commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [VOTE] Release Configuration 1.2
Date Sat, 03 Dec 2005 19:43:22 GMT
On 12/3/05, Oliver Heger <> wrote:
> Stephen,
> thanks for your feedback. I will address your points. Some questions follow:
> - What is the purpose of the file? I didn't find anything
> about that in the releasing components instructions. It contains the
> *.java files and the LICENSE and NOTICE files, right?
> - Line endings: You mean files like project.xml or
> should also be converted?
> I think many things can be done with maven by tweaking the maven.xml,
> but the complex line ending stuff probably not. AFAIK a comming up
> version of the dist plugin should support this.
> Oliver
> Stephen Colebourne wrote:
> > Oliver Heger wrote:
> >
> >>> ---------------------------------------------------------------
> >>> [ ] +1  I support this release and am willing to help
> >>> [ ] +0  I support this release but am unable to help
> >>> [ ] -0  I do not support this release
> >>> [X] -1  I do not support this release, and here are my reasons
> >>> ---------------------------------------------------------------
> >>
> >
> > Finally had time to check it (and note down what I did for the
> > future). Apologies for it being a late -1.
> >
> > -1:
> > Usage of Simian. This is a commercial product which requires a
> > license. They state that they will grant a license to OSS, but we
> > should confirm whether ASF/Jakarta has such a license. The simplest
> > thing for now is to remove this report from the website until the PMC
> > can confirm the legal position.
> >
> > -1:
> > jar file manifest:
> > Built-By: hacker
> >
> > I assume 'hacker' is a username of yours. However, I think its
> > unsuitable for an ASF distribution.
> >
> > -0:
> > jar file manifest:
> > Build-Jdk: 1.4.2_04
> >
> > Also, I assume that the build-jdk has come from the jdk running maven
> > and is not the version configuration supports? Not sure what the
> > solution to this is except using ant for the build running JDK 1.3.
> >
> > -0:
> > The xdocs are not included in the src download.
> >
> >
> > Other recommended changes:
> > - Digester dependency states v1.5, but v1.6 is now released.
> >
> > - You specify the two separate beanutils jar files when you could
> > specify just beanutils-core (there is no dependency on
> > beanutils-collections).
> >
> >
> > Other optional ideas:
> > - Ensure that the source zip unzips to a directory name ending with
> > -src. There is a maven setting for this, but I can't find it quickly.
> >
> > - Include a file in the binary release. See commons-io.
> > This can only be done with ant AFAIK.
> >
> > - Line endings. It seems that you are converting txt files in the root
> > folder. Personally I would like to see all text files in the root
> > folder converted. This can only be done with ant AFAIK.
> >
> > - Ensure that the jar uploaded to ibiblio is exactly the same as that
> > in the binary release - including date and timestamp. This makes
> > problem resolution easier. This can only be done manually AFAIK.
> >
> >
> > You may notice that ant is needed to achieve much of the above. But
> > maven vs ant is a debate for a separate thread.
> >
> > Stephen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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:

View raw message