Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49C213A1.7070803@zeus.net.au>
Date: Thu, 19 Mar 2009 19:42:57 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: RIVER-272 Working Fix - Licensing?
References: <49BFC37A.2070407@zeus.net.au>
 <caf30e2a0903190040s433e6aaw9ec08502b70328a7@mail.gmail.com>
In-Reply-To: <caf30e2a0903190040s433e6aaw9ec08502b70328a7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Niclas Hedhman wrote:
> On Tue, Mar 17, 2009 at 11:36 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>
>   
>> How would one go about getting a ReplacementTools.jar library added to
>> River?  It isn't licensed under Apache v2.
>>     
>
> There is no way forward, as Jukka points out, and I think it was
> mentioned earlier as well; No GPL (nor LGPL for that matter) code in
> Apache repositories. Period.
> But, my question is; Doesn't Harmony contain the things needed
> already? If so, then there is a path forward (although I think it is
> less than important) as Harmony's sources are clean from a licensing
> point of view.
>   
The consensus is against continuing with ClassDep.java using tools.jar, 
apart from licensing & distribution issues, it has some functional 
shortcomings, it doesn't detect new language features like generics etc. 
Tim Blackman, Mark Brouwer, Patrick Wright and Peter Jones have 
indicated support for writing a new ClassDep tool utilising ASM, which 
appears a cleaner and more elegant solution, there also appears be some 
additional functionality possible. I've posted the code from Bantam 
ClassDepAnalyzer (thanks Patrick) in an earlier message, I'm hoping Tim 
is happy to submit his code too so we can play around with it.

The current consensus is to replace ClassDep with a new Class Dependency 
Analyser utilising the ASM Library.

Now all we need is a place in the repository to collaborate on the 
replacment ClassDepAnalyzer.  I'd also like to suggest including and 
using a custom namespace for the ASM library, Patrick pointed out on an 
earlier discussion that ASM's API is subject to change,  I suspect that 
this will settle down as the library matures, however in the mean time, 
we don't want it stepping on user code using different versions of ASM 
within the same namespace.

I believe we can get the River dev process firing on all cylinders 
again, lets concentrate on solutions and get this River flowing.  
Suggestion: When you highlight a problem to a proposed solution, don't 
get bogged down with the problem, suggest & investigate a number of 
solution options to choose from, this opens a discussion for new 
proposals and helps to identify arguments for and against each, when 
done correctly it's amazing how this accelerates learning, generates 
respect and builds a team.  We need input and direction from experienced 
developers who may not have the time to code, to guide us. 

River might simply be suffering from passionate ideologies and ongoing 
arguments causing experienced developers to loose interest in the list, 
lets keep them interested.

Best Regards,

Peter Firmstone.