Maven project junit:junit:jar #511

Tibor17 · 2012-09-22T23:08:06Z

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.

dsaff · 2012-09-25T21:29:03Z

pom.xml

+			<email>david@saff.net</email>
+		</developer>
+	</developers>
+	<contributors>


Is there any way to direct people to github for a comprehensive list of contributors?

sure we will extend this section. I am open.

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

dsaff · 2012-09-25T21:40:05Z

Thanks for the hard work here. A good start.

Tibor17 · 2012-09-25T21:45:07Z

yes, we will refactor of course.
It seems today we make a progress. I am very glad.

stefanbirkner · 2012-09-26T20:25:11Z

pom.xml

+		</contributor>
+	</contributors>
+	<properties>
+		<hamcrestVersion>1.3</hamcrestVersion>


Shouldn't this be [1.3,)

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

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.

Please no... do not use version ranges... they were a seductive idea, but they result in builds that break behind your back

@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.

…aven

Tibor17 · 2012-09-26T21:03:55Z

@dsaff
do you have time to build locally now?
Just open command line and type "make" -you do not need to struggle with IDE/Maven configuration yet.

dsaff · 2012-09-27T14:29:55Z

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.

Tibor17 · 2012-09-27T15:28:05Z

I am going to push updated pom.xml with documenting comments for us.

This is fast start up tutorial of maven
http://maven.apache.org/
Use Maven > Getting Started Tutorial

you can copy/paste the examples and run

This link helps you to configure http://maven.apache.org/download.html#Installation
however in our makefile it is not necessary -just see it's easy
initialy it is enough to start the maven script
apache-maven-3.0.4/bin/mvn.bat (for Win)
apache-maven-3.0.4/bin/mvn (for Unix)

just extract the tgz file
http://www.us.apache.org/dist/maven/maven-3/3.0.4/binaries/apache-maven-3.0.4-bin.tar.gz

Tibor17 · 2012-09-28T01:26:37Z

@dsaff
the latest update has a documentation in pom.xml and little improvements
pls put your comments

dsaff · 2012-10-10T18:24:58Z

Makefile

@@ -0,0 +1,59 @@
+	SHELL = /bin/sh


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)

makes sense.
i can write such a maven launcher in ant.

@Tibor17 Can you please delete this file?

stephenc · 2013-01-15T10:03:51Z

@Tibor17 you are deploying to central via sonatype. Therefore the Artifactory stuff is unnecessary and irrelevant. Build #12 deployed correctly because it was specifying the settings.xml to use, build #1 failed because it wasn't.

Tibor17 · 2013-01-15T10:06:34Z

@stephenc
Ah, ok, I missed.
So what was the difference between #1 and #12 ?
@marcphilipp ?

stephenc · 2013-01-15T10:07:51Z

@Tibor17 the difference is, and I am guessing because I'm not looking at the job config only the build history, that in #1 no "Alternate settings" or -s /private/.../settings.xml was configured but in #12 that has been set

Tibor17 · 2013-01-15T10:09:57Z

@stephenc
Ok, so I will push a new pull with
<id>junit-snapshot-repo</id> <id>junit-releases-repo</id>

Do we need timeout in settings.xml ?
Do we have to upgrade from wagon-http:1.0 to wagon-http:2.2 ?

stephenc · 2013-01-15T10:18:40Z

Here is one example of a standalone parent pom.xml: https://github.com/cloudbees/cloudbees-oss-parent/blob/master/pom.xml I'll see if I have more

Tibor17 · 2013-01-15T10:21:29Z

@marcphilipp
If you use mvn release:prepare release:perform instead of mvn deploy, then we should update the BUILDING documentation.

Tibor17 · 2013-01-15T10:22:40Z

@stephenc
Nice, we will do it in similar.
Thx

stephenc · 2013-01-15T10:23:31Z

Here is the sonatype one: https://github.com/sonatype/spice/blob/master/oss/oss-parent/pom.xml

No extensions required

Tibor17 · 2013-01-15T10:27:11Z

@stephenc
No extensions because of using release-plugin?

stephenc · 2013-01-15T10:28:24Z

@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 mvn deploy for deploying -SNAPSHOTs and cut releases with mvn release:prepare release:perform

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 settings.xml... mind you @kohsuke and I have a long running (since 2007) disagreement over the maven project type, so I am just mentioning that if you are having issues cutting releases with a Maven project type job then “I'm right and Kohsuke's wrong” ;-) but perhaps my tauntings have had some positive effects and you won't have issues ;-)

stephenc · 2013-01-15T10:33:45Z

@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:

It again is just safer

It allows us to define the profile specific GPG keyname and passphrase

<profile>
  <id>cloudbees-oss-release</id>
  <properties>
    <gpg.keyname>4A2F92BB</gpg.keyname>
    <gpg.passphrase><!-- my secret passphrase for the key on my machine --></gpg.passphrase>
  </properties>
</profile>

Now getting to that will require @marcphilipp to put some more files in the /private webdav share if you want Jenkins cutting releases.

Keep in mind that the GPG key used for signing releases must be the one registered with Sonatype.

stephenc · 2013-01-15T10:40:43Z

@marcphilipp your /private/.../settings.xml will probably want to look something like this:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>junit-snapshot-repo</id>
      <username>...</username>
      <password>...</password>
    </server>
    <server>
      <id>junit-releases-repo</id>
      <username>...</username>
      <password>...</password>
    </server>
  </servers>
  <profiles>
    <profile>
      <id>junit-release</id>
      <properties>
        <gpg.keyname>...</gpg.keyname>
        <gpg.passphrase>...</gpg.passphrase>
        <gpg.defaultKeyring>false</gpg.defaultKeyring>
        <gpg.useagent>true</gpg.useagent>
        <gpg.homedir>/private/.../.gnupg</gpg.homedir>
        <gpg.publicKeyring>/private/.../.gnupg/pubring.gpg</gpg.publicKeyring>
        <gpg.secretKeyring>/private/.../.gnupg/secring.gpg</gpg.secretKeyring>
      </properties>
    </profile>
  </profiles>
</settings>

And you will have to seed the .gnupg home directory in the webdav share.

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)

stephenc · 2013-01-15T10:43:59Z

@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.

Tibor17 · 2013-01-15T11:13:19Z

@stephenc
We have to use a profile for signing as it is now, because the developers won't use gpg plugin.

stephenc · 2013-01-15T11:31:19Z

@Tibor17 yes, but it should be namespaced too just like the server <id>s to allow the release manager to manage different projects that are being signed with different gpg keys

Tibor17 · 2013-01-15T11:39:57Z

@stephenc
gpg plugin under profil junit-release. -just renaming our current profile sign to junit-release.
Agree?

All together for documentation.

CMD for snapshots:
mvn clean deploy

CMD for releases:
mvn -Dgpg.passphrase=<your psswd> -Dgpg.keyname=<your key> -Pjunit-release release:prepare release:perform
, where gpg key is the Sonatype registered key. Seed the .gnupg home directory (in the webdav share).

The clean does not slow down in this small project.

Are we missing something in these commands?
Pls check it, thx.
I will push a new pull for updating pom.xml, settings.xml, doc, and invite you there.

stephenc · 2013-01-15T12:16:35Z

Actually to get release to work in the forked execution you need the gpg stuff in settings.xml and the profile activation configuration in the pom.xml within the maven-release-plugin def of the plugin, e.g. what I did here

In which case command for snapshots is

mvn clean deploy

command for release is

mvn release:prepare release:perform

stephenc · 2013-01-15T12:23:44Z

BTW, what I do is I have

    <gpg.defaultKeyring>false</gpg.defaultKeyring>
    <gpg.useagent>true</gpg.useagent>
    <gpg.homedir>/Volumes/RelCredsUSB/.gnupg</gpg.homedir>
    <gpg.publicKeyring>/Volumes/RelCredsUSB/.gnupg/pubring.gpg</gpg.publicKeyring>
    <gpg.secretKeyring>/Volumes/RelCredsUSB/.gnupg/secring.gpg</gpg.secretKeyring>

in my the ~/.m2/settings.xml

That way even though the passphrase is in my ~/.m2/settings.xml the actual key is on removable storage that I just insert when I need to make a release. Gives physical security of the release keys.

Some people may think I am being paranoid... others may think I am not paranoid enough. YMMV

Tibor17 · 2013-01-15T12:27:12Z

@stephenc
of course, the settings.xml as you proposed.
I understand the security.
It will be perfect.

Tibor17 · 2013-01-15T13:36:20Z

@stephenc
Suppose we would make a new release of JUnit. We want to update the incremental version from
development 4.12-SNAPSHOT to the release version 4.12.1.

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 4.12.1-SNAPSHOT in Jenkins ?
I think the plugin will cut to release version 4.12.1.

Will be the final command like this?

mvn -DdevelopmentVersion=4.12.1-SNAPSHOT -Dgpg.passphrase=<your psswd> -Dgpg.keyname=<your key> -Pjunit-release clean release:update-versions release:prepare release:perform

The version specified manually has to be always SNAPSHOT, right?

stephenc · 2013-01-15T14:11:41Z

@Tibor17

Specifying -Dgpg.passphrase=... or -Dgpg.keyname=... on the CLI will not work with the release plugin as it forks a clean release environment for performing the release so that environment will not have the gpg.passphrase or gpg.keyname properties defined... you'd have to do -Dgpg.passphrase=... -Dgpg.keyname=... '-Darguments=-Dgpg.passphrase=... -Dgpg.keyname=...' to get it to work... which is error prone (typing passphrase twice) hence do it “the maven way” and have those properties in a junit-release profile in your ~/.m2/settings.xml and be done with it.

You don't need to update the versions if you are preparing a release, you just go with

mvn -DreleaseVersion=4.12.1 -DdevelopmentVesrion=4.12.2-SNAPSHOT release:prepare release:perform

And that will take care of the rest.

dsaff · 2013-01-15T16:08:37Z

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 · 2013-01-15T17:49:03Z

@stephenc
I pushed a new pull #613 .
Would you pls remind us of your findings in my changes?
Thx

marcphilipp · 2013-01-15T20:01:05Z

@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.

Tibor17 · 2013-01-15T20:13:50Z

@marcphilipp
you mean that the javadoc deployment to open repository on CloudBees fails.
It's best to automate the processes.

stephenc · 2013-01-15T20:15:31Z

If somebody commits a unit test that scrapes some files off the file system
and pushes them to a remote server, there is nothing we can do to stop
that. Hence I would recommend that an instance responsible for pushing to
maven central only build git branches that you have reviewed the code going
in. Leave eg buildhive to checkout and build the pull requests.

Longer term (couple of months) I aim to get the Jenkins credentials plugin
better integrated. That would give you a secure store where the
passphrase could be held in-process rather than on the file system...
However as this would be running as the same user, this can never be
perfect.

If you want to guard the key with your life then you probably want to store
than on a USB stick and do release builds from your machine.

I am perfectly happy, myself, with the keys I manage being stored in the
WebDAV store.

Some things we can do, and I recommend contacting me on a non-public list,
ie sconnolly at cloudbees dot com, and I will be happy to take you through
some of the finer details... Unfortunately they do only obscure... If you
want Jenkins to auto push then you need to give it everything it needs and
therefore there is a risk.

It all depends on the level of risk you are comfortable with... And CI
system will have these issues

On Tuesday, 15 January 2013, Marc Philipp wrote:

@Tibor17 https://github.com/Tibor17 @stephenchttps://github.com/stephencThanks to both of you for working this out.

@stephenc https://github.com/stephenc How secure is the private
CloudBees WebDAV store? Is it save enough to store passwords and keys there?

@Tibor17 https://github.com/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.

—
Reply to this email directly or view it on GitHubhttps://github.com/KentBeck/junit/pull/511#issuecomment-12286170.

marcphilipp · 2013-01-15T20:50:06Z

@Tibor17 No, I meant the Jenkins feature to archive browsable Javadoc
for successful builds.

Tibor17 · 2013-01-15T21:32:29Z

@marcphilipp
ok, what about to deploy to the repo via goal site-deploy
http://docs.codehaus.org/display/MAVENUSER/Javadoc+Plugin

I think there is a configuration in maven to zip the content and extract on repo via scp, site:deploy.

marcphilipp · 2013-01-16T06:20:16Z

Switched back to freestyle Jenkins job. Now it works as expected.

Tibor Digana added 2 commits September 23, 2012 00:56

Maven project junit:junit artifact

32b5270

completed deployment Sourcefore and Maven central: verified OK

6674534

dsaff reviewed Sep 25, 2012
View reviewed changes

stefanbirkner reviewed Sep 26, 2012
View reviewed changes

type "make" helps you to build without studying a config of IDE for M…

a0f325e

…aven

deleted **/junit/runner/LICENSE

4dc40a2

added documentation + improvements

36101e7

Tibor17 mentioned this pull request Sep 28, 2012

OSGi Proposal #515

Closed

signing all project artifacts before deployment

ab70e74

dsaff reviewed Oct 10, 2012
View reviewed changes

Tibor17 mentioned this pull request Jan 15, 2013

Prepare for Maven release #613

Closed

Maven project junit:junit:jar #511

Maven project junit:junit:jar #511

Conversation

Tibor17 commented Sep 22, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dsaff commented Sep 25, 2012

Tibor17 commented Sep 25, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tibor17 commented Sep 26, 2012

dsaff commented Sep 27, 2012

Tibor17 commented Sep 27, 2012

Tibor17 commented Sep 28, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

stephenc commented Jan 15, 2013

stephenc commented Jan 15, 2013

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

stephenc commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

dsaff commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

marcphilipp commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

stephenc commented Jan 15, 2013

marcphilipp commented Jan 15, 2013

Tibor17 commented Jan 15, 2013

marcphilipp commented Jan 16, 2013