I added LICENSE and NOTICE files to all modules - these are now being
included in the generated jars.

I also added assembly to create source and binary distros (not
including JSR199 and Examples - is that correct?).

Niall


On 4/12/07, Niall Pemberton <[EMAIL PROTECTED]> wrote:
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]

Reply via email to