On 6/4/07, Torsten Curdt <[EMAIL PROTECTED]> wrote:
On 04.06.2007, at 06:49, Phil Steitz wrote: > Sigs and hashes check fine, but I had to grab your key from > http://www.apache.org/dist/jakarta/bcel/KEYS. Make sure to add this > under JCI somewhere (see below) It's there http://svn.apache.org/repos/asf/jakarta/commons/proper/jci/tags/1.0- 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 http://www.apache.org/dev/release.html#what.) 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 :) Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
