Left Craig's til last :)
Comments inline...
On Wed, 13 Aug 2003, Craig R. McClanahan wrote:
> Comments interspersed.
>
> On Thu, 14 Aug 2003, Henri Yandell wrote:
>
> > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> > From: Henri Yandell <[EMAIL PROTECTED]>
> >
> > This is the biggest complaint about Commons at the moment [I think], that
> > we have some kind of reproduction of jars going on in which more and more
> > jars appear in the user's code.
> >
>
> That was one issue. Another was the potential for having different
> packages require different versions of the same commons package.
Yep. Combo releases solve this internally, but not as a reusable jar. If
Tomcat wants to use Collections 2.1 and Lang-SNAPSHOT, but Collections 2.1
relies on Lang 1.0, they would be screwed either way :)
> > I'd like to consider a release as such from Combo of what some of us were
> > calling Commons Core a while back. It's an implementation of the Combo
> > ant-scripts [currently I copy and paste, but it shouldn't be hard for me
> > to make a single build.xml and a shared properties file per
> > 'distribution' with enough Ant learning].
> >
> > My current criteria is that Commons Core _only_ depends on JDK1.4 [and
> > cross-dependencies inside the distribution]. Currently I have:
>
> Trying to define "combo" as anything other than "the latest released
> version of every Commons package" seems like it's guaranteed to cause
> arguments. The collection you propose below, for example, is totally
> useless to me and all the projects I work on. But commons-combo as it is
> currently built would be useful to me, and to you, and to anyone else.
Not really. Commons-combo as it is is a huge jar [which is acceptable] and
more importantly has a huge huge list of dependencies.
Now I'm going to be sneaky :)
[in another mail] Craig:
"Makes sense to me. All three of those packages are the right sort of
scale (self contained class libraries) that Commons was designed to deal
with."
I like this. To me it means: Must be dependant solely on a JVM version
at runtime, [We accept compile time dependency on JUnit for the tests].
Commons-Logging: log4j. logkit. avalon-framework.
Latka: ant. ant-optional. commons-jelly. jaxen. commons-logging. jdom.
dom4j. regexp. saxpath. log4j. servletapi. xalan. xerces.
xml-apis. commons-jexl.
Digester : commons-logging. xml-apis.
Modeler : commons-digester. commons-logging. mx4j-jmx. mx4j-tools. xml-apis.
etc etc. These are not self-contained. What's your definition of
self-contained?
> > I'm doing some trickery to turn BeanUtils' commons-logging dependency into
> > a JDK1.4 util.logging dependency. It would be nice to add Pool, HttpClient
> > and maybe Net [with some regexp trickery] and consider that a version 1.0.
> >
>
> We can talk about that on a [beanutils] specific thread, but I'd be -1 on
> doing this to the real BeanUtils code. A very large number of BeanUtils
> users do not have the luxury to run on a 1.4 JDK.
Yeah, I've no desire to apply this to the BeanUtils code itself, and doing
said munging concerns me that we might introduce bugs. However,
commons-logging is not self-contained and therefore would invalidate
commons-beanutils.
The reason for JDK 1.4 is due to trying to get more in. I think a JDK1.2
version should exist too, but it would not contain HttpClient (?) which I
thought might be 1.4 dependant now for SSL and would not include BeanUtils
with the current api munging.
> > Issues I forsee
> > ===============
> >
> > *) Combo has never been voted into Commons-proper. How do we handle this?
> > It's not a new codebase but a release mechanism.
> >
>
> It should be voted as a formal package (with a defined release mechansim
> like "every time an included package rolls a new release, then roll a new
> combo release as well.")
+1. If this discussion can find common ground, I'll push for such a vote.
> Of course, this is going to run into difficulties if/when included
> packages start making backwards-incompatible API changes (like on version
> 1.x to version 2.x transitions), but so far Commons developers have been
> pretty sensitive to that.
It'll be a learning experience :)
> > 1) Can I treat Combo as a Commons Proper project.
> > 2) Is the idea of a Commons Core distribution viable.
>
>
> I'm -1 on subsetting commons-combo to be less than a combination of all
> released Commons packages. Trying to say what things are "core" and what
> are not is just fodder for flamewars.
Yep. We had that last time and there was no set of rules which could
dictate what was 'core'. At the same time, a release of the entire of
Commons would be utterly wrong I think. Therefore my rules [stealing your
language] are:
* Projects [or project components] must be self-contained, meaning
projects must rely on a static list of dependencies [per JVM].
* Projects must be in Jakarta Commons. [Over time we could open up to Xml
Commons and Apache Commons, but so far there are no qualified
candidates].
Configuration files make me a little queasy. Unsure whether a project that
relies on those can happily be in a combined jar. Seems there's no reason
to stop them.
I think there should be two defined environments:
JDK 1.4
JDK 1.2 + jars to make it 1.4-like
Currently only xml-apis.jar seems like an obvious addition to JDK 1.2.
> I'm +0 on setting up the combo build.xml file in such a way that you can
> do your own custom subsets.
Cool.
So that's what I think anyway :) Everything in Commons which is
self-contained should go in. Forcing a user of three api's to grab
dependencies for 12 other api's is going to kill combo dead in the water.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
