On 4/12/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
Niall, really appreciate our input!
On 12.04.2007, at 06:22, Niall Pemberton wrote:
> 1) NOTICE / LICENSE
> The issue raised by Rahul about the missing NOTICE and LICENSE files
> gets a bit complex.They are not specified as a "resource" element in
> version 2 of the commons parent pom (which AFAIK would cause them to
> be included in all modules) because of a bug in the maven source
> plugin (MSOURCES-6) with resource elements in the base directory - so
> it has an "antrun" workaround which doesn't seem to have worked in
> this multi-module case.
Grr
> We're still waiting for a release of that
> plugin so the workaround can be removed. One solution is to move these
> to jci/src/main/resources (which is the default resources location for
> maven)
For every artifact you mean?
It looks that way - projects like Shale have done that - but maybe one
of the maven gurus can offer a better idea.
> and AFAIK will result in them being automatically included in
> all jars (except the test jars - not sure how you get them there).
>
> Also the NOTICE.txt has 1999-2006 in the copyright statement - should
> be 2007 (and is 1999 really the start year?)
That should be 2004. Fixed.
> 2) Dependencies
> Couple of points - any reason not to depend on the latest versions of
> commons components (Collections 3.2 rather than 3.1, IO 1.3.1 rather
> than 1.1, Lang 2.3 rather than 2.1)?
>
> Also the following report hightlights dependency discerepancies:
> http://jakarta.apache.org/commons/jci/commons-jci-core/dependency-
> convergence.html
>
> FAM depends on JUnit 3.8.2 and everything else 3.8.1 and Core depends
> on Logging 1.0.4 and FAM depends on Logging 1.1.
Just didn't bother. Fixed that up, too.
> Also in the most of the module's pom.xml the core-test-jar dependency
> has version 1.0-SNAPSHOT rather than 1.0-RC1.
Well, that I don't know. I was just using the usual mvn release process.
I fear maven missed the attached jar. Not sure how to deal with that
yet.
Could be a maven bug - but not sure. Could also be that maven messed up
when I re-did the RC1 after an unsuccessful try.
Will watch that closely next time.
> Usually I don't mind
> whether people use the older RC method or create the actual aritifacts
> to be distributed - but in this case theres too many things to forget
> in a multi-module release so I won't vote on a RC for JCI - only the
> actual artifacts.
So you want really individual votes for each artifact? ...keep in mind
there is only one site though.
Sorry, didn't say that very well. What I meant was rather than
producing "release candidate" artifacts (i.e with version 1.0-RC1
numbers) - I'd rather vote on the actual artifacts that are going to
be deployed if the votes passes - i.e. with the proper 1.0 version
number. A number of components have done this recently and it means
less chance of something going wrong after the vote passes as it
simply becomes a case of copying the jars/distros that have been voted
on rather than building a whole new set when "cutting a release".
> 3) Source/Binary distros
> Any reason not to produce the usual source/binary distros for JCI -
> rather than just maven artifacts?
Well, how much different would that be? We could zip up artifacts
but e.g. the site does not work offline (stupid!) unless you do a
site:stage.
Any suggestions?
Site doesn't need to be included IMO - but a binary distro with all
the JCI jars and javadocs would be nice and a source distro which is
just a zip of the whole src repo. If I get time later I could add an
assembly to create these.
> 4) pom.xml Name & Description
> None of the module pom.xml have descriptions (only JCI parent) which
> are used on the generated module site.
OK ...added those
> Also the commons parent pom
> uses the name in the manifest entries in the jar - having a name like
> "fam" (rather than e.g. JCI fam) makes those entries less useful.
Well, that requires a new release of the parent pom.
> 5) site.xml
> Seems that all the modules are using the parent site.xml, since they
> don't have one - which means all the module sites have a "Usage",
> "FAQ" and "Downloads" links which are broken. You probably need to
> include site.xml for each module to avoid this.
As the site.xml is inherited I would assume the links get adjusted.
That sucks! How stupid is that?
True and probably doesn't matter for the release since you're not
shipping that. So perhaps something to ponder after.
> 6) Source Xref links
> Seems that the amalgamated source xref is generated OK - but reports
> in modules that link to it are broken - guess thats probably a maven
> bug.
Yeah ...wouldn't know how to fix that
> 7) JDK Version
> The commons parent pom is set up to compile with a source/target
> version of 1.4 by default - and it adds entries to the jar's manifest
> indicating this (X-Compile-Source-JDK and X-Compile-Target-JDK). In
> the JSR199 module (I realize its not part of the RC, but is in RC1
> tag) you have overriden this to specify JDK 1.6 via the plugin config
> - this would result in the manifest indicating 1.4 - the way to
> specify this is by adding properties to the JSR199 pom.xml rather than
> using the plugin config:
> <properties>
> <maven.compile.source>1.6</maven.compile.source>
> <maven.compile.target>1.6</maven.compile.target>
> </properties>
Ah ...good catch. Fixed!
> Is 1.4 the correct setting for all the other modules?
Yes
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
