You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2007/04/11 01:42:06 UTC
[vote] release commons jci RC1 as 1.0
Since RC1 is working fine for cocoon and other parties I would like
to call a vote on the release for commons jci.
http://jakarta.apache.org/commons/jci/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-core/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-eclipse/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-fam/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-groovy/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-janino/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-javac/1.0-RC1/
http://people.apache.org/repo/m2-snapshot-repository/org/apache/
commons/commons-jci-rhino/1.0-RC1/
Please cast your votes.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Torsten Curdt <tc...@apache.org>.
Great, thanks!
On 19.04.2007, at 16:31, Niall Pemberton wrote:
> Found a few source file headers still with copyright statement - hope
> you don't mind but I just dived in and fixed them:
>
> http://svn.apache.org/viewvc?view=rev&revision=530425
>
> Niall
>
> On 4/11/07, Torsten Curdt <tc...@apache.org> wrote:
>> Since RC1 is working fine for cocoon and other parties I would like
>> to call a vote on the release for commons jci.
>>
>> http://jakarta.apache.org/commons/jci/
>>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-core/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-eclipse/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-fam/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-groovy/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-janino/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-javac/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-rhino/1.0-RC1/
>>
>> Please cast your votes.
>>
>> cheers
>> --
>> Torsten
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
Found a few source file headers still with copyright statement - hope
you don't mind but I just dived in and fixed them:
http://svn.apache.org/viewvc?view=rev&revision=530425
Niall
On 4/11/07, Torsten Curdt <tc...@apache.org> wrote:
> Since RC1 is working fine for cocoon and other parties I would like
> to call a vote on the release for commons jci.
>
> http://jakarta.apache.org/commons/jci/
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-core/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-eclipse/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-fam/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-groovy/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-janino/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-javac/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-rhino/1.0-RC1/
>
> Please cast your votes.
>
> cheers
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: [vote] release commons jci RC1 as 1.0
Posted by Torsten Curdt <tc...@apache.org>.
Feel free to fix :)
...but I fear that would required another RC round then
cheers
--
Torsten
On 11.04.2007, at 18:07, Niall Pemberton wrote:
> I'll try and review tonight - if I find any build/site nitpicks do you
> mind if I fix them or do you prefer patches?
>
> Niall
>
> On 4/11/07, Torsten Curdt <tc...@apache.org> wrote:
>> Since RC1 is working fine for cocoon and other parties I would like
>> to call a vote on the release for commons jci.
>>
>> http://jakarta.apache.org/commons/jci/
>>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-core/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-eclipse/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-fam/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-groovy/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-janino/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-javac/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-rhino/1.0-RC1/
>>
>> Please cast your votes.
>>
>> cheers
>> --
>> Torsten
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
I'll try and review tonight - if I find any build/site nitpicks do you
mind if I fix them or do you prefer patches?
Niall
On 4/11/07, Torsten Curdt <tc...@apache.org> wrote:
> Since RC1 is working fine for cocoon and other parties I would like
> to call a vote on the release for commons jci.
>
> http://jakarta.apache.org/commons/jci/
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-core/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-eclipse/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-fam/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-groovy/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-janino/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-javac/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-rhino/1.0-RC1/
>
> Please cast your votes.
>
> cheers
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: [vote] release commons jci RC1 as 1.0
Posted by Wendy Smoak <ws...@gmail.com>.
On 4/15/07, Torsten Curdt <tc...@apache.org> wrote:
> Niall wrote:
> > 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".
>
> True and makes total sense. Unfortunately the maven release process
> does not really adhere to that - unless I am missing something.
>
> mvn release:prepare -Prc
> mvn release:perform -Prc
>
> Creates the tag and deploy to the snapshot repo.
>
> mvn release:prepare -Prelease
> mvn release:perform -Prelease
>
> Would be next ....but that would not match our (or the quite common)
> process of turning a RC into a release.
Instead of deploying straight to m2-ibiblio-rsync-repository, "stage"
the release somewhere else for the vote. The two ways that work right
now are:
1. Use an alternate deployment repository configured in the pom or on
the command line.
See http://maven.apache.org/developers/release/releasing.html
which talks about
how to release parts of the Maven project.
2. Override <distributionManagement><repository> in your project pom.
Many projects use space under http://people.apache.org/builds/ to do
this, for example:
http://people.apache.org/builds/tiles/2.0.3/ . This has the source
and binary distributions at the top, and then a staging repo for the
Maven artifacts, which can be merged (or just copied) into the rsynced
repo after the vote.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/17/07, Niall Pemberton <ni...@gmail.com> wrote:
<snip/>
>
> AIU projects using m2 that vote on actual release artifacts use a
> "staging" repository - but I guess that would take a change in the
> commons pom first. Anyway ignore my comment - I've not done a release
> using m2 and I guess if you resolve the reason why the release plugin
> didn't correctly update all the dependency versions for the RC then it
> should be OK.
>
<snap/>
I'd prefer to vote on the actual artifacts, and FWIW, I'd mostly vote
no better than +0 for anything else (ofcourse, this is not a JCI
specific comment).
-Rahul
P.S.-Thanks for the license / notice additions to all modules.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
On 4/16/07, Torsten Curdt <tc...@apache.org> wrote:
>
> On 12.04.2007, at 19:56, Niall Pemberton wrote:
>
> > On 4/12/07, Torsten Curdt <tc...@apache.org> 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.
>
> Well, would have been nice if that wasn't required - but you already
> worked around it :)
>
> <snip/>
>
> >> > 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.
>
> Ah! OK
>
> > 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".
>
> True and makes total sense. Unfortunately the maven release process
> does not really adhere to that - unless I am missing something.
>
> mvn release:prepare -Prc
> mvn release:perform -Prc
>
> Creates the tag and deploy to the snapshot repo.
>
> mvn release:prepare -Prelease
> mvn release:perform -Prelease
>
> Would be next ....but that would not match our (or the quite common)
> process of turning a RC into a release.
AIU projects using m2 that vote on actual release artifacts use a
"staging" repository - but I guess that would take a change in the
commons pom first. Anyway ignore my comment - I've not done a release
using m2 and I guess if you resolve the reason why the release plugin
didn't correctly update all the dependency versions for the RC then it
should be OK.
> >> > 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.
>
> Thanks for that!
>
> >> > 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.
>
> Well, would love to have a working site. Release or not ;) Stupid
> maven multiproject stuff.
>
> cheers
> --
> Torsten
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [vote] release commons jci RC1 as 1.0
Posted by Torsten Curdt <tc...@apache.org>.
On 12.04.2007, at 19:56, Niall Pemberton wrote:
> On 4/12/07, Torsten Curdt <tc...@apache.org> 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.
Well, would have been nice if that wasn't required - but you already
worked around it :)
<snip/>
>> > 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.
Ah! OK
> 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".
True and makes total sense. Unfortunately the maven release process
does not really adhere to that - unless I am missing something.
mvn release:prepare -Prc
mvn release:perform -Prc
Creates the tag and deploy to the snapshot repo.
mvn release:prepare -Prelease
mvn release:perform -Prelease
Would be next ....but that would not match our (or the quite common)
process of turning a RC into 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.
Thanks for that!
>> > 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.
Well, would love to have a working site. Release or not ;) Stupid
maven multiproject stuff.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Torsten Curdt <tc...@apache.org>.
On 13.04.2007, at 06:22, Niall Pemberton wrote:
> 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?).
Awesome Niall! Thanks a lot!
I hope to find the time to look into the site stuff this week and
then prepare a RC2
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
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 <ni...@gmail.com> wrote:
> On 4/12/07, Torsten Curdt <tc...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
On 4/12/07, Torsten Curdt <tc...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Torsten Curdt <tc...@apache.org>.
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?
> 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.
> 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?
> 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?
> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
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. 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) 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?)
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.
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. 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.
3) Source/Binary distros
Any reason not to produce the usual source/binary distros for JCI -
rather than just maven artifacts?
4) pom.xml Name & Description
None of the module pom.xml have descriptions (only JCI parent) which
are used on the generated module site. 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.
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.
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.
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>
Is 1.4 the correct setting for all the other modules?
Niall
On 4/11/07, Torsten Curdt <tc...@apache.org> wrote:
> Since RC1 is working fine for cocoon and other parties I would like
> to call a vote on the release for commons jci.
>
> http://jakarta.apache.org/commons/jci/
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-core/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-eclipse/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-fam/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-groovy/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-janino/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-javac/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-rhino/1.0-RC1/
>
> Please cast your votes.
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Niall Pemberton <ni...@gmail.com>.
Couple more comments (sorry been digging around in the source code) -
the main issue IMO is deprecations
1) Deprecations
A number of classes have deprecations - I think these should be
removed prior to the first release of JCI:
JavaCompilerFactory - static instance (& accessor method) is deprecated
FileResourceReader - list() methods deprecated
MemoryResourceReader - list() method deprecated
FileResourceStore - list() methods deprecated
MemoryResourceStore - list() method deprecated
2) ConversionUtils
- The toJavaCasing() method is only used by JavaCompilerFactory -
perhaps should be a private method in JavaCompilerFactory?
- The clazzName() method is not used - should be removed?
3) Commons IO Dependency
The Commons IO dependency is only used by 3 classes
(ReloadingListener, FileResourceReader and FileResourceStore) and only
needs two IOUitls methods - toByteArray() and closeQuietly()
(FileResourceReader uses FileUtils but I think it could also use
IOUitls.toByteArray() instead).
Wouldn't it be better to copy these 2 methods and remove the need for
the Commons IO dependency?
If this isn't considered a good idea then theres a couple of methods
in ConversionUtils that could be replaced by Commons IO:
ConversionUtils.stripExtension() --> FilenameUtils.removeExtension()
ConversionUtils.getResourceNameFromFileName() -->
FilenameUtils.separatorsToUnix()
4) EclipseJavaCompilerSettings
The (package friendly) getMap() method of EclipseJavaCompilerSettings
overrides/fixes four of the settings in the Map - including setting
the source/target version at 1.4 - just wondering why and is this
correct?
Niall
On 4/11/07, Torsten Curdt <tc...@apache.org> wrote:
> Since RC1 is working fine for cocoon and other parties I would like
> to call a vote on the release for commons jci.
>
> http://jakarta.apache.org/commons/jci/
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-core/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-eclipse/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-fam/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-groovy/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-janino/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-javac/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-rhino/1.0-RC1/
>
> Please cast your votes.
>
> cheers
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> 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
Re: [vote] release commons jci RC1 as 1.0
Posted by Ashesh <as...@gmail.com>.
+1
Ashesh
On 4/10/07, Torsten Curdt <tc...@apache.org> wrote:
>
> Since RC1 is working fine for cocoon and other parties I would like
> to call a vote on the release for commons jci.
>
> http://jakarta.apache.org/commons/jci/
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-core/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-eclipse/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-fam/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-groovy/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-janino/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-javac/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-rhino/1.0-RC1/
>
> Please cast your votes.
>
> cheers
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [vote] release commons jci RC1 as 1.0
Posted by Torsten Curdt <tc...@apache.org>.
On 11.04.2007, at 23:33, Rahul Akolkar wrote:
> On 4/10/07, Torsten Curdt <tc...@apache.org> wrote:
>> Since RC1 is working fine for cocoon and other parties I would like
>> to call a vote on the release for commons jci.
>>
>> http://jakarta.apache.org/commons/jci/
>>
> <snip/>
>
> The site menus on all of the module sites seem broken (numerous 404s).
Ah ...bugger - missed those
> While its a cosmetic issue, it does make it hard to go through the
> site documentation.
>
>
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci/1.0-RC1/
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
>> commons/commons-jci-core/1.0-RC1/
> <snap/>
>
> No license and notice in above (core) jars. Stopped checking there.
Hm... thought maven would already include at least the license.
> I will try to help with some of this, if needed, but can't this week.
Any help appreciated.
We should probably solve the license/notice on the parent-pom level
but for now I'll try to fix it in the project pom.
cheers
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [vote] release commons jci RC1 as 1.0
Posted by Rahul Akolkar <ra...@gmail.com>.
On 4/10/07, Torsten Curdt <tc...@apache.org> wrote:
> Since RC1 is working fine for cocoon and other parties I would like
> to call a vote on the release for commons jci.
>
> http://jakarta.apache.org/commons/jci/
>
<snip/>
The site menus on all of the module sites seem broken (numerous 404s).
While its a cosmetic issue, it does make it hard to go through the
site documentation.
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-core/1.0-RC1/
<snap/>
No license and notice in above (core) jars. Stopped checking there.
I will try to help with some of this, if needed, but can't this week.
-Rahul
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-eclipse/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-fam/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-groovy/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-janino/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-javac/1.0-RC1/
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/
> commons/commons-jci-rhino/1.0-RC1/
>
> Please cast your votes.
>
> cheers
> --
> Torsten
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org