commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [VOTE] Release Configuration 1.2
Date Sun, 04 Dec 2005 19:23:16 GMT

Hi Phil,

I think I am now at a point where I have a maven build, which should satisfy almost all points
noticed by you and other reviewers - except for the line ending issue. After some documentation
improvements I hope I can publish the (hopefully final) RC3 in some days.

I had a clirr report in the first release candidate. It can be found here:

This report contains two error messages, which are a bit strange. It claims that a method
was dropped from XMLConfiguration, but this method was simply moved into a super class. Maybe
a clirr expert can chime in?


>Sorry to be so late checking / trying to help.  I am +1 for the
>release assuming Stephen's points (other than the ones listed as
>"optional") and the following issues are addressed:
>- You should either modify configs, fix issues or eliminate PMD and
>checkstyle reports
>- Javadoc errors should be fixed so javadoc report is clean
>- Package javadoc is missing from three of the packages
>- Apologies if I missed this posted somewhere, but have you done a
>clirr or jdiff report against 1.0?  If there have been incompatible
>changes since 1.1, these should be called out to users.  Its hard to
>tell from the changes report.
>Here are some additional comments that you are free to ignore, but
>which may be useful.
>1) The username in the jar manifest is a PITA, since the maven dist
>plugin does not seem to pay attention to the property that
>it is supposed to control this (yes, I know, need to open ticket).  To
>work around this, I provide this on the command line:
>maven dist.  That works4me.
>2) I think the workaround mentioned above for the sun jar is OK,
>though I don't think its that bad to force the local repo surgery,
>with a doco note somewhere.
>3) You can use maven.compile.executable as described above to force
>compilation on jdk 1.3 (I personally do not view this as necessary, as
>long as you test the build on 1.3) and then use the maven.jar.manifest
>property (
>to specify a text file with lines to be "merged in" to the manifest to
>fix the version spec.  If you go this route, you should probably check
>that file into svn so the build is repeatable.  Note this can also be
>used to solve 1).  Also, in order for maven.compile.executable to
>work, you need to have maven.compile.fork=true.  Start with a bogus
>path in the first property to make sure it is being used.
>4) At this point, we have no consensus on line endings standards, so I
>would not worry about the CRLF issue.  See other thread.  To me the
>bigger problem here is actually when releases are cut on Windows we
>are shipping CRLF on all files with svn eol=native props. Looks to me
>like the RC was build on unix, so there is no problem there.
>5) If you configure and local as
>described here:
> and you have an apache
>ssh key set up, you can deploy the distribution jar to the
>distribution repo using
>maven -Dmaven.repo.list=apache.releases jar:deploy
>You should sign the jar as well and manually upload the sig to the
>repo.  Signing is not yet supported by the jar (or dist) plugin, and
>most of the jars in java-repository are not signed, but we should be
>(manually) signing them.
>6) You can use the maven announcement plugin with customized jsl (see
>[math]) to create full release notes like the maven changes report.  I
>have no problem with not doing that, but if you don't, you need to
>remember to put a <version> element in the POM post release,  so that
>the link to
>remains valid (i.e. contents don't change to include changes after the
>release within scope of release).   You might also consider including
>the current version of the html file in both src and binary distros.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message