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]
