commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject Re: [vote] releasing jci RC3 as 1.0 ...maybe this time?
Date Tue, 05 Jun 2007 00:59:29 GMT
On 6/4/07, Torsten Curdt <> wrote:
> On 04.06.2007, at 06:49, Phil Steitz wrote:
> > Sigs and hashes check fine, but I had to grab your key from
> >  Make sure to add this
> > under JCI somewhere (see below)
> It's there
> RC3/KEYS.txt
> > * I think that for consistency and at least to provide a definitive
> > location for the release artifacts, KEYS, and release notes, we should
> > continue the practice of rolling combined zips/tarballs and putting
> > these on the mirrors under /dist/jakarta-commons.  The separate jars
> > in [cli] are pretty small, so the "who needs what" issue is not really
> > a big one here, IMO.
> So you are saying +1 for the assembly release ...but I don't get the
> "who needs what" part.

What I meant was that I did not see it as a big user inconvenience to
bundle all of the jars into a single release, since they are
individually small.  So, yes, I am +1 on putting together an assembly
and making it available, along with the KEYS file, on the commons
download page.

> > ** It is not clear to me how to build the binaries from the provided
> > sources.  The *sources* jars contain java source code. Do I need to
> > unpack this code with a common root and use the pom in
> > /org/apache/commons/commons-jci/1.0/commons-jci-1.0.pom?  I think we
> > should provide either a conventional source distribution or some
> > instructions on how to unpack and build the sources
> Hm... I don't see the source jars to be used for building the whole
> project but provide the sources for things like debugging.
> So if you want to build it from the source I would expect people to
> check it out of subversion. Anyone that is capable of building a
> project should be able to do a svn checkout to get the source for that.

ASF releases need to include source.  (See  Admittedly, publishing
jars to a maven repo puts us into a grey area.  I am not comfortable
going into that area though without a voted, full source,
validated-to-build release that the secondarily published artifacts
are part of.

> > * by itself is not a showstopper for me, but ** is.  I think a basic
> > requirement that we have is that release binaries can be built from
> > the sources in our distributions.  In the m1 days, we used to say
> > "maven clean dist" or at least "ant clean dist" needs to work from the
> > unpacked source distribution.  I don't care if it is a shell script,
> > ant, maven, or provided instructions, but users should have an obvious
> > and effective way to build from the sources in our releases.  Sorry if
> > I am just missing the obvious way to do this using m2.
> See above ...I think subversion is our source distribution. I don't
> really see a point in providing a classic source distribution. But
> maybe that's too much change for now ;)

Yes, too much for me at least.  In theory, voting on a tag and
pointing users there to get sources still could be viewed as a
release, but that is a big change from current practice and
inconvenient for users who prefer to build from release sources.  I
think we should always distribute the source with our releases.

I guess what we are really talking about here is "what is a release?"
and the link above is the only ASF definition that I can find.  Could
be I will come around to seeing it as OK one day to just push binaries
+ source jars to repos (after voting on these artifacts *plus* svn
tags) and direct those who want to build from source to the tags, but
I am just not there yet. Still seems to me that as part of the
release, we should roll (and eventually archive) an actual buildable
source distro.

> I'll prepare the assembly distributions and hope to get your +1 then :)

Of course!  I just need to be able to build it first :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message