On 8 Sep 2010, at 15:40, Carl Trieloff wrote:

> On 09/08/2010 10:29 AM, Scott Wilson wrote:
>> On 8 Sep 2010, at 15:13, Carl Trieloff wrote:
>> 
>>   
>>> What is the view of having a project in Apache that pulls substantial 
>>> components
>>> that are licensed under ASL as dependencies into the code base. I.e. not 
>>> coping the
>>> code, but using components that have been built and maintained elsewhere 
>>> under ASL
>>> but used as dependencies for running.
>>> 
>>> I assume this is not an issue, based in the info posted on use of licenses 
>>> -- however I'm
>>> interested in understand if others have had positive or negative 
>>> experiences with such
>>> a case.
>>>     
>> Hi Carl,
>> 
>> Wookie has been using Ivy[1] to pull in external dependencies as part of the 
>> build process. It took a bit of initial effort to get right, but now works 
>> really nicely, and makes it much easier to track external libraries and 
>> check their licenses are compatible.  You can also distinguish between 
>> dependencies that are needed for development, for building, and for 
>> distribution and downstream reuse. There is an Eclipse plugin for Ivy that 
>> works pretty well too.
>> 
>> The only vaguely negative thing I found was the initial challenge of getting 
>> the hang of how Ivy works, but we had good help from other community members 
>> and from our mentors on that.
>> 
>> [1] http://ant.apache.org/ivy/
>> 
>> - Scott
>> 
>>   
> 
> Scott,
> 
> Do you see any negative sides from the community perspective with the 
> dependencies that or from projects
> outside of Apache?
> 
> Carl.

I think it depends on the nature of the project you depend on. For the most 
part these are pretty mature, commonly used libraries. 

However in one case we did have the issue that we had a problem that was caused 
by a bug in a dependency (HtmlCleaner) where it wasn't very clear from the 
website whether the project was still active (patches not applied, no recent 
commits etc). In the end I just asked nicely on their tracker if it could be 
fixed, waited patiently, and eventually it was :-) 

I can imagine there might be problems if you got into a blame game with 
upstream projects, or where there is a combination of a big culture difference 
plus an unstable codebase. I think the answer is to evaluate dependencies from 
a community and sustainability viewpoint, not just a functional one.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to