commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stanley,Michael P." <mstan...@mitre.org>
Subject Re: [combo] Commons Core release?
Date Thu, 14 Aug 2003 05:48:14 GMT
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" <craigmcc@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 <bayard@generationjava.com>
>>>Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>>>To: Jakarta Commons Developers List <commons-dev@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
>
>  
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message