river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Hurley <Jim.Hur...@Sun.COM>
Subject Re: VOTING ISSUE with apache-river-2.1.1-incubating
Date Mon, 24 Dec 2007 13:42:39 GMT
Thank you, Frank, for the effort... and everyone who has contributed
to the discussion.

Seems like a respin is our best course of action for the project --
so let's cancel the ongoing vote until we have a new candidate.

thanks -Jim

On Dec 24, 2007, at 4:00 AM, Frank Barnaby wrote:
> On Dec 23, 2007, at 17:39, Mark Brouwer wrote:
>> Frank Barnaby wrote:
>>> To be clear, the classes and jars both build fine by using the  
>>> "all" and "jars" ant targets.  The javadoc no longer builds for  
>>> the end user because of the addition of the url pointing to the  
>>> NOTICE file to allow for stand-alone javadoc distributions.  The  
>>> release zip files also cannot be generated through the use of the  
>>> "build.release" target.  While the javadoc should build for the  
>>> end user, we never intended the end user to build release  
>>> bundles.  However, I think it looks bad to have a build target  
>>> that fails for the end user--I agree that we should either fix it  
>>> or remove it from the end user build scripts.
>>> By fixing the javadoc end-user build, the release build will be  
>>> fixed as well.  The fix will require me to add the NOTICE and  
>>> LICENSE files to the source sub-directory in the source  
>>> distribution.  Note that the source distribution already contains  
>>> the NOTICE and LICENSE files in the top level, but the doc and  
>>> release builds are not aware of those top-level files.  After  
>>> committing the changes, I'll generate another release, another  
>>> set of corresponding signature and check-sum files, upload the  
>>> files to people-apache.org, some folks can do some sanity tests,  
>>> and we can start another vote.  Did I overlook any steps?
>>> Is this course of action we want to pursue?
>> Hi Frank,
>> I did indeed build with build.release because I believe an end user
>> should be able to build a release as well.
>> Also as I'm a newbie with regard to building the JTSK (I'm a source
>> consumer), as there is no README or build instruction file (something
>> for AR2?) it was unclear as what build targets I was supposed to  
>> execute
>> (besides the default of 'all').
> The top-level doc directory in the source release contains
> build.html, which provides a few instructions for building.  That
> location was sufficient when we did not provide a release-build
> target.  Now that such a target is available to the end users,
> however, the source release should also contain the build.html file.
> This issue also illuminates the need for a few other doc files to
> be added to the source sub-directory of the source release-bundle
> in support of end-user release builds.
>> I would fix it by copying the NOTICE and LICENSE files into the  
>> source
>> distribution, while doing that I would also add source="1.4" in the
>> javac tasks in the the build files because I was kind of irritated by
>> that one too and had to set my JAVA_HOME to an 1.4.2 JDK (this is not
>> a complete fix for RIVER-212 but it is just 60 seconds of work and
>> prevents from other people being confronted with the issue until  
>> AR2 is
>> out the door for which we don't know how long it takes).
> The "javac-cmd" macro-def already contains "source=1.4", and I
> believe that option has been included since at least version 2.0.
> Am I missing something here?
>> I also would suggest to fix Niclas's issue because otherwise no doubt
>> this issue pops up during the vote for Incubator and we don't know  
>> the
>> outcome.
> I agree--it's a simple addition and would provide a useful level
> of clarity.  Is there an Apache template for such a disclaimer or
> should we simply create the file from scratch, basing it on project
> Wicket's disclaimer?
>> If you need a hand, let me know so I can help out.
> Thank you--I appreciate the offer.  So far, the changes are simple
> enough for me to handle in short order.  In fact, most of the work
> is already complete.  Though, I would appreciate a review after I
> commit the changes and extra eyes to examine the resulting bundles.
> Frank
>> -- 
>> Mark

View raw message