commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [VOTE] Release Configuration 1.2
Date Sun, 04 Dec 2005 19:23:16 GMT
<snip/>

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:
http://people.apache.org/~oheger/commons-configuration-1.2RC1-docs/clirr.xml

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?

Thanks
Oliver

>
>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 user.name 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 -Duser.name=psteitz 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 (http://maven.apache.org/maven-1.x/reference/plugins/jar/properties.html)
>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 project.properties and local build.properties as
>described here:
>http://jakarta.apache.org/commons/building.html 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 http://jakarta.apache.org/commons/configuration/changes-report.html
>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.
>
>Phil
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message