You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/08/14 06:02:52 UTC
[combo] Commons Core release?
Last November [I think] Craig created the Combo project. It puts a whole
lot of Commons projects into one jar and makes them available in a much
simpler form to users.
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.
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:
=====
Apache Commons Core v1.0 consists of:
Jakarta Commons BeanUtils 1.6.1
Makes the JavaBean specification easier to deal with.
Jakarta Commons CLI 1.0
A command line interpreter. Used to handle all the flags passed to your
program on the command line.
Jakarta Commons Codec 1.1
Common encoders and decoders.
Jakarta Commons Collections 2.1
Many more implementations that fit the Collections API.
Jakarta Commons Lang 1.0.1
Enhancements to classes found in java.lang.
=======
A url to a build is: http://www.apache.org/~bayard/commons-core/
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.
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.
*) Arguments over what goes in what. Rather than create a huge jar of
everything, which I think is unpalatable to the user, I chose the JDK 1.4
dependency as a strict guideline and tried to make things toe the line.
Effectively it's a Commons-J2SE distribution for adding features to a
new J2SE install.
*) Testing. In Core 1.0 I've chosen the latest stable releases [except
HttpClient which is at RC2] of each project. There are no
interdependencies, but as projects depend on each other the building of a
combo jar becomes trickier. This is a problem for the future probably.
Possibly the solution is that after each component is built/tested, and
the new uber-jar is built, the tests should be re-run against that jar.
====
My general idea for Combo is that it is a tool for creating distributions
of Commons code. These distributions are effectively configurations of
Combo. I'm not sure if Craig is +1 or -1 for this and what his
original plans were, but I think there's a need for a solution and that
this is a solution.
No idea if it's a good solution :) It seems quite fun and interesting.
Any ideas? Flames?
My chief two concerns are:
1) Can I treat Combo as a Commons Proper project.
2) Is the idea of a Commons Core distribution viable.
Hen
Re: [combo] Commons Core release?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I haven't added to the debate up till now as I wanted to see how things
went.
Firstly, my definition of 'core' is basic extensions to the JDK, no config
files, no logging, no framework.
lang
io
collections
codec (never looked at it, but may fit)
cli?? (never looked at it, but may be more framework like)
BeanUtils ought to be included, however it has been written to use logging.
I believe this to be wrong, but this is an old decision, hard to change.
JDK1.2 should be the baseline.
However, it is clear that this division is just one of many that can occur.
It makes most sense to me, but others disagree. Given the current commons
structure I would suggest agreement on the contents of core is highly
unlikely.
One way out would be a separate mailing list, or maybe a separate
Jakarta-Core subproject. Then a single release could be created. However,
this also seems to fail the reality check.
Originally, I supported commons core, by promoting collections, io, pattern
(deceased), beanutils to all depend on lang, thus forming a nice group. Now
it seems that the more independent absolute minimum dependencies route is
actually simpler for everyone. A little code duplication may occur, but that
is better than additional dependencies.
My answer to the users - just deal with the jars. Its not that hard, and
creating a combo or core jar creates really nasty versioning issues, as
commons projects release to their own timescales, not one. One product = One
jar.
Stephen
NOTE: If Java was OSS and we were in charge of adding new functions to the
JDK, matters might be different. But as outside libraries, the midset must
be different.
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
>
> 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.
>
> 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:
>
> =====
> Apache Commons Core v1.0 consists of:
>
> Jakarta Commons BeanUtils 1.6.1
> Makes the JavaBean specification easier to deal with.
>
> Jakarta Commons CLI 1.0
> A command line interpreter. Used to handle all the flags passed to
your
> program on the command line.
>
> Jakarta Commons Codec 1.1
> Common encoders and decoders.
>
> Jakarta Commons Collections 2.1
> Many more implementations that fit the Collections API.
>
> Jakarta Commons Lang 1.0.1
> Enhancements to classes found in java.lang.
> =======
>
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
>
> 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.
>
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
>
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
>
> ====
>
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
>
> No idea if it's a good solution :) It seems quite fun and interesting.
>
> Any ideas? Flames?
>
> My chief two concerns are:
>
>
> 1) Can I treat Combo as a Commons Proper project.
> 2) Is the idea of a Commons Core distribution viable.
>
>
> Hen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Tomasz Pik wrote:
> A little different idea:
> How about creating plugin for Maven that will repackage
> all libraries defined as dependency into one jar?
> (note problem with MANIFEST file here).
> Then everybody may create own 'combo' just by writing
> project.xml file.
Two things needed for this I think.
1) Record JVM requirements in the POM. Unsure if Maven does this yet, I've
not found anything about it online.
2) Upload POMs to repositories so that dependencies of dependencies may be
placed in the jar. Or created as a README.
Otherwise, it's a good build mechanism and would hopefully replace the
combo ant scripts.
> I know it's different idea then releasing 'combo' as
> separate package but this will help developers avoid
> having many jars used in their apps without releasing
> new combo every new commons core package.
Unsure. I think we'd still use it as a tool to release something. The
users who most want a combo-jar are not hte users who want to sit and
define their own POMs etc.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Tomasz Pik wrote:
> A little different idea:
> How about creating plugin for Maven that will repackage
> all libraries defined as dependency into one jar?
> (note problem with MANIFEST file here).
> Then everybody may create own 'combo' just by writing
> project.xml file.
Two things needed for this I think.
1) Record JVM requirements in the POM. Unsure if Maven does this yet, I've
not found anything about it online.
2) Upload POMs to repositories so that dependencies of dependencies may be
placed in the jar. Or created as a README.
Otherwise, it's a good build mechanism and would hopefully replace the
combo ant scripts.
> I know it's different idea then releasing 'combo' as
> separate package but this will help developers avoid
> having many jars used in their apps without releasing
> new combo every new commons core package.
Unsure. I think we'd still use it as a tool to release something. The
users who most want a combo-jar are not hte users who want to sit and
define their own POMs etc.
Hen
Re: [combo] Commons Core release?
Posted by Tomasz Pik <pi...@ais.pl>.
A little different idea:
How about creating plugin for Maven that will repackage
all libraries defined as dependency into one jar?
(note problem with MANIFEST file here).
Then everybody may create own 'combo' just by writing
project.xml file.
I know it's different idea then releasing 'combo' as
separate package but this will help developers avoid
having many jars used in their apps without releasing
new combo every new commons core package.
And I think that discussion, what should be included
in combo will be the longest thread on this list...
Regards,
Tomek
PS There's 'uberjar' plugin but it's working like this.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Tomasz Pik wrote:
> Henri Yandell wrote:
> >
> > I figured the munging would be unlikely to pass muster. The easy solution
> > is that BeanUtils/Net are not allowed into a combo-distribution until
> > their dependencies are. So ORO/commons-logging would have to be in it. One
> > problem there is commons-logging's dependency on log4j, logkit and
> > avalon-framework.
>
> Two points here;
> 1. here was a disussion of splitting logging into 'api' and
> implementation jars but I don't know what's with this idea;
> 2. it's compile-time dependency rather then runtime;
> I'm also concerned about recompilation of the code.
> Note that official release of component comes in source and
> binary (compiled) version. And sometimes recompilation may
> make code different (OK, I know, in most cases it's J2SE1.4
> problem with StringBuffer.append(StringBuffer) but...).
Yep. Splitting proejcts up is the way to handle such things. With an
implementation version that does not depend, another one dependent on
jdk14 in this instance etc.
Combo builds against cvs tags, so as long as the same compiler is used
things are fine I think. The problem there is that choice of compiler is
not defined in Commons. Not really a Combo issue as such but a
cross-Commons issue. Possibly release builds should all occur on some
standard machine [nagoya or something].
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Tomasz Pik wrote:
> Henri Yandell wrote:
> >
> > I figured the munging would be unlikely to pass muster. The easy solution
> > is that BeanUtils/Net are not allowed into a combo-distribution until
> > their dependencies are. So ORO/commons-logging would have to be in it. One
> > problem there is commons-logging's dependency on log4j, logkit and
> > avalon-framework.
>
> Two points here;
> 1. here was a disussion of splitting logging into 'api' and
> implementation jars but I don't know what's with this idea;
> 2. it's compile-time dependency rather then runtime;
> I'm also concerned about recompilation of the code.
> Note that official release of component comes in source and
> binary (compiled) version. And sometimes recompilation may
> make code different (OK, I know, in most cases it's J2SE1.4
> problem with StringBuffer.append(StringBuffer) but...).
Yep. Splitting proejcts up is the way to handle such things. With an
implementation version that does not depend, another one dependent on
jdk14 in this instance etc.
Combo builds against cvs tags, so as long as the same compiler is used
things are fine I think. The problem there is that choice of compiler is
not defined in Commons. Not really a Combo issue as such but a
cross-Commons issue. Possibly release builds should all occur on some
standard machine [nagoya or something].
Hen
Re: [combo] Commons Core release?
Posted by Tomasz Pik <pi...@ais.pl>.
Henri Yandell wrote:
>
> I figured the munging would be unlikely to pass muster. The easy solution
> is that BeanUtils/Net are not allowed into a combo-distribution until
> their dependencies are. So ORO/commons-logging would have to be in it. One
> problem there is commons-logging's dependency on log4j, logkit and
> avalon-framework.
Two points here;
1. here was a disussion of splitting logging into 'api' and
implementation jars but I don't know what's with this idea;
2. it's compile-time dependency rather then runtime;
I'm also concerned about recompilation of the code.
Note that official release of component comes in source and
binary (compiled) version. And sometimes recompilation may
make code different (OK, I know, in most cases it's J2SE1.4
problem with StringBuffer.append(StringBuffer) but...).
Regards,
Tomek
> I suspect Commons-Regexp [merger of ORO/Regexp] is far more likely to
> occur and pass the rules I set out than Logging.
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Tomasz Pik <pi...@ais.pl>.
Henri Yandell wrote:
>
> I figured the munging would be unlikely to pass muster. The easy solution
> is that BeanUtils/Net are not allowed into a combo-distribution until
> their dependencies are. So ORO/commons-logging would have to be in it. One
> problem there is commons-logging's dependency on log4j, logkit and
> avalon-framework.
Two points here;
1. here was a disussion of splitting logging into 'api' and
implementation jars but I don't know what's with this idea;
2. it's compile-time dependency rather then runtime;
I'm also concerned about recompilation of the code.
Note that official release of component comes in source and
binary (compiled) version. And sometimes recompilation may
make code different (OK, I know, in most cases it's J2SE1.4
problem with StringBuffer.append(StringBuffer) but...).
Regards,
Tomek
> I suspect Commons-Regexp [merger of ORO/Regexp] is far more likely to
> occur and pass the rules I set out than Logging.
>
> Hen
Re: [combo] Commons Core release?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, August 14, 2003, at 12:29 PM, Henri Yandell wrote:
<snip>
> I figured the munging would be unlikely to pass muster. The easy solution
> is that BeanUtils/Net are not allowed into a combo-distribution until
> their dependencies are. So ORO/commons-logging would have to be in it. One
> problem there is commons-logging's dependency on log4j, logkit and
> avalon-framework.
i've been thinking for a while that several components will soon be
reaching the stage commons logging reached a while ago. digester and
beanutils (for example) are going to want to add non-core dependencies
for optional plugins sometime soonish.
commons-logging does not require log4j, logkit or avalon-framework to
function in it's basic configuration. the case (when the time comes) will
be similar for digester and beanutils. additional dependencies will be
required if the user wants to plugin some optional functional but not to
for the core component.
i think that there a strong case to be made that it's only core
dependencies that should concern the assemblers of the combo bundle. it is
therefore not unreasonable to include commons-logging (and any commons
components that depend on it) within a combo release.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, August 14, 2003, at 12:29 PM, Henri Yandell wrote:
<snip>
> I figured the munging would be unlikely to pass muster. The easy solution
> is that BeanUtils/Net are not allowed into a combo-distribution until
> their dependencies are. So ORO/commons-logging would have to be in it. One
> problem there is commons-logging's dependency on log4j, logkit and
> avalon-framework.
i've been thinking for a while that several components will soon be
reaching the stage commons logging reached a while ago. digester and
beanutils (for example) are going to want to add non-core dependencies
for optional plugins sometime soonish.
commons-logging does not require log4j, logkit or avalon-framework to
function in it's basic configuration. the case (when the time comes) will
be similar for digester and beanutils. additional dependencies will be
required if the user wants to plugin some optional functional but not to
for the core component.
i think that there a strong case to be made that it's only core
dependencies that should concern the assemblers of the combo bundle. it is
therefore not unreasonable to include commons-logging (and any commons
components that depend on it) within a combo release.
- robert
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Tomasz Pik wrote:
> Henri Yandell wrote:
> > A url to a build is: http://www.apache.org/~bayard/commons-core/
> >
> > 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.
>
> That's something that I think should be avoided.
> Combo (IMHO) should be a jar containing classes/resources voted
> as releases.
> If developer will pick up Combo described by a list of packages
> included, (s)he must be sure that Combo jar may be replaced by
> those packages as they are downloadable jars.
> With such regexp magic it's not so obvious.
I figured the munging would be unlikely to pass muster. The easy solution
is that BeanUtils/Net are not allowed into a combo-distribution until
their dependencies are. So ORO/commons-logging would have to be in it. One
problem there is commons-logging's dependency on log4j, logkit and
avalon-framework.
I suspect Commons-Regexp [merger of ORO/Regexp] is far more likely to
occur and pass the rules I set out than Logging.
Hen
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Tomasz Pik wrote:
> Henri Yandell wrote:
> > A url to a build is: http://www.apache.org/~bayard/commons-core/
> >
> > 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.
>
> That's something that I think should be avoided.
> Combo (IMHO) should be a jar containing classes/resources voted
> as releases.
> If developer will pick up Combo described by a list of packages
> included, (s)he must be sure that Combo jar may be replaced by
> those packages as they are downloadable jars.
> With such regexp magic it's not so obvious.
I figured the munging would be unlikely to pass muster. The easy solution
is that BeanUtils/Net are not allowed into a combo-distribution until
their dependencies are. So ORO/commons-logging would have to be in it. One
problem there is commons-logging's dependency on log4j, logkit and
avalon-framework.
I suspect Commons-Regexp [merger of ORO/Regexp] is far more likely to
occur and pass the rules I set out than Logging.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Tomasz Pik <pi...@ais.pl>.
Henri Yandell wrote:
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
That's something that I think should be avoided.
Combo (IMHO) should be a jar containing classes/resources voted
as releases.
If developer will pick up Combo described by a list of packages
included, (s)he must be sure that Combo jar may be replaced by
those packages as they are downloadable jars.
With such regexp magic it's not so obvious.
Regards,
Tomek
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Wed, 13 Aug 2003 23:25:31 -0700 (PDT)
"Craig R. McClanahan" <cr...@apache.org> wrote:
> For those who wonder why such a combination JAR is important, please
> hang around on the user lists, not just the developer lists :-).
Aha. Okay.
Please see,
http://www.apache.org/~tetsuya/jars/
... for those lurk in common-users/dev :-)
All the jars in /www/www.apache.org/dist/jakarta/commons/
, ecs, log4j, ant, velocity, oro and regexp ... near 4MB ..
(without ant and velocity, it will be less than 3MB ..)
Those who can download JDK/JRE will be able to download it, too
... perhaps. :D
Sincerely,
-- Tetsuya (tetsuya@apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Wed, 13 Aug 2003 23:25:31 -0700 (PDT)
"Craig R. McClanahan" <cr...@apache.org> wrote:
> For those who wonder why such a combination JAR is important, please
> hang around on the user lists, not just the developer lists :-).
Aha. Okay.
Please see,
http://www.apache.org/~tetsuya/jars/
... for those lurk in common-users/dev :-)
All the jars in /www/www.apache.org/dist/jakarta/commons/
, ecs, log4j, ant, velocity, oro and regexp ... near 4MB ..
(without ant and velocity, it will be less than 3MB ..)
Those who can download JDK/JRE will be able to download it, too
... perhaps. :D
Sincerely,
-- Tetsuya (tetsuya@apache.org)
Re: [combo] Commons Core release?
Posted by "Stanley,Michael P." <ms...@mitre.org>.
>I knew that these kind of objections would occur if we thought
>this package *in* "Jakarta"-Commons Dev list.
>
>
>Briefly, ... How about Apache Commons?
>
>Keep the tiny commons.jakarta packages as they are and Apache
>Commons (http://commons.apache.org/) provides the mixture of
>Jakarta-Commons, DB-Commons, XML-Commons etc.... Perfect! ;-)
>
>Jakarta-Commons would be as it is ... no change.
>
Well, I think the suggestion I made is still valid (and even more so) in
this scenario. I think providing a utility (that can be used
interactively, or from a build utility, conf file, etc) to combine
multiple commons components (be it Jakarta, DB, or XML-Commons) into a
single jar is more beneficial than creating a "Apache Commons
Distribution". My suggestion does not come from the "creating a
commons out of the commons" complaint, but rather dependency/version
management in Java is not easy. Keeping dependencies (especially
commons) tightly packaged and independently revisioned is necessary.
Again, to help create a single distribution, create a configuration
utility that lets this distribution be built (easily, and automatically)
by the end user rather than a community voting on releases, combo
version numbers, etc... Not only does this resolve your issue but it
lets existing projects that use a variety of commons to create default
configurations for themselves. I know this would make my life easier,
and I know an "apache commons distribution" will definitely not.
- Mike
>
>
>-- Tetsuya (tetsuya@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
Re: [combo] Commons Core release?
Posted by "Stanley,Michael P." <ms...@mitre.org>.
>Nobody is talking about eliminating the individual releases. The question
>is whether or not we should offer an *additional* combination package of
>some sort, and what it should contain. One can certainly extend the
>concept recursively beyond Jakarta Commons, but something like this is
>going to align on language lines anyway -- and Jakarta Commons is already
>only about Java based packages.
>
I understand this. But I do feel that the inclusion of a "combination"
distribution will create more confusion and conflicts down the road. I
agree something needs to be done to make it easier to use a large set of
different commons packages but I think that a tool that puts this
together based on some known combinations, is a win-win.
>For those who wonder why such a combination JAR is important, please hang
>around on the user lists, not just the developer lists :-).
>
I'm on both ;-)
- Mike
>
>
>
>>-- Tetsuya (tetsuya@apache.org)
>>
>>
>>
>>
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [combo] Commons Core release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
> Date: Thu, 14 Aug 2003 15:14:10 +0900
> From: Tetsuya Kitahata <te...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [combo] Commons Core release?
>
>
> On Thu, 14 Aug 2003 15:58:45 +1000
> "Vikram Goyal" <v....@uq.edu.au> wrote:
>
> > > -1 on any combination. Core / Combo - whatever. I think it is a bad
> > > idea.
> > Agree with you that it is a bad idea. Commons was supposed to be it.
> > Its like trying to factor out a "Commons" out of Commons. I can see
> > the nightmare and the trouble people will have trying to understand
> > what a "Combo" is out of Commons. Developers are sensible enough to
> > realise and factor out common jars. Agreed that it takes time but hey,
> > thats what we are paid for.
>
> I knew that these kind of objections would occur if we thought
> this package *in* "Jakarta"-Commons Dev list.
>
>
> Briefly, ... How about Apache Commons?
>
> Keep the tiny commons.jakarta packages as they are and Apache
> Commons (http://commons.apache.org/) provides the mixture of
> Jakarta-Commons, DB-Commons, XML-Commons etc.... Perfect! ;-)
>
> Jakarta-Commons would be as it is ... no change.
>
>
Nobody is talking about eliminating the individual releases. The question
is whether or not we should offer an *additional* combination package of
some sort, and what it should contain. One can certainly extend the
concept recursively beyond Jakarta Commons, but something like this is
going to align on language lines anyway -- and Jakarta Commons is already
only about Java based packages.
For those who wonder why such a combination JAR is important, please hang
around on the user lists, not just the developer lists :-).
> -- Tetsuya (tetsuya@apache.org)
>
>
Craig
Re: [combo] Commons Core release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
> Date: Thu, 14 Aug 2003 15:14:10 +0900
> From: Tetsuya Kitahata <te...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [combo] Commons Core release?
>
>
> On Thu, 14 Aug 2003 15:58:45 +1000
> "Vikram Goyal" <v....@uq.edu.au> wrote:
>
> > > -1 on any combination. Core / Combo - whatever. I think it is a bad
> > > idea.
> > Agree with you that it is a bad idea. Commons was supposed to be it.
> > Its like trying to factor out a "Commons" out of Commons. I can see
> > the nightmare and the trouble people will have trying to understand
> > what a "Combo" is out of Commons. Developers are sensible enough to
> > realise and factor out common jars. Agreed that it takes time but hey,
> > thats what we are paid for.
>
> I knew that these kind of objections would occur if we thought
> this package *in* "Jakarta"-Commons Dev list.
>
>
> Briefly, ... How about Apache Commons?
>
> Keep the tiny commons.jakarta packages as they are and Apache
> Commons (http://commons.apache.org/) provides the mixture of
> Jakarta-Commons, DB-Commons, XML-Commons etc.... Perfect! ;-)
>
> Jakarta-Commons would be as it is ... no change.
>
>
Nobody is talking about eliminating the individual releases. The question
is whether or not we should offer an *additional* combination package of
some sort, and what it should contain. One can certainly extend the
concept recursively beyond Jakarta Commons, but something like this is
going to align on language lines anyway -- and Jakarta Commons is already
only about Java based packages.
For those who wonder why such a combination JAR is important, please hang
around on the user lists, not just the developer lists :-).
> -- Tetsuya (tetsuya@apache.org)
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by "Stanley,Michael P." <ms...@mitre.org>.
>I knew that these kind of objections would occur if we thought
>this package *in* "Jakarta"-Commons Dev list.
>
>
>Briefly, ... How about Apache Commons?
>
>Keep the tiny commons.jakarta packages as they are and Apache
>Commons (http://commons.apache.org/) provides the mixture of
>Jakarta-Commons, DB-Commons, XML-Commons etc.... Perfect! ;-)
>
>Jakarta-Commons would be as it is ... no change.
>
Well, I think the suggestion I made is still valid (and even more so) in
this scenario. I think providing a utility (that can be used
interactively, or from a build utility, conf file, etc) to combine
multiple commons components (be it Jakarta, DB, or XML-Commons) into a
single jar is more beneficial than creating a "Apache Commons
Distribution". My suggestion does not come from the "creating a
commons out of the commons" complaint, but rather dependency/version
management in Java is not easy. Keeping dependencies (especially
commons) tightly packaged and independently revisioned is necessary.
Again, to help create a single distribution, create a configuration
utility that lets this distribution be built (easily, and automatically)
by the end user rather than a community voting on releases, combo
version numbers, etc... Not only does this resolve your issue but it
lets existing projects that use a variety of commons to create default
configurations for themselves. I know this would make my life easier,
and I know an "apache commons distribution" will definitely not.
- Mike
>
>
>-- Tetsuya (tetsuya@apache.org)
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Thu, 14 Aug 2003 15:58:45 +1000
"Vikram Goyal" <v....@uq.edu.au> wrote:
> > -1 on any combination. Core / Combo - whatever. I think it is a bad
> > idea.
> Agree with you that it is a bad idea. Commons was supposed to be it.
> Its like trying to factor out a "Commons" out of Commons. I can see
> the nightmare and the trouble people will have trying to understand
> what a "Combo" is out of Commons. Developers are sensible enough to
> realise and factor out common jars. Agreed that it takes time but hey,
> thats what we are paid for.
I knew that these kind of objections would occur if we thought
this package *in* "Jakarta"-Commons Dev list.
Briefly, ... How about Apache Commons?
Keep the tiny commons.jakarta packages as they are and Apache
Commons (http://commons.apache.org/) provides the mixture of
Jakarta-Commons, DB-Commons, XML-Commons etc.... Perfect! ;-)
Jakarta-Commons would be as it is ... no change.
-- Tetsuya (tetsuya@apache.org)
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Thu, 14 Aug 2003 15:58:45 +1000
"Vikram Goyal" <v....@uq.edu.au> wrote:
> > -1 on any combination. Core / Combo - whatever. I think it is a bad
> > idea.
> Agree with you that it is a bad idea. Commons was supposed to be it.
> Its like trying to factor out a "Commons" out of Commons. I can see
> the nightmare and the trouble people will have trying to understand
> what a "Combo" is out of Commons. Developers are sensible enough to
> realise and factor out common jars. Agreed that it takes time but hey,
> thats what we are paid for.
I knew that these kind of objections would occur if we thought
this package *in* "Jakarta"-Commons Dev list.
Briefly, ... How about Apache Commons?
Keep the tiny commons.jakarta packages as they are and Apache
Commons (http://commons.apache.org/) provides the mixture of
Jakarta-Commons, DB-Commons, XML-Commons etc.... Perfect! ;-)
Jakarta-Commons would be as it is ... no change.
-- Tetsuya (tetsuya@apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Vikram Goyal <v....@uq.edu.au>.
> Hi everyone -
>
> I'm not directly involved with any Jakarta/Apache project at the
> moment. I lurk on a ton of the lists and have lurked for some time.
Ha! So I am not the only one. :)
> -1 on any combination. Core / Combo - whatever. I think it is a bad
> idea.
Agree with you that it is a bad idea. Commons was supposed to be it. Its
like trying to factor out a "Commons" out of Commons. I can see the
nightmare and the trouble people will have trying to understand what a
"Combo" is out of Commons. Developers are sensible enough to realise and
factor out common jars. Agreed that it takes time but hey, thats what we are
paid for.
Vikram
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Vikram Goyal <v....@uq.edu.au>.
> Hi everyone -
>
> I'm not directly involved with any Jakarta/Apache project at the
> moment. I lurk on a ton of the lists and have lurked for some time.
Ha! So I am not the only one. :)
> -1 on any combination. Core / Combo - whatever. I think it is a bad
> idea.
Agree with you that it is a bad idea. Commons was supposed to be it. Its
like trying to factor out a "Commons" out of Commons. I can see the
nightmare and the trouble people will have trying to understand what a
"Combo" is out of Commons. Developers are sensible enough to realise and
factor out common jars. Agreed that it takes time but hey, thats what we are
paid for.
Vikram
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Stanley,Michael P. wrote:
> ...projects in all my projects. I want to add my two cents to this
> conversation.
Always welcome.
> -1 on any combination. Core / Combo - whatever. I think it is a bad
> idea.
>
> Dealing with dependencies and versions in Java is difficult enough. One
> of the benefits of the commons, in my opinion, is the ability to have
> fine control over the classes & versions that you currently need. You
Not suggesting that this go away. The Combo distribution is in addition to
the others.
> can resolve conflicts in small increments. For example. If I'm using
> Commons Collections 2.1 but another dependency that I use requires
> Commons Collections 2.0, I can easily resolve this tiny conflict in a
> number of ways. The larger jars become the harder this becomes
> (especially as the project grows in size). It is much easier to manage
> 50 jar dependencies than it is to resolve a conflict that occurs in 5
> large jars.
It can be a serious problem. A colleague once wasted ages debugging
JavaMail to finally realise that his EJB container had its own older
JavaMail jar built inside its core jar.
The other side of the problem though is that in a world of no conflict,
the 50 jar dependencies are far more painful than the 5 large jars.
> I don't think that creating a Commons Combo distribution is in any way
> beneficial. If this is the biggest complaint :
>
> > 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.
>
> Then there are other ways to ease the management of commons dependencies.
>
> I suggest creating a small interactive utility that can be run by the
> end user. The utility will display some known packaged configurations
> (such as the ones currently being discussed). The same tool can also
> offer an advanced option that lets the user pick and choose the package
> and configuration they want. Once a configuration is selected, the
> utility grabs the releases off the net, combines them in a jar, and
> creates a dependency README file of sorts.
The idea is great, but the reality is not. My two main reasons:
1) Resource. An interactive build will chew CPU, someone needs to code
this up and people only code to their itches and most importantly, Apache
does not currently have a production facing machine that runs a JVM. The
last is getting closer to happening. There is a Sun box that does the
nightly builds, I suspect the infrastructure people would not want it to
be running part of the website.
2) Application. The best application for this would be a Maven
sub-project, but this has issues. They don't currently record the required
JVM version, they don't upload POM files to the repositories and it would
mean mandating usage of Maven by Commons projects.
> This will save a lot of time and energy in the long run, and provides a
> solution to the "biggest complaint".
Apart from those, I like the idea and would love to use said software. In
a way it's a maven-install program and to make a Combo distribution would
just be a case of a single project.xml with dependencies. The
current feasibility is just not high.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Stanley,Michael P. wrote:
> ...projects in all my projects. I want to add my two cents to this
> conversation.
Always welcome.
> -1 on any combination. Core / Combo - whatever. I think it is a bad
> idea.
>
> Dealing with dependencies and versions in Java is difficult enough. One
> of the benefits of the commons, in my opinion, is the ability to have
> fine control over the classes & versions that you currently need. You
Not suggesting that this go away. The Combo distribution is in addition to
the others.
> can resolve conflicts in small increments. For example. If I'm using
> Commons Collections 2.1 but another dependency that I use requires
> Commons Collections 2.0, I can easily resolve this tiny conflict in a
> number of ways. The larger jars become the harder this becomes
> (especially as the project grows in size). It is much easier to manage
> 50 jar dependencies than it is to resolve a conflict that occurs in 5
> large jars.
It can be a serious problem. A colleague once wasted ages debugging
JavaMail to finally realise that his EJB container had its own older
JavaMail jar built inside its core jar.
The other side of the problem though is that in a world of no conflict,
the 50 jar dependencies are far more painful than the 5 large jars.
> I don't think that creating a Commons Combo distribution is in any way
> beneficial. If this is the biggest complaint :
>
> > 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.
>
> Then there are other ways to ease the management of commons dependencies.
>
> I suggest creating a small interactive utility that can be run by the
> end user. The utility will display some known packaged configurations
> (such as the ones currently being discussed). The same tool can also
> offer an advanced option that lets the user pick and choose the package
> and configuration they want. Once a configuration is selected, the
> utility grabs the releases off the net, combines them in a jar, and
> creates a dependency README file of sorts.
The idea is great, but the reality is not. My two main reasons:
1) Resource. An interactive build will chew CPU, someone needs to code
this up and people only code to their itches and most importantly, Apache
does not currently have a production facing machine that runs a JVM. The
last is getting closer to happening. There is a Sun box that does the
nightly builds, I suspect the infrastructure people would not want it to
be running part of the website.
2) Application. The best application for this would be a Maven
sub-project, but this has issues. They don't currently record the required
JVM version, they don't upload POM files to the repositories and it would
mean mandating usage of Maven by Commons projects.
> This will save a lot of time and energy in the long run, and provides a
> solution to the "biggest complaint".
Apart from those, I like the idea and would love to use said software. In
a way it's a maven-install program and to make a Combo distribution would
just be a case of a single project.xml with dependencies. The
current feasibility is just not high.
Hen
Re: [combo] Commons Core release?
Posted by "Stanley,Michael P." <ms...@mitre.org>.
Hi everyone -
I'm not directly involved with any Jakarta/Apache project at the
moment. I lurk on a ton of the lists and have lurked for some time. I
use (and try to contribute back as much as possible) many Jakarta/Apache
projects in all my projects. I want to add my two cents to this
conversation.
-1 on any combination. Core / Combo - whatever. I think it is a bad
idea.
Dealing with dependencies and versions in Java is difficult enough. One
of the benefits of the commons, in my opinion, is the ability to have
fine control over the classes & versions that you currently need. You
can resolve conflicts in small increments. For example. If I'm using
Commons Collections 2.1 but another dependency that I use requires
Commons Collections 2.0, I can easily resolve this tiny conflict in a
number of ways. The larger jars become the harder this becomes
(especially as the project grows in size). It is much easier to manage
50 jar dependencies than it is to resolve a conflict that occurs in 5
large jars.
I don't think that creating a Commons Combo distribution is in any way
beneficial. If this is the biggest complaint :
> 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.
Then there are other ways to ease the management of commons dependencies.
I suggest creating a small interactive utility that can be run by the end user. The utility will display some known packaged configurations (such as the ones currently being discussed). The same tool can also offer an advanced option that lets the user pick and choose the package and configuration they want. Once a configuration is selected, the utility grabs the releases off the net, combines them in a jar, and creates a dependency README file of sorts.
The benefits to this approach - 1) you provide a simple way to combine commons files in a single jar. 2) You avoid the discussions, arguments, and headaches with coordinating the release(s) of a combo/core package. 3) You put the user in complete control and provide a clean way to resolve conflicts (or upgrade partial commons libraries and still maintain one manageable jar). 4) you can easily migrate this tool integrate with existing build tools such as an ant task and/or maven plugin. 5) provide a limitless number of combination configurations - i.e. "Struts Commons Package", "James Commons Package", "Apache Commons Package", "Jakarta Commons Core", "Cutting Edge Commons", etc.
This will save a lot of time and energy in the long run, and provides a solution to the "biggest complaint".
- Mike
Tetsuya Kitahata wrote:
>By the way, how about
>"Commons-Core_August_2003" or something equivalent to it,
>rather than "Commons-Core V1.0" ... ??
>
>We are taking the list of "Products available as of the end of ***,
>year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
>would be ideal and make sense .... Comments please ;-)
>
>-- Tetsuya (tetsuya@apache.org)
>
>--
>
>On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
>(Subject: Re: [combo] Commons Core release?)
>"Craig R. McClanahan" <cr...@apache.org> wrote:
>
>
>
>>Comments interspersed.
>>
>>On Thu, 14 Aug 2003, Henri Yandell wrote:
>>
>>
>>
>>>Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
>>>From: Henri Yandell <ba...@generationjava.com>
>>>Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>>To: Jakarta Commons Developers List <co...@jakarta.apache.org>
>>>Subject: [combo] Commons Core release?
>>>
>>>
>>>Last November [I think] Craig created the Combo project. It puts a whole
>>>lot of Commons projects into one jar and makes them available in a much
>>>simpler form to users.
>>>
>>>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.
>>
>>
>>
>>>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.
>>
>>
>>
>>>=====
>>>Apache Commons Core v1.0 consists of:
>>>
>>>Jakarta Commons BeanUtils 1.6.1
>>> Makes the JavaBean specification easier to deal with.
>>>
>>>Jakarta Commons CLI 1.0
>>> A command line interpreter. Used to handle all the flags passed to your
>>>program on the command line.
>>>
>>>Jakarta Commons Codec 1.1
>>> Common encoders and decoders.
>>>
>>>Jakarta Commons Collections 2.1
>>> Many more implementations that fit the Collections API.
>>>
>>>Jakarta Commons Lang 1.0.1
>>> Enhancements to classes found in java.lang.
>>>=======
>>>
>>>A url to a build is: http://www.apache.org/~bayard/commons-core/
>>>
>>>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.
>>
>>
>>
>>>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.")
>>
>>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.
>>
>>
>>
>>>*) Arguments over what goes in what. Rather than create a huge jar of
>>>everything, which I think is unpalatable to the user, I chose the JDK 1.4
>>>dependency as a strict guideline and tried to make things toe the line.
>>>Effectively it's a Commons-J2SE distribution for adding features to a
>>>new J2SE install.
>>>
>>>*) Testing. In Core 1.0 I've chosen the latest stable releases [except
>>>HttpClient which is at RC2] of each project. There are no
>>>interdependencies, but as projects depend on each other the building of a
>>>combo jar becomes trickier. This is a problem for the future probably.
>>>Possibly the solution is that after each component is built/tested, and
>>>the new uber-jar is built, the tests should be re-run against that jar.
>>>
>>>====
>>>
>>>My general idea for Combo is that it is a tool for creating distributions
>>>of Commons code. These distributions are effectively configurations of
>>>Combo. I'm not sure if Craig is +1 or -1 for this and what his
>>>original plans were, but I think there's a need for a solution and that
>>>this is a solution.
>>>
>>>No idea if it's a good solution :) It seems quite fun and interesting.
>>>
>>>Any ideas? Flames?
>>>
>>>My chief two concerns are:
>>>
>>>
>>>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.
>>
>>I'm +0 on setting up the combo build.xml file in such a way that you can
>>do your own custom subsets.
>>
>>
>>
>>>Hen
>>>
>>>
>>Craig
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
Not sure. I think any combo release should be driven by a release of a
sub-component. Versioning of the combo release gets a bit interesting
then, probably we should have the idea of:
super-major-minor-bugfix
ie) 1.1.1.1
When Lang 2.0 comes out, it would move to 1.2.1.1. When Codec 1.1.1 comes
out, it would move to 1.2.1.2 etc.
Hen
On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
>
> By the way, how about
> "Commons-Core_August_2003" or something equivalent to it,
> rather than "Commons-Core V1.0" ... ??
>
> We are taking the list of "Products available as of the end of ***,
> year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
> would be ideal and make sense .... Comments please ;-)
>
> -- Tetsuya (tetsuya@apache.org)
>
> --
>
> On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
> (Subject: Re: [combo] Commons Core release?)
> "Craig R. McClanahan" <cr...@apache.org> wrote:
>
> > Comments interspersed.
> >
> > On Thu, 14 Aug 2003, Henri Yandell wrote:
> >
> > > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> > > From: Henri Yandell <ba...@generationjava.com>
> > > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > > Subject: [combo] Commons Core release?
> > >
> > >
> > > Last November [I think] Craig created the Combo project. It puts a whole
> > > lot of Commons projects into one jar and makes them available in a much
> > > simpler form to users.
> > >
> > > 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.
> >
> > > 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.
> >
> > >
> > > =====
> > > Apache Commons Core v1.0 consists of:
> > >
> > > Jakarta Commons BeanUtils 1.6.1
> > > Makes the JavaBean specification easier to deal with.
> > >
> > > Jakarta Commons CLI 1.0
> > > A command line interpreter. Used to handle all the flags passed to your
> > > program on the command line.
> > >
> > > Jakarta Commons Codec 1.1
> > > Common encoders and decoders.
> > >
> > > Jakarta Commons Collections 2.1
> > > Many more implementations that fit the Collections API.
> > >
> > > Jakarta Commons Lang 1.0.1
> > > Enhancements to classes found in java.lang.
> > > =======
> > >
> > > A url to a build is: http://www.apache.org/~bayard/commons-core/
> > >
> > > 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.
> >
> > > 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.")
> >
> > 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.
> >
> > > *) Arguments over what goes in what. Rather than create a huge jar of
> > > everything, which I think is unpalatable to the user, I chose the JDK 1.4
> > > dependency as a strict guideline and tried to make things toe the line.
> > > Effectively it's a Commons-J2SE distribution for adding features to a
> > > new J2SE install.
> > >
> > > *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> > > HttpClient which is at RC2] of each project. There are no
> > > interdependencies, but as projects depend on each other the building of a
> > > combo jar becomes trickier. This is a problem for the future probably.
> > > Possibly the solution is that after each component is built/tested, and
> > > the new uber-jar is built, the tests should be re-run against that jar.
> > >
> > > ====
> > >
> > > My general idea for Combo is that it is a tool for creating distributions
> > > of Commons code. These distributions are effectively configurations of
> > > Combo. I'm not sure if Craig is +1 or -1 for this and what his
> > > original plans were, but I think there's a need for a solution and that
> > > this is a solution.
> > >
> > > No idea if it's a good solution :) It seems quite fun and interesting.
> > >
> > > Any ideas? Flames?
> > >
> > > My chief two concerns are:
> > >
> > >
> > > 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.
> >
> > I'm +0 on setting up the combo build.xml file in such a way that you can
> > do your own custom subsets.
> >
> > >
> > >
> > > Hen
> >
> > Craig
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
Not sure. I think any combo release should be driven by a release of a
sub-component. Versioning of the combo release gets a bit interesting
then, probably we should have the idea of:
super-major-minor-bugfix
ie) 1.1.1.1
When Lang 2.0 comes out, it would move to 1.2.1.1. When Codec 1.1.1 comes
out, it would move to 1.2.1.2 etc.
Hen
On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
>
> By the way, how about
> "Commons-Core_August_2003" or something equivalent to it,
> rather than "Commons-Core V1.0" ... ??
>
> We are taking the list of "Products available as of the end of ***,
> year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
> would be ideal and make sense .... Comments please ;-)
>
> -- Tetsuya (tetsuya@apache.org)
>
> --
>
> On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
> (Subject: Re: [combo] Commons Core release?)
> "Craig R. McClanahan" <cr...@apache.org> wrote:
>
> > Comments interspersed.
> >
> > On Thu, 14 Aug 2003, Henri Yandell wrote:
> >
> > > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> > > From: Henri Yandell <ba...@generationjava.com>
> > > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > > Subject: [combo] Commons Core release?
> > >
> > >
> > > Last November [I think] Craig created the Combo project. It puts a whole
> > > lot of Commons projects into one jar and makes them available in a much
> > > simpler form to users.
> > >
> > > 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.
> >
> > > 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.
> >
> > >
> > > =====
> > > Apache Commons Core v1.0 consists of:
> > >
> > > Jakarta Commons BeanUtils 1.6.1
> > > Makes the JavaBean specification easier to deal with.
> > >
> > > Jakarta Commons CLI 1.0
> > > A command line interpreter. Used to handle all the flags passed to your
> > > program on the command line.
> > >
> > > Jakarta Commons Codec 1.1
> > > Common encoders and decoders.
> > >
> > > Jakarta Commons Collections 2.1
> > > Many more implementations that fit the Collections API.
> > >
> > > Jakarta Commons Lang 1.0.1
> > > Enhancements to classes found in java.lang.
> > > =======
> > >
> > > A url to a build is: http://www.apache.org/~bayard/commons-core/
> > >
> > > 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.
> >
> > > 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.")
> >
> > 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.
> >
> > > *) Arguments over what goes in what. Rather than create a huge jar of
> > > everything, which I think is unpalatable to the user, I chose the JDK 1.4
> > > dependency as a strict guideline and tried to make things toe the line.
> > > Effectively it's a Commons-J2SE distribution for adding features to a
> > > new J2SE install.
> > >
> > > *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> > > HttpClient which is at RC2] of each project. There are no
> > > interdependencies, but as projects depend on each other the building of a
> > > combo jar becomes trickier. This is a problem for the future probably.
> > > Possibly the solution is that after each component is built/tested, and
> > > the new uber-jar is built, the tests should be re-run against that jar.
> > >
> > > ====
> > >
> > > My general idea for Combo is that it is a tool for creating distributions
> > > of Commons code. These distributions are effectively configurations of
> > > Combo. I'm not sure if Craig is +1 or -1 for this and what his
> > > original plans were, but I think there's a need for a solution and that
> > > this is a solution.
> > >
> > > No idea if it's a good solution :) It seems quite fun and interesting.
> > >
> > > Any ideas? Flames?
> > >
> > > My chief two concerns are:
> > >
> > >
> > > 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.
> >
> > I'm +0 on setting up the combo build.xml file in such a way that you can
> > do your own custom subsets.
> >
> > >
> > >
> > > Hen
> >
> > Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
By the way, how about
"Commons-Core_August_2003" or something equivalent to it,
rather than "Commons-Core V1.0" ... ??
We are taking the list of "Products available as of the end of ***,
year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
would be ideal and make sense .... Comments please ;-)
-- Tetsuya (tetsuya@apache.org)
--
On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
(Subject: Re: [combo] Commons Core release?)
"Craig R. McClanahan" <cr...@apache.org> wrote:
> Comments interspersed.
>
> On Thu, 14 Aug 2003, Henri Yandell wrote:
>
> > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> > From: Henri Yandell <ba...@generationjava.com>
> > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: [combo] Commons Core release?
> >
> >
> > Last November [I think] Craig created the Combo project. It puts a whole
> > lot of Commons projects into one jar and makes them available in a much
> > simpler form to users.
> >
> > 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.
>
> > 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.
>
> >
> > =====
> > Apache Commons Core v1.0 consists of:
> >
> > Jakarta Commons BeanUtils 1.6.1
> > Makes the JavaBean specification easier to deal with.
> >
> > Jakarta Commons CLI 1.0
> > A command line interpreter. Used to handle all the flags passed to your
> > program on the command line.
> >
> > Jakarta Commons Codec 1.1
> > Common encoders and decoders.
> >
> > Jakarta Commons Collections 2.1
> > Many more implementations that fit the Collections API.
> >
> > Jakarta Commons Lang 1.0.1
> > Enhancements to classes found in java.lang.
> > =======
> >
> > A url to a build is: http://www.apache.org/~bayard/commons-core/
> >
> > 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.
>
> > 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.")
>
> 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.
>
> > *) Arguments over what goes in what. Rather than create a huge jar of
> > everything, which I think is unpalatable to the user, I chose the JDK 1.4
> > dependency as a strict guideline and tried to make things toe the line.
> > Effectively it's a Commons-J2SE distribution for adding features to a
> > new J2SE install.
> >
> > *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> > HttpClient which is at RC2] of each project. There are no
> > interdependencies, but as projects depend on each other the building of a
> > combo jar becomes trickier. This is a problem for the future probably.
> > Possibly the solution is that after each component is built/tested, and
> > the new uber-jar is built, the tests should be re-run against that jar.
> >
> > ====
> >
> > My general idea for Combo is that it is a tool for creating distributions
> > of Commons code. These distributions are effectively configurations of
> > Combo. I'm not sure if Craig is +1 or -1 for this and what his
> > original plans were, but I think there's a need for a solution and that
> > this is a solution.
> >
> > No idea if it's a good solution :) It seems quite fun and interesting.
> >
> > Any ideas? Flames?
> >
> > My chief two concerns are:
> >
> >
> > 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.
>
> I'm +0 on setting up the combo build.xml file in such a way that you can
> do your own custom subsets.
>
> >
> >
> > Hen
>
> Craig
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
By the way, how about
"Commons-Core_August_2003" or something equivalent to it,
rather than "Commons-Core V1.0" ... ??
We are taking the list of "Products available as of the end of ***,
year 200X" ... So, "Commons-Core_(Month)_YYYY.jar"-styled package name
would be ideal and make sense .... Comments please ;-)
-- Tetsuya (tetsuya@apache.org)
--
On Wed, 13 Aug 2003 21:27:26 -0700 (PDT)
(Subject: Re: [combo] Commons Core release?)
"Craig R. McClanahan" <cr...@apache.org> wrote:
> Comments interspersed.
>
> On Thu, 14 Aug 2003, Henri Yandell wrote:
>
> > Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> > From: Henri Yandell <ba...@generationjava.com>
> > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: [combo] Commons Core release?
> >
> >
> > Last November [I think] Craig created the Combo project. It puts a whole
> > lot of Commons projects into one jar and makes them available in a much
> > simpler form to users.
> >
> > 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.
>
> > 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.
>
> >
> > =====
> > Apache Commons Core v1.0 consists of:
> >
> > Jakarta Commons BeanUtils 1.6.1
> > Makes the JavaBean specification easier to deal with.
> >
> > Jakarta Commons CLI 1.0
> > A command line interpreter. Used to handle all the flags passed to your
> > program on the command line.
> >
> > Jakarta Commons Codec 1.1
> > Common encoders and decoders.
> >
> > Jakarta Commons Collections 2.1
> > Many more implementations that fit the Collections API.
> >
> > Jakarta Commons Lang 1.0.1
> > Enhancements to classes found in java.lang.
> > =======
> >
> > A url to a build is: http://www.apache.org/~bayard/commons-core/
> >
> > 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.
>
> > 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.")
>
> 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.
>
> > *) Arguments over what goes in what. Rather than create a huge jar of
> > everything, which I think is unpalatable to the user, I chose the JDK 1.4
> > dependency as a strict guideline and tried to make things toe the line.
> > Effectively it's a Commons-J2SE distribution for adding features to a
> > new J2SE install.
> >
> > *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> > HttpClient which is at RC2] of each project. There are no
> > interdependencies, but as projects depend on each other the building of a
> > combo jar becomes trickier. This is a problem for the future probably.
> > Possibly the solution is that after each component is built/tested, and
> > the new uber-jar is built, the tests should be re-run against that jar.
> >
> > ====
> >
> > My general idea for Combo is that it is a tool for creating distributions
> > of Commons code. These distributions are effectively configurations of
> > Combo. I'm not sure if Craig is +1 or -1 for this and what his
> > original plans were, but I think there's a need for a solution and that
> > this is a solution.
> >
> > No idea if it's a good solution :) It seems quite fun and interesting.
> >
> > Any ideas? Flames?
> >
> > My chief two concerns are:
> >
> >
> > 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.
>
> I'm +0 on setting up the combo build.xml file in such a way that you can
> do your own custom subsets.
>
> >
> >
> > Hen
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Wed, 13 Aug 2003, Craig R. McClanahan wrote:
> 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.
I'm with Craig on this. +0 to a "combo" that contains everything in
commons (even httpclient) in a single JAR (and we'll cross our fingers
that won't introduce any versioning issues.) -1 anything like
"commons-core" that tries to pick and choose which products the user is
likely to want. This is impractical at best, and political at worst.
> >
> > =====
> > Apache Commons Core v1.0 consists of:
> >
> > Jakarta Commons BeanUtils 1.6.1
> > Makes the JavaBean specification easier to deal with.
> >
> > Jakarta Commons CLI 1.0
> > A command line interpreter. Used to handle all the flags passed to your
> > program on the command line.
> >
> > Jakarta Commons Codec 1.1
> > Common encoders and decoders.
> >
> > Jakarta Commons Collections 2.1
> > Many more implementations that fit the Collections API.
> >
> > Jakarta Commons Lang 1.0.1
> > Enhancements to classes found in java.lang.
> > =======
> >
> > A url to a build is: http://www.apache.org/~bayard/commons-core/
> >
> > 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.
>
This is probably better suited to another thread, but I'm -1 on making
BeanUtils require JDK 1.4.
With respect to versioning of something like commons-combo, I'd rather see
either: (1) straight incremental version numbers--"release 1",
"release 2", ... , "release n"--or (2) a straight date based
system--"17 Aug 2003", "23 Sept 2003", etc. Anything else is going to
confuse the suitation more than clarifying it. If you want to know which
specific versions of each component are contained, you're gonna have to
look at the release notes anyway.
- Rod <http://radio.weblogs.com/0122027/>
Re: [combo] Commons Core release?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Wed, 13 Aug 2003, Craig R. McClanahan wrote:
> 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.
I'm with Craig on this. +0 to a "combo" that contains everything in
commons (even httpclient) in a single JAR (and we'll cross our fingers
that won't introduce any versioning issues.) -1 anything like
"commons-core" that tries to pick and choose which products the user is
likely to want. This is impractical at best, and political at worst.
> >
> > =====
> > Apache Commons Core v1.0 consists of:
> >
> > Jakarta Commons BeanUtils 1.6.1
> > Makes the JavaBean specification easier to deal with.
> >
> > Jakarta Commons CLI 1.0
> > A command line interpreter. Used to handle all the flags passed to your
> > program on the command line.
> >
> > Jakarta Commons Codec 1.1
> > Common encoders and decoders.
> >
> > Jakarta Commons Collections 2.1
> > Many more implementations that fit the Collections API.
> >
> > Jakarta Commons Lang 1.0.1
> > Enhancements to classes found in java.lang.
> > =======
> >
> > A url to a build is: http://www.apache.org/~bayard/commons-core/
> >
> > 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.
>
This is probably better suited to another thread, but I'm -1 on making
BeanUtils require JDK 1.4.
With respect to versioning of something like commons-combo, I'd rather see
either: (1) straight incremental version numbers--"release 1",
"release 2", ... , "release n"--or (2) a straight date based
system--"17 Aug 2003", "23 Sept 2003", etc. Anything else is going to
confuse the suitation more than clarifying it. If you want to know which
specific versions of each component are contained, you're gonna have to
look at the release notes anyway.
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Henri Yandell wrote:
> As more cross-dependency is added, complexity will increase, with the
> possibility of a 'combo' being impossible due to cyclics etc. One solution
> to stop this is to stop dependencies in Commons between projects.
Cyclic dependencies between projects generally indicate a bad
separation of the purposes and concerns. Dependencies, at least
for somewhat coordinated projects, should form a DAG.
Well, the problem is that some projects may consist of related
but differently scoped code. An example would be if [text] had
a spell checking library, used by [cli] to check for misspelled
options ( :-) ), and a dictionary management tool which uses
[cli]. In order to keep the dependencies under control, as well
as GUMP happy, the project would have to be split into, say [text]
for the libraries and [text-tools] for the rest, or something
similar.
Does this make sense?
> If anything, a hierarchy diagram showing the dependencies would be a nice
> result from this.
I could supply XSLT code to generate this from the maven project
files. Cyclic dependencies would still be a problem.
J.Pietschmann
Re: [combo] Commons Core release?
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Henri Yandell wrote:
> As more cross-dependency is added, complexity will increase, with the
> possibility of a 'combo' being impossible due to cyclics etc. One solution
> to stop this is to stop dependencies in Commons between projects.
Cyclic dependencies between projects generally indicate a bad
separation of the purposes and concerns. Dependencies, at least
for somewhat coordinated projects, should form a DAG.
Well, the problem is that some projects may consist of related
but differently scoped code. An example would be if [text] had
a spell checking library, used by [cli] to check for misspelled
options ( :-) ), and a dictionary management tool which uses
[cli]. In order to keep the dependencies under control, as well
as GUMP happy, the project would have to be split into, say [text]
for the libraries and [text-tools] for the rest, or something
similar.
Does this make sense?
> If anything, a hierarchy diagram showing the dependencies would be a nice
> result from this.
I could supply XSLT code to generate this from the maven project
files. Cyclic dependencies would still be a problem.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 17 Aug 2003, Rodney Waldhoff wrote:
> On Fri, 15 Aug 2003, Henri Yandell wrote:
>
> > On Fri, 15 Aug 2003, Rodney Waldhoff wrote:
> >
> > > On Thu, 14 Aug 2003, Henri Yandell wrote:
> > >
> > > > Forcing a user of three api's to grab
> > > > dependencies for 12 other api's is going to kill combo dead in the water.
> > >
> > > An observation: a user of 3 APIs doesn't need to grab any external
> > > dependencies outside of those three APIs. If you never load or use the
> > > dependent classes, you never need to load their dependencies.
> >
> > It's very hard to know though.
>
> Not hard at all. Look for "NoClassDefFound".
Not very good when I'm trying to learn about and install something.
> > I look at the dependency list and it says
> > it needs 5 jars.
>
> What dependency list? The compile-time ant and/or maven descriptors? We
> don't have a formal or even conventional run-time dependency indication
> AFAIK, although maybe this suggests we need one.
Yep. Maven one. Some kind of runtime would be good. Just thinking about
Commons Core/Combo is a good idea in terms of discovering problems here.
Currently I'm building BeanUtils 1.6.1 into my jar [I like the javadoc on
my PDA as one blob] but Math [which I'd like to start building in] relies
on BeanUtils 1.5.
As more cross-dependency is added, complexity will increase, with the
possibility of a 'combo' being impossible due to cyclics etc. One solution
to stop this is to stop dependencies in Commons between projects. Which is
obviously painful, we can't eat our own dogfood because it might get
tricky.
If anything, a hierarchy diagram showing the dependencies would be a nice
result from this.
> > We don't publish a 'you need this jar for this, this jar
> > for this' list. Also, who wants to trust that?
>
> Actually I believe in several places we do (e.g,.
> <http://jakarta.apache.org/commons/logging/userguide.html>,
> <http://jakarta.apache.org/commons/httpclient/sslguide.html>). The
> STATUS files used to hold this information, probably many of
> them have not been maintained.
>
> > Automating a build of this gets difficult I believe, plus you'd have to
> > not run certain tests. It feels like a rather manual solution.
>
> Both maven and gump seem to automate this rather well.
I presume that they have the compile-time dependencies available at
test-time. I would be aiming not to have things like log4j available, and
yet this means I can't run the tests for commons-logging log4j component
else it'll fall over.
Hen
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 17 Aug 2003, Rodney Waldhoff wrote:
> On Fri, 15 Aug 2003, Henri Yandell wrote:
>
> > On Fri, 15 Aug 2003, Rodney Waldhoff wrote:
> >
> > > On Thu, 14 Aug 2003, Henri Yandell wrote:
> > >
> > > > Forcing a user of three api's to grab
> > > > dependencies for 12 other api's is going to kill combo dead in the water.
> > >
> > > An observation: a user of 3 APIs doesn't need to grab any external
> > > dependencies outside of those three APIs. If you never load or use the
> > > dependent classes, you never need to load their dependencies.
> >
> > It's very hard to know though.
>
> Not hard at all. Look for "NoClassDefFound".
Not very good when I'm trying to learn about and install something.
> > I look at the dependency list and it says
> > it needs 5 jars.
>
> What dependency list? The compile-time ant and/or maven descriptors? We
> don't have a formal or even conventional run-time dependency indication
> AFAIK, although maybe this suggests we need one.
Yep. Maven one. Some kind of runtime would be good. Just thinking about
Commons Core/Combo is a good idea in terms of discovering problems here.
Currently I'm building BeanUtils 1.6.1 into my jar [I like the javadoc on
my PDA as one blob] but Math [which I'd like to start building in] relies
on BeanUtils 1.5.
As more cross-dependency is added, complexity will increase, with the
possibility of a 'combo' being impossible due to cyclics etc. One solution
to stop this is to stop dependencies in Commons between projects. Which is
obviously painful, we can't eat our own dogfood because it might get
tricky.
If anything, a hierarchy diagram showing the dependencies would be a nice
result from this.
> > We don't publish a 'you need this jar for this, this jar
> > for this' list. Also, who wants to trust that?
>
> Actually I believe in several places we do (e.g,.
> <http://jakarta.apache.org/commons/logging/userguide.html>,
> <http://jakarta.apache.org/commons/httpclient/sslguide.html>). The
> STATUS files used to hold this information, probably many of
> them have not been maintained.
>
> > Automating a build of this gets difficult I believe, plus you'd have to
> > not run certain tests. It feels like a rather manual solution.
>
> Both maven and gump seem to automate this rather well.
I presume that they have the compile-time dependencies available at
test-time. I would be aiming not to have things like log4j available, and
yet this means I can't run the tests for commons-logging log4j component
else it'll fall over.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Fri, 15 Aug 2003, Henri Yandell wrote:
> On Fri, 15 Aug 2003, Rodney Waldhoff wrote:
>
> > On Thu, 14 Aug 2003, Henri Yandell wrote:
> >
> > > Forcing a user of three api's to grab
> > > dependencies for 12 other api's is going to kill combo dead in the water.
> >
> > An observation: a user of 3 APIs doesn't need to grab any external
> > dependencies outside of those three APIs. If you never load or use the
> > dependent classes, you never need to load their dependencies.
>
> It's very hard to know though.
Not hard at all. Look for "NoClassDefFound".
> I look at the dependency list and it says
> it needs 5 jars.
What dependency list? The compile-time ant and/or maven descriptors? We
don't have a formal or even conventional run-time dependency indication
AFAIK, although maybe this suggests we need one.
> We don't publish a 'you need this jar for this, this jar
> for this' list. Also, who wants to trust that?
Actually I believe in several places we do (e.g,.
<http://jakarta.apache.org/commons/logging/userguide.html>,
<http://jakarta.apache.org/commons/httpclient/sslguide.html>). The
STATUS files used to hold this information, probably many of
them have not been maintained.
> Only power users will be able to deal with this easily, and they have no
> need for a combo jar.
> Automating a build of this gets difficult I believe, plus you'd have to
> not run certain tests. It feels like a rather manual solution.
Both maven and gump seem to automate this rather well.
> Hen
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Fri, 15 Aug 2003, Henri Yandell wrote:
> On Fri, 15 Aug 2003, Rodney Waldhoff wrote:
>
> > On Thu, 14 Aug 2003, Henri Yandell wrote:
> >
> > > Forcing a user of three api's to grab
> > > dependencies for 12 other api's is going to kill combo dead in the water.
> >
> > An observation: a user of 3 APIs doesn't need to grab any external
> > dependencies outside of those three APIs. If you never load or use the
> > dependent classes, you never need to load their dependencies.
>
> It's very hard to know though.
Not hard at all. Look for "NoClassDefFound".
> I look at the dependency list and it says
> it needs 5 jars.
What dependency list? The compile-time ant and/or maven descriptors? We
don't have a formal or even conventional run-time dependency indication
AFAIK, although maybe this suggests we need one.
> We don't publish a 'you need this jar for this, this jar
> for this' list. Also, who wants to trust that?
Actually I believe in several places we do (e.g,.
<http://jakarta.apache.org/commons/logging/userguide.html>,
<http://jakarta.apache.org/commons/httpclient/sslguide.html>). The
STATUS files used to hold this information, probably many of
them have not been maintained.
> Only power users will be able to deal with this easily, and they have no
> need for a combo jar.
> Automating a build of this gets difficult I believe, plus you'd have to
> not run certain tests. It feels like a rather manual solution.
Both maven and gump seem to automate this rather well.
> Hen
- Rod <http://radio.weblogs.com/0122027/>
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 15 Aug 2003, Rodney Waldhoff wrote:
> On Thu, 14 Aug 2003, Henri Yandell wrote:
>
> > Forcing a user of three api's to grab
> > dependencies for 12 other api's is going to kill combo dead in the water.
>
> An observation: a user of 3 APIs doesn't need to grab any external
> dependencies outside of those three APIs. If you never load or use the
> dependent classes, you never need to load their dependencies.
It's very hard to know though. I look at the dependency list and it says
it needs 5 jars. We don't publish a 'you need this jar for this, this jar
for this' list. Also, who wants to trust that?
Only power users will be able to deal with this easily, and they have no
need for a combo jar.
> For example:
>
> > Commons-Logging: log4j. logkit. avalon-framework.
>
> Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
> Compiling Commons-Logging without these things is a different matter, of
> course.
>
> Similarly:
>
> > it would not contain HttpClient (?) which I
> > thought might be 1.4 dependent now for SSL and would not include BeanUtils
> > with the current api munging.
>
> If you're not using HTTPS support within HttpClient, you don't
> need to have the SSL libraries (which weren't 1.4 dependent when I last
> checked) around either.
They come with 1.4 I believe.
> Including a component (such as Latka or Jelly, for example) with
> dependencies on a large number of external JARs would not require all
> users of commons-combo to grab those external JARs. (Of course, neither
> Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
> included anyway.)
Automating a build of this gets difficult I believe, plus you'd have to
not run certain tests. It feels like a rather manual solution.
> > > > 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.
>
> Creating a "comons-beanutils-for-commons-core.jar" that's different from
> commons-beanutils.jar is an extremely bad idea IMO. This creates a much
> worse problem than the one commons-core/commons-combo is trying to solve.
Yeah. It should instead be commons-beanutils.jar which depends on
commons-logging-api.jar.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 15 Aug 2003, Rodney Waldhoff wrote:
> On Thu, 14 Aug 2003, Henri Yandell wrote:
>
> > Forcing a user of three api's to grab
> > dependencies for 12 other api's is going to kill combo dead in the water.
>
> An observation: a user of 3 APIs doesn't need to grab any external
> dependencies outside of those three APIs. If you never load or use the
> dependent classes, you never need to load their dependencies.
It's very hard to know though. I look at the dependency list and it says
it needs 5 jars. We don't publish a 'you need this jar for this, this jar
for this' list. Also, who wants to trust that?
Only power users will be able to deal with this easily, and they have no
need for a combo jar.
> For example:
>
> > Commons-Logging: log4j. logkit. avalon-framework.
>
> Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
> Compiling Commons-Logging without these things is a different matter, of
> course.
>
> Similarly:
>
> > it would not contain HttpClient (?) which I
> > thought might be 1.4 dependent now for SSL and would not include BeanUtils
> > with the current api munging.
>
> If you're not using HTTPS support within HttpClient, you don't
> need to have the SSL libraries (which weren't 1.4 dependent when I last
> checked) around either.
They come with 1.4 I believe.
> Including a component (such as Latka or Jelly, for example) with
> dependencies on a large number of external JARs would not require all
> users of commons-combo to grab those external JARs. (Of course, neither
> Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
> included anyway.)
Automating a build of this gets difficult I believe, plus you'd have to
not run certain tests. It feels like a rather manual solution.
> > > > 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.
>
> Creating a "comons-beanutils-for-commons-core.jar" that's different from
> commons-beanutils.jar is an extremely bad idea IMO. This creates a much
> worse problem than the one commons-core/commons-combo is trying to solve.
Yeah. It should instead be commons-beanutils.jar which depends on
commons-logging-api.jar.
Hen
Re: [combo] Commons Core release?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 14 Aug 2003, Henri Yandell wrote:
> Forcing a user of three api's to grab
> dependencies for 12 other api's is going to kill combo dead in the water.
An observation: a user of 3 APIs doesn't need to grab any external
dependencies outside of those three APIs. If you never load or use the
dependent classes, you never need to load their dependencies.
For example:
> Commons-Logging: log4j. logkit. avalon-framework.
Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
Compiling Commons-Logging without these things is a different matter, of
course.
Similarly:
> it would not contain HttpClient (?) which I
> thought might be 1.4 dependent now for SSL and would not include BeanUtils
> with the current api munging.
If you're not using HTTPS support within HttpClient, you don't
need to have the SSL libraries (which weren't 1.4 dependent when I last
checked) around either.
Including a component (such as Latka or Jelly, for example) with
dependencies on a large number of external JARs would not require all
users of commons-combo to grab those external JARs. (Of course, neither
Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
included anyway.)
>
> > > 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.
Creating a "comons-beanutils-for-commons-core.jar" that's different from
commons-beanutils.jar is an extremely bad idea IMO. This creates a much
worse problem than the one commons-core/commons-combo is trying to solve.
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Oleg Kalnichevski <ol...@apache.org>.
> Is it just that JCE/JSSE weren't combined with 1.2? So to be only
> dependent on a single JDK [and not additional Sun jars], you'd need 1.4?
>
Not really. One can still happily run HttpClient on Java 1.2 (without
JCE & JSEE installed at all) as long as HTTPS and NTLM are not used. An
attempt to execute HTTP request that requires SSL transport or NTLM
authentication will result in ClassDefNotFound exception.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Oleg Kalnichevski <ol...@apache.org>.
> Is it just that JCE/JSSE weren't combined with 1.2? So to be only
> dependent on a single JDK [and not additional Sun jars], you'd need 1.4?
>
Not really. One can still happily run HttpClient on Java 1.2 (without
JCE & JSEE installed at all) as long as HTTPS and NTLM are not used. An
attempt to execute HTTP request that requires SSL transport or NTLM
authentication will result in ClassDefNotFound exception.
Oleg
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Oleg Kalnichevski wrote:
>
> >
> > 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.
> >
>
> Httpclient is still run-time dependent on Java 1.2 + commons-logging
> only. It is compile dependent on Java 1.2, commons-logging, JCE & JSSE.
Is it just that JCE/JSSE weren't combined with 1.2? So to be only
dependent on a single JDK [and not additional Sun jars], you'd need 1.4?
Hen
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
On Thu, 14 Aug 2003, Oleg Kalnichevski wrote:
>
> >
> > 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.
> >
>
> Httpclient is still run-time dependent on Java 1.2 + commons-logging
> only. It is compile dependent on Java 1.2, commons-logging, JCE & JSSE.
Is it just that JCE/JSSE weren't combined with 1.2? So to be only
dependent on a single JDK [and not additional Sun jars], you'd need 1.4?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Oleg Kalnichevski <ol...@apache.org>.
>
> 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.
>
Httpclient is still run-time dependent on Java 1.2 + commons-logging
only. It is compile dependent on Java 1.2, commons-logging, JCE & JSSE.
We are planning to introduce commons-codec as a run-time/compile
dependency in the next release. There will be no dependencies on Java
1.3 and above features in the foreseeable future (even though some of
them are quite tempting).
So, we clearly should be able to play nicely with both proposed
platforms: 'JDK 1.4' and 'JDK 1.2 + jars to make it 1.4-like'.
Oleg
Re: [combo] Commons Core release?
Posted by Oleg Kalnichevski <ol...@apache.org>.
>
> 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.
>
Httpclient is still run-time dependent on Java 1.2 + commons-logging
only. It is compile dependent on Java 1.2, commons-logging, JCE & JSSE.
We are planning to introduce commons-codec as a run-time/compile
dependency in the next release. There will be no dependencies on Java
1.3 and above features in the foreseeable future (even though some of
them are quite tempting).
So, we clearly should be able to play nicely with both proposed
platforms: 'JDK 1.4' and 'JDK 1.2 + jars to make it 1.4-like'.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 14 Aug 2003, Henri Yandell wrote:
> Forcing a user of three api's to grab
> dependencies for 12 other api's is going to kill combo dead in the water.
An observation: a user of 3 APIs doesn't need to grab any external
dependencies outside of those three APIs. If you never load or use the
dependent classes, you never need to load their dependencies.
For example:
> Commons-Logging: log4j. logkit. avalon-framework.
Commons-Logging runs just fine without log4j, logkit, or avalon-framework.
Compiling Commons-Logging without these things is a different matter, of
course.
Similarly:
> it would not contain HttpClient (?) which I
> thought might be 1.4 dependent now for SSL and would not include BeanUtils
> with the current api munging.
If you're not using HTTPS support within HttpClient, you don't
need to have the SSL libraries (which weren't 1.4 dependent when I last
checked) around either.
Including a component (such as Latka or Jelly, for example) with
dependencies on a large number of external JARs would not require all
users of commons-combo to grab those external JARs. (Of course, neither
Latka nor Jelly has 1.0 release IIRC, so they probably wouldn't be
included anyway.)
>
> > > 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.
Creating a "comons-beanutils-for-commons-core.jar" that's different from
commons-beanutils.jar is an extremely bad idea IMO. This creates a much
worse problem than the one commons-core/commons-combo is trying to solve.
- Rod <http://radio.weblogs.com/0122027/>
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
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 <ba...@generationjava.com>
> >
> > 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Henri Yandell <ba...@generationjava.com>.
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 <ba...@generationjava.com>
> >
> > 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
Re: [combo] Commons Core release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Comments interspersed.
On Thu, 14 Aug 2003, Henri Yandell wrote:
> Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> From: Henri Yandell <ba...@generationjava.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [combo] Commons Core release?
>
>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
>
> 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.
> 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.
>
> =====
> Apache Commons Core v1.0 consists of:
>
> Jakarta Commons BeanUtils 1.6.1
> Makes the JavaBean specification easier to deal with.
>
> Jakarta Commons CLI 1.0
> A command line interpreter. Used to handle all the flags passed to your
> program on the command line.
>
> Jakarta Commons Codec 1.1
> Common encoders and decoders.
>
> Jakarta Commons Collections 2.1
> Many more implementations that fit the Collections API.
>
> Jakarta Commons Lang 1.0.1
> Enhancements to classes found in java.lang.
> =======
>
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
> 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.")
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.
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
>
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
>
> ====
>
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
>
> No idea if it's a good solution :) It seems quite fun and interesting.
>
> Any ideas? Flames?
>
> My chief two concerns are:
>
>
> 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.
I'm +0 on setting up the combo build.xml file in such a way that you can
do your own custom subsets.
>
>
> Hen
Craig
Re: [combo] Commons Core release?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I haven't added to the debate up till now as I wanted to see how things
went.
Firstly, my definition of 'core' is basic extensions to the JDK, no config
files, no logging, no framework.
lang
io
collections
codec (never looked at it, but may fit)
cli?? (never looked at it, but may be more framework like)
BeanUtils ought to be included, however it has been written to use logging.
I believe this to be wrong, but this is an old decision, hard to change.
JDK1.2 should be the baseline.
However, it is clear that this division is just one of many that can occur.
It makes most sense to me, but others disagree. Given the current commons
structure I would suggest agreement on the contents of core is highly
unlikely.
One way out would be a separate mailing list, or maybe a separate
Jakarta-Core subproject. Then a single release could be created. However,
this also seems to fail the reality check.
Originally, I supported commons core, by promoting collections, io, pattern
(deceased), beanutils to all depend on lang, thus forming a nice group. Now
it seems that the more independent absolute minimum dependencies route is
actually simpler for everyone. A little code duplication may occur, but that
is better than additional dependencies.
My answer to the users - just deal with the jars. Its not that hard, and
creating a combo or core jar creates really nasty versioning issues, as
commons projects release to their own timescales, not one. One product = One
jar.
Stephen
NOTE: If Java was OSS and we were in charge of adding new functions to the
JDK, matters might be different. But as outside libraries, the midset must
be different.
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
>
> 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.
>
> 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:
>
> =====
> Apache Commons Core v1.0 consists of:
>
> Jakarta Commons BeanUtils 1.6.1
> Makes the JavaBean specification easier to deal with.
>
> Jakarta Commons CLI 1.0
> A command line interpreter. Used to handle all the flags passed to
your
> program on the command line.
>
> Jakarta Commons Codec 1.1
> Common encoders and decoders.
>
> Jakarta Commons Collections 2.1
> Many more implementations that fit the Collections API.
>
> Jakarta Commons Lang 1.0.1
> Enhancements to classes found in java.lang.
> =======
>
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
>
> 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.
>
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
>
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
>
> ====
>
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
>
> No idea if it's a good solution :) It seems quite fun and interesting.
>
> Any ideas? Flames?
>
> My chief two concerns are:
>
>
> 1) Can I treat Combo as a Commons Proper project.
> 2) Is the idea of a Commons Core distribution viable.
>
>
> 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
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Thu, 14 Aug 2003 01:00:04 -0400
(Subject: RE: [combo] Commons Core release?)
"Noel J. Bergman" <no...@devtech.com> wrote:
> > > Now, Jakarta-ORO think about one of the potentialities
> > > of the transfer to commons-proper. (How about Regexp, ECS?)
> > 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.
> If you look at the mailing list for oro
> (http://nagoya.apache.org/eyebrowse/BrowseList?listName=oro-dev@jakarta.apache.org&by=date&from=2003-08-01&to=2003-08-31&first=1&count=15),
> you'll see that coming here is one of the options. I think that it
> makes sense to invite them.
Is this Jakarta PMC matter? Anyway, oro/regexp/ecs are all compact and
would fit to the commons-proper charter.
> > Only if combo is truly a combination of every Commons package that you
> > need :-).
> I agree. For example, the ones interesting to James are Collection, Pool,
> DBCP, NET and ORO.
Haha. Anyway, one of the possibilities is "Jakarta Commons Combo".
The other is "Apache Commons Combo" (Apache Commons Project, so
components in db-commons/xml-commons can join to it)
--
Again and again, "Bye bye! too many jars! ;-)"
-- Tetsuya (tetsuya@apache.org)
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
On Thu, 14 Aug 2003 01:00:04 -0400
(Subject: RE: [combo] Commons Core release?)
"Noel J. Bergman" <no...@devtech.com> wrote:
> > > Now, Jakarta-ORO think about one of the potentialities
> > > of the transfer to commons-proper. (How about Regexp, ECS?)
> > 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.
> If you look at the mailing list for oro
> (http://nagoya.apache.org/eyebrowse/BrowseList?listName=oro-dev@jakarta.apache.org&by=date&from=2003-08-01&to=2003-08-31&first=1&count=15),
> you'll see that coming here is one of the options. I think that it
> makes sense to invite them.
Is this Jakarta PMC matter? Anyway, oro/regexp/ecs are all compact and
would fit to the commons-proper charter.
> > Only if combo is truly a combination of every Commons package that you
> > need :-).
> I agree. For example, the ones interesting to James are Collection, Pool,
> DBCP, NET and ORO.
Haha. Anyway, one of the possibilities is "Jakarta Commons Combo".
The other is "Apache Commons Combo" (Apache Commons Project, so
components in db-commons/xml-commons can join to it)
--
Again and again, "Bye bye! too many jars! ;-)"
-- Tetsuya (tetsuya@apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, August 14, 2003, at 05:29 AM, Craig R. McClanahan wrote:
> On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
<snip>
>> Combo project is very attractive and useful for most of the
>> java engineers. Oro, Regexp, ECS can join to it, i think.
>
> 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.
ECS is big (i make it 383 source files) and is a framework. though it's a
good fit in some other ways, i'd say that it's definitely out of scope.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Thursday, August 14, 2003, at 05:29 AM, Craig R. McClanahan wrote:
> On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
<snip>
>> Combo project is very attractive and useful for most of the
>> java engineers. Oro, Regexp, ECS can join to it, i think.
>
> 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.
ECS is big (i make it 383 source files) and is a framework. though it's a
good fit in some other ways, i'd say that it's definitely out of scope.
- robert
RE: [combo] Commons Core release?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Craig R. McClanahan:
> Tetsuya wrote:
> > Now, Jakarta-ORO think about one of the potentialities
> > of the transfer to commons-proper. (How about Regexp, ECS?)
> 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.
If you look at the mailing list for oro
(http://nagoya.apache.org/eyebrowse/BrowseList?listName=oro-dev@jakarta.apac
he.org&by=date&from=2003-08-01&to=2003-08-31&first=1&count=15), you'll see
that coming here is one of the options. I think that it makes sense to
invite them.
> Only if combo is truly a combination of every Commons package that you
> need :-).
I agree. For example, the ones interesting to James are Collection, Pool,
DBCP, NET and ORO.
--- Noel
RE: [combo] Commons Core release?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Craig R. McClanahan:
> Tetsuya wrote:
> > Now, Jakarta-ORO think about one of the potentialities
> > of the transfer to commons-proper. (How about Regexp, ECS?)
> 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.
If you look at the mailing list for oro
(http://nagoya.apache.org/eyebrowse/BrowseList?listName=oro-dev@jakarta.apac
he.org&by=date&from=2003-08-01&to=2003-08-31&first=1&count=15), you'll see
that coming here is one of the options. I think that it makes sense to
invite them.
> Only if combo is truly a combination of every Commons package that you
> need :-).
I agree. For example, the ones interesting to James are Collection, Pool,
DBCP, NET and ORO.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
> Date: Thu, 14 Aug 2003 13:13:40 +0900
> From: Tetsuya Kitahata <te...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [combo] Commons Core release?
>
>
> Now, Jakarta-ORO think about one of the potentialities
> of the transfer to commons-proper. (How about Regexp, ECS?)
>
> Combo project is very attractive and useful for most of the
> java engineers. Oro, Regexp, ECS can join to it, i think.
>
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.
> Bye bye, "too many jars" problem :-)
>
Only if combo is truly a combination of every Commons package that you
need :-).
> Sincerely,
>
> -- Tetsuya (tetsuya@apache.org)
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 14 Aug 2003, Tetsuya Kitahata wrote:
> Date: Thu, 14 Aug 2003 13:13:40 +0900
> From: Tetsuya Kitahata <te...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [combo] Commons Core release?
>
>
> Now, Jakarta-ORO think about one of the potentialities
> of the transfer to commons-proper. (How about Regexp, ECS?)
>
> Combo project is very attractive and useful for most of the
> java engineers. Oro, Regexp, ECS can join to it, i think.
>
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.
> Bye bye, "too many jars" problem :-)
>
Only if combo is truly a combination of every Commons package that you
need :-).
> Sincerely,
>
> -- Tetsuya (tetsuya@apache.org)
>
Craig
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
Now, Jakarta-ORO think about one of the potentialities
of the transfer to commons-proper. (How about Regexp, ECS?)
Combo project is very attractive and useful for most of the
java engineers. Oro, Regexp, ECS can join to it, i think.
Bye bye, "too many jars" problem :-)
Sincerely,
-- Tetsuya (tetsuya@apache.org)
On Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
(Subject: [combo] Commons Core release?)
Henri Yandell <ba...@generationjava.com> wrote:
>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
>
> 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.
>
> 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:
>
> =====
> Apache Commons Core v1.0 consists of:
>
> Jakarta Commons BeanUtils 1.6.1
> Makes the JavaBean specification easier to deal with.
>
> Jakarta Commons CLI 1.0
> A command line interpreter. Used to handle all the flags passed to your
> program on the command line.
>
> Jakarta Commons Codec 1.1
> Common encoders and decoders.
>
> Jakarta Commons Collections 2.1
> Many more implementations that fit the Collections API.
>
> Jakarta Commons Lang 1.0.1
> Enhancements to classes found in java.lang.
> =======
>
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
>
> 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.
>
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
>
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
>
> ====
>
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
>
> No idea if it's a good solution :) It seems quite fun and interesting.
>
> Any ideas? Flames?
>
> My chief two concerns are:
>
>
> 1) Can I treat Combo as a Commons Proper project.
> 2) Is the idea of a Commons Core distribution viable.
>
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Tomasz Pik <pi...@ais.pl>.
A little different idea:
How about creating plugin for Maven that will repackage
all libraries defined as dependency into one jar?
(note problem with MANIFEST file here).
Then everybody may create own 'combo' just by writing
project.xml file.
I know it's different idea then releasing 'combo' as
separate package but this will help developers avoid
having many jars used in their apps without releasing
new combo every new commons core package.
And I think that discussion, what should be included
in combo will be the longest thread on this list...
Regards,
Tomek
PS There's 'uberjar' plugin but it's working like this.
Re: [combo] Commons Core release?
Posted by Tetsuya Kitahata <te...@apache.org>.
Now, Jakarta-ORO think about one of the potentialities
of the transfer to commons-proper. (How about Regexp, ECS?)
Combo project is very attractive and useful for most of the
java engineers. Oro, Regexp, ECS can join to it, i think.
Bye bye, "too many jars" problem :-)
Sincerely,
-- Tetsuya (tetsuya@apache.org)
On Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
(Subject: [combo] Commons Core release?)
Henri Yandell <ba...@generationjava.com> wrote:
>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
>
> 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.
>
> 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:
>
> =====
> Apache Commons Core v1.0 consists of:
>
> Jakarta Commons BeanUtils 1.6.1
> Makes the JavaBean specification easier to deal with.
>
> Jakarta Commons CLI 1.0
> A command line interpreter. Used to handle all the flags passed to your
> program on the command line.
>
> Jakarta Commons Codec 1.1
> Common encoders and decoders.
>
> Jakarta Commons Collections 2.1
> Many more implementations that fit the Collections API.
>
> Jakarta Commons Lang 1.0.1
> Enhancements to classes found in java.lang.
> =======
>
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
>
> 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.
>
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
>
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
>
> ====
>
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
>
> No idea if it's a good solution :) It seems quite fun and interesting.
>
> Any ideas? Flames?
>
> My chief two concerns are:
>
>
> 1) Can I treat Combo as a Commons Proper project.
> 2) Is the idea of a Commons Core distribution viable.
>
>
> Hen
Re: [combo] Commons Core release?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Comments interspersed.
On Thu, 14 Aug 2003, Henri Yandell wrote:
> Date: Thu, 14 Aug 2003 00:02:52 -0400 (EDT)
> From: Henri Yandell <ba...@generationjava.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: [combo] Commons Core release?
>
>
> Last November [I think] Craig created the Combo project. It puts a whole
> lot of Commons projects into one jar and makes them available in a much
> simpler form to users.
>
> 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.
> 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.
>
> =====
> Apache Commons Core v1.0 consists of:
>
> Jakarta Commons BeanUtils 1.6.1
> Makes the JavaBean specification easier to deal with.
>
> Jakarta Commons CLI 1.0
> A command line interpreter. Used to handle all the flags passed to your
> program on the command line.
>
> Jakarta Commons Codec 1.1
> Common encoders and decoders.
>
> Jakarta Commons Collections 2.1
> Many more implementations that fit the Collections API.
>
> Jakarta Commons Lang 1.0.1
> Enhancements to classes found in java.lang.
> =======
>
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
> 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.")
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.
> *) Arguments over what goes in what. Rather than create a huge jar of
> everything, which I think is unpalatable to the user, I chose the JDK 1.4
> dependency as a strict guideline and tried to make things toe the line.
> Effectively it's a Commons-J2SE distribution for adding features to a
> new J2SE install.
>
> *) Testing. In Core 1.0 I've chosen the latest stable releases [except
> HttpClient which is at RC2] of each project. There are no
> interdependencies, but as projects depend on each other the building of a
> combo jar becomes trickier. This is a problem for the future probably.
> Possibly the solution is that after each component is built/tested, and
> the new uber-jar is built, the tests should be re-run against that jar.
>
> ====
>
> My general idea for Combo is that it is a tool for creating distributions
> of Commons code. These distributions are effectively configurations of
> Combo. I'm not sure if Craig is +1 or -1 for this and what his
> original plans were, but I think there's a need for a solution and that
> this is a solution.
>
> No idea if it's a good solution :) It seems quite fun and interesting.
>
> Any ideas? Flames?
>
> My chief two concerns are:
>
>
> 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.
I'm +0 on setting up the combo build.xml file in such a way that you can
do your own custom subsets.
>
>
> Hen
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [combo] Commons Core release?
Posted by Tomasz Pik <pi...@ais.pl>.
Henri Yandell wrote:
> A url to a build is: http://www.apache.org/~bayard/commons-core/
>
> 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.
That's something that I think should be avoided.
Combo (IMHO) should be a jar containing classes/resources voted
as releases.
If developer will pick up Combo described by a list of packages
included, (s)he must be sure that Combo jar may be replaced by
those packages as they are downloadable jars.
With such regexp magic it's not so obvious.
Regards,
Tomek