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]

Reply via email to