Re: Distributions to include dependencies?

[Paulo Gaspar]

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 <[EMAIL PROTECTED]> wrote:
 

On Mon, 27 Dec 2004 22:23:30 -0500, Henri Yandell <[EMAIL PROTECTED]> wrote:
   

On Mon, 27 Dec 2004 15:48:00 -0800, Martin Cooper <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
     

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]