Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41D46DB5.20402@kebom.net>
Date: Thu, 30 Dec 2004 21:05:57 +0000
From: Paulo Gaspar <dev.apache@kebom.net>
Reply-To: dev.apache@kebom.net
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: Distributions to include dependencies?
References: <31cc37360412271338311b9d3f@mail.gmail.com>
	 <16d6c6200412271548216a1ce2@mail.gmail.com>
	 <31cc373604122716581ea111ec@mail.gmail.com>
	 <31cc373604122719237a92febf@mail.gmail.com>
	 <16d6c62004122811102f13ea2a@mail.gmail.com>
 <31cc3736041228144046d11990@mail.gmail.com>
In-Reply-To: <31cc3736041228144046d11990@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sometimes it is even difficult to define what are those dependencies, 
because it depends on the use
cases.

An example of this that got me by surprise is the HttpClient. Some time 
ago I had to import the
Commons HttpClient into an Oracle Database.

By default, Oracle's import tool tries to import all dependencies it 
finds in the Java code, and also those
dependencies's dependencies, and so on. Sometimes I just add those 
dependencies... but this time I
had to use that command line option that tells the import tool "I know 
better and stop bugging me",
because, although the HttpClient has a huge POTENTIAL dependency chain.

Potential because, OTOH, HttpClient needs almost nothing else for the 
simplest use cases and only
gets to need a lot of extra stuff for optional functionality.

So, although you need nothing for the simplest uses of HttpClient, to 
provide the dependencies for
all the use cases you would have to build a huge download.

I am not against providing downloads with all the dependencies but 
PLEASE make it optional. Also
allow us to download the basic binaries alone.

I think it is wiser to let each project decide what is convenient for 
their users - the current situation,
I think.

With my best regards,
Paulo Gaspar

Henri Yandell wrote:

>Curse you and your valid points :)
>
>Next step for me is to work out just how much of Commons is affected
>by your points. If it's just a particular component, then we work
>around it (ie don't put the things in the dist, same as the current
>situation).
>
>One positive is that if we manually place a javamail/activation in our
>local repo prior to a build; it's actually legal for us to put it in
>the distribution.
>
>I'll come up with some concrete examples and propose those, including
>byte-size increases in tar.gz files.
>
>Hen
>
>On Tue, 28 Dec 2004 11:10:21 -0800, Martin Cooper <mfncooper@gmail.com> wrote:
>  
>
>>On Mon, 27 Dec 2004 22:23:30 -0500, Henri Yandell <flamefew@gmail.com> wrote:
>>    
>>
>>>>On Mon, 27 Dec 2004 15:48:00 -0800, Martin Cooper <mfncooper@gmail.com> wrote:
>>>>
>>>>        
>>>>
>>>>>Not me. Doing this will lead to people having multiple copies of
>>>>>various component jars lying around on their disks, and will
>>>>>unnecessarily increase the amount of stuff that people need to
>>>>>download.
>>>>>          
>>>>>
>>>Definitely true, but it's petty change however. The people who have
>>>this problem (clutter) are likely to have this problem already.
>>>      
>>>
>>Whether or not it's petty change depends on (a) how you define
>>dependencies (see below), and (b) your network connection. People
>>still using dial-up connections (and there are still a lot of them)
>>will not appreciate the extra download times, especially for stuff
>>they already have.
>>
>>    
>>
>>>>>For example, suppose I use Digester and Betwixt. I download them both,
>>>>>and now I have two copies of Digester, BeanUtils and Logging. But if I
>>>>>actually wanted to use BeanUtils itself, I'd need to download it
>>>>>again, because I only have the jar file, and not the JavaDocs or other
>>>>>contents of the distro.
>>>>>          
>>>>>
>>>This partly leads me on to a different issue that I think we need to
>>>improve; Javadoc management; but I don't think this is a very big
>>>deal.
>>>      
>>>
>>See (b) above.
>>
>>    
>>
>>>>>It's also not clear to me that every component is going to comprise a
>>>>>single jar for the purposes of inclusion into another distro. In such
>>>>>cases, there would need to be some well-defined structure for the
>>>>>additional files.
>>>>>          
>>>>>
>>>This is already solved in the project.xml.
>>>      
>>>
>>I don't get this. If component A requires component B, how does
>>component A's project.xml know which files need to be picked up from
>>component B, especially if they're not jar files? Even if there is an
>>explicit list in component A's project.xml file, this seems very
>>fragile to me, since A has to know too much about B.
>>
>>    
>>
>>>>>One more: How do you define dependencies? What happens in cases such
>>>>>as Resources, where there are multiple optional implementations? Do we
>>>>>include all of them, or just some of them, and how would we decide?
>>>>>          
>>>>>
>>>project.xml. You add a property to each dependency that you wish to
>>>include in the distribution. For an example like Resources, I've no
>>>idea. I imagine it would depend on the particular situation.
>>>      
>>>
>>I assume you're talking about using the <dependency> element here. But
>>that won't work (I don't think) for non-jar dependencies, because
>>Maven uses these elements to construct the compilation classpath as
>>well.
>>
>>Also, if component X comprises an API jar and an impl jar, I
>>specifically don't want to include the impl jar in a <depepdency>
>>element, to ensure that the impl isn't on the compilation classpath
>>(and so ensure that I'm not depending on a specific implementation). I
>>don't see how the impl jar will be picked up and included in the
>>'dependencies' directory in this case.
>>
>>--
>>Martin Cooper
>>
>>    
>>
>>>Hen
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>>
>>>
>>>      
>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org