-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maven project junit:junit:jar #511
Conversation
<email>[email protected]</email> | ||
</developer> | ||
</developers> | ||
<contributors> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way to direct people to github for a comprehensive list of contributors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure we will extend this section. I am open.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, it's less about extending it with current contributors, and more about not having to keep checked into the codebase some static representation of who's done enough to be considered a "contributor". If there's no official maven way, I'd almost rather kill the "contributors" section entirely, and add a comment pointing the interested to https://github.com/KentBeck/junit/graphs/contributors
Thanks for the hard work here. A good start. |
yes, we will refactor of course. |
</contributor> | ||
</contributors> | ||
<properties> | ||
<hamcrestVersion>1.3</hamcrestVersion> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be [1.3,)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah it works, but it's not usual in maven central.
the companies use the range of version but i haven't seen any maven central artifact like this.
imho with strick version we are on safe side if hamcrest makes any incompatible changes (without changing major version)
the user of junit may still exclude or override junit's dependency of hamcrest-core:1.3 to other version
are you facing a need for, that it would help you in your use of junit?
maybe [1.3, 2.0) is more safe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current configuration works for me. It's just about a problem, that may occur if we only work with a recommendation for the Hamcrest version. [1.3, 2.0) is a good solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please no... do not use version ranges... they were a seductive idea, but they result in builds that break behind your back
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stephenc
yes, i agree with you. I vote for simplicity.
More and more people want to be isolated from hamcrest and control the version by themselve. That's maybe the reason why many proposals come.
IMHO at some later time we may propose modular junit and isolate the most of the junit modules from ext artifacts.
I think it should help devs and users as well, while keeping junit:junit artifact unchanged (not talking about src).
@stefanbirkner @stephenc are you open for this idea? Maybe we should discuss it in junit2yahoo.
@dsaff |
We're off a great start. As I mention in at least one of the comments above, mostly, I figure that anywhere I can't easily figure out what's going on, the next contributor might have the same question, so some in-line documentation could really help. |
I am going to push updated pom.xml with documenting comments for us. This is fast start up tutorial of maven you can copy/paste the examples and run This link helps you to configure http://maven.apache.org/download.html#Installation just extract the tgz file |
@dsaff |
@@ -0,0 +1,59 @@ | |||
SHELL = /bin/sh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way to do what this file does, only with ant? I'm not a huge fan of ant, but it does have the advantage of working on popular OS's that do not have /bin/sh preinstalled (e.g. Windows)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense.
i can write such a maven launcher in ant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Tibor17 Can you please delete this file?
@stephenc |
@stephenc Do we need timeout in |
Here is one example of a standalone parent |
@marcphilipp |
@stephenc |
Here is the sonatype one: https://github.com/sonatype/spice/blob/master/oss/oss-parent/pom.xml No extensions required |
@stephenc |
@Tibor17 @marcphilipp you probably want two jobs, or else use the M2 release plugin in jenkins if you want Jenkins to roll the releases for you. I would use Also I would note that I repeatedly find issues with the Maven project type as opposed to a FreeStyle project with a Maven build step when trying to cut releases using a custom |
@Tibor17, another thing you will notice with the CloudBees OSS Parent is that we use a namespaced profile for the release signing... that has two effects:
Now getting to that will require @marcphilipp to put some more files in the Keep in mind that the GPG key used for signing releases must be the one registered with Sonatype. |
@marcphilipp your
And you will have to seed the Note the above is if you want Jenkins to be able to cut release builds... you will still be required to login to http://oss.sonatype.org to promote the staged release. (CloudBees Employee Hat) If you want help configuring the RBAC plugin to lock down who can kick off builds from a release build job, just give me a ping and I'd be happy to help(/CloudBees Employee Hat) |
@Tibor17 no extensions because not needed. Sonatype nexus deploy is not over webdav but just a simple HTTP PUT and Nexus does not need the path to exist. WebDAV based repos need extensions to ensure that the path is fixed. And using the newer wagon shouldn't hurt and should make deploys more reliable, but given that there is staging in front and Nexus checks the checksums and junit is small, I have yet to need a newer wagon. |
@stephenc |
@Tibor17 yes, but it should be namespaced too just like the server |
@stephenc All together for documentation. CMD for snapshots: CMD for releases: The clean does not slow down in this small project. Are we missing something in these commands? |
Actually to get release to work in the forked execution you need the gpg stuff in In which case command for snapshots is
command for release is
|
BTW, what I do is I have
in my the ~/.m2/settings.xml That way even though the passphrase is in my Some people may think I am being paranoid... others may think I am not paranoid enough. YMMV |
@stephenc |
@stephenc We will set the new version in Jenkins UI via maven-release plugin. Will be one command, and do we have to specify the new snapshot version Will be the final command like this?
The version specified manually has to be always SNAPSHOT, right? |
Specifying You don't need to update the versions if you are preparing a release, you just go with
And that will take care of the rest. |
I'm hearing productive chatter here, but staying out of the particulars. If there's something I can helpfully chime in on, please point it out to me. Thanks! |
@Tibor17 @stephenc Thanks to both of you for working this out. @stephenc How secure is the private CloudBees WebDAV store? Is it save enough to store passwords and keys there? @Tibor17 Regarding the Javadoc post-build-step: That was an experiment. I still can't get the Maven 2/3 job to archive Javadoc. I will probably switch back to a free-style project. |
@marcphilipp |
If somebody commits a unit test that scrapes some files off the file system Longer term (couple of months) I aim to get the Jenkins credentials plugin If you want to guard the key with your life then you probably want to store I am perfectly happy, myself, with the keys I manage being stored in the Some things we can do, and I recommend contacting me on a non-public list, It all depends on the level of risk you are comfortable with... And CI On Tuesday, 15 January 2013, Marc Philipp wrote:
|
@Tibor17 No, I meant the Jenkins feature to archive browsable Javadoc |
@marcphilipp I think there is a configuration in maven to zip the content and extract on repo via scp, site:deploy. |
Switched back to freestyle Jenkins job. Now it works as expected. |
I created this artifact because we agreed we want to have the Maven build process.
I would like to deploy this project to Maven central Snapshot repositories under version 4.11.1-SNAPSHOT, and notify the JUnit community to test. For the first looking the build outcome is useful.
IMHO the release plan could be like this:
4.11-SNAPSHOT for #332
4.11.1-SNAPSHOT for this pull request
4.11.2-SNAPSHOT for OSGi + Maven pull request
What you think?
I obviously do not have server credentials user/psswd to deploy to Maven central.