[collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections ClassMap.java)

["Waldhoff, Rodney" <rw...@us.britannica.com>]

Personally, I'd prefer not to have collections depend upon lang (currently it doesn't depend upon anything else, correct?), at least not if ClassMap is the best justification we have for it. 

A lot of other packages use Collections, so adding a new dependency to Collections is adding a new dependency to a lot of modules.  We should be very careful and deliberate about that.

> Much of the code for getting all the superclasses 
> and superinterfaces of a class is coded in the 
> upcoming [lang] reflection code. Maybe the next 
> collections release should depend on [lang]?

> Stephen

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections ClassMap.java)

["Michael A. Smith" <ma...@apache.org>]

Ok, so I went back to write my little proposal (which I'm not even going 
to mention now).  In order to make sure my proposal was well informed 
and thus a higher chance of being adopted, I went back to take a look at 
previous discussions about commons-core, dependencies between commons 
components, and other related topics.  While very depressing[*], this 
exercise was very informative, and is keeping me from making an 
ill-advised proposal.

Even with the release of a commons-core or a commons-combo or whatever, 
the issue of interdependencies isn't going to go away.  Classes and 
functionality need to be put into the most appropriate classes, and only 
when said functionality is absolutely necessary.

My current thoughts are that maybe this ClassMap shouldn't even be 
there.  While it does provide some interesting functionality that I know 
would be useful for the conversion stuff (as was the original example 
that Hen described), the semantics of the super interface/class is way 
under defined.  And even just adding documentation isn't going to solve 
that, as different people may want different semantics.  I'm beginning 
to think that if someone wants such a functionality they could have 
their project depend on both lang and collections and implement the 
semantics they want on their own.  In other words, I think that ClassMap 
might be a little bit outside the scope of the collections component, 
even if it *is* a map.

btw, an eventual dependency on lang and/or pattern might be acceptable, 
but as Rodney pointed out, ClassMap isn't the best justification for 
doing that at this point.

regards,
michael

[*] If you're curious, search archives in June for messages with the 
subject of "architecture", and messages in August with subject of "cross 
dependecy"[sic] and "pattern charter" (case insensitive).  That was 
right before the start of the nearly two-week long debate on public 
constructors. Fun, fun, fun.

Michael A. Smith wrote:
> Agreed.  Care must be taken when adding dependencies, especially to 
> collections and lang.  I have an alternative suggestion, but want to 
> write it up as a more formal proposal.  Hopefully I'll get that done by 
> the end of the weekend.  
> 
> regards,
> michael
> 
> On Fri, 25 Oct 2002, Waldhoff, Rodney wrote:
> 
>>Personally, I'd prefer not to have collections depend upon lang
>>(currently it doesn't depend upon anything else, correct?), at least
>>not if ClassMap is the best justification we have for it.
>>
>>A lot of other packages use Collections, so adding a new dependency to
>>Collections is adding a new dependency to a lot of modules.  We should
>>be very careful and deliberate about that.
>>
>>
>>>Much of the code for getting all the superclasses 
>>>and superinterfaces of a class is coded in the 
>>>upcoming [lang] reflection code. Maybe the next 
>>>collections release should depend on [lang]?
>>
>>>Stephen
>>
>>--
>>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


-- 
Michael A. Smith
mas@apache.org



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections ClassMap.java)

["Craig R. McClanahan" <cr...@apache.org>]

On Fri, 25 Oct 2002, Steve Downey wrote:

> Date: Fri, 25 Oct 2002 15:35:06 -0400
> From: Steve Downey <st...@netfolio.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: Re: [collections] collections depends on lang? (RE: cvs commit:
>     jakarta-commons/collections/src/java/org/apache/commons/collections
>     ClassMap.java)
>
> When libraries are too small, you start to have to make bad decisions about
> coupling. There are natural ways for lang, collections, beanutils and a few
> others to interact. Coupling them is probably better than duplicating the
> behavior. OTOH, it does introduce more management difficulties, because the
> releases would need to be coordinated.
>
> It is interesting to note that the releases of many of these projects,
> although coordinated separately, do tend to come in waves. The release bug is
> contagious.
>

I took a crack at one way to deal with the coupling problems, by creating
the "combo" directory in the jakarta-commons workspace.  The basic idea
was to allow a developer to create an all-in-one JAR file with your
favorite tagged versions of *all* the released Commons packages -- the
default would be the latest released version of each package.  My thinking
was that, whenever one of the constituent packages did a release, the
release manager would also do an updated commons-combo release.

As an extra added benefit, the build script creates consolidated Javadocs
for the included packages -- something that I've found invaluable in its
own right, completely separate from the combined JAR file.

If you'd like to help me explore whether this would be a useful thing to
work on, feel free to pitch in - I'm sure that the build.xml file there
now is probably somewhat stale, and the CVS checkin log messages for
build.xml mention some FIXME items that weren't done in the first place.

>
>
>
> On Friday 25 October 2002 01:35 pm, Henri Yandell wrote:
> > *chants*
> > commons-core commons-core
> > */chants*
> >
> > :)
> >

Or maybe  commons-combo ... commons-combo ... :-)


Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections ClassMap.java)

[Steve Downey <st...@netfolio.com>]

When libraries are too small, you start to have to make bad decisions about 
coupling. There are natural ways for lang, collections, beanutils and a few 
others to interact. Coupling them is probably better than duplicating the 
behavior. OTOH, it does introduce more management difficulties, because the 
releases would need to be coordinated.

It is interesting to note that the releases of many of these projects, 
although coordinated separately, do tend to come in waves. The release bug is 
contagious.




On Friday 25 October 2002 01:35 pm, Henri Yandell wrote:
> *chants*
> commons-core commons-core
> */chants*
>
> :)
>
> Also got the itch to have a solution to this. If a friend and I can iron
> out our idea it might be worthy of mentioning.
>
> On Fri, 25 Oct 2002, Michael A. Smith wrote:
> > Agreed.  Care must be taken when adding dependencies, especially to
> > collections and lang.  I have an alternative suggestion, but want to
> > write it up as a more formal proposal.  Hopefully I'll get that done by
> > the end of the weekend.
> >
> > regards,
> > michael
> >
> > On Fri, 25 Oct 2002, Waldhoff, Rodney wrote:
> > > Personally, I'd prefer not to have collections depend upon lang
> > > (currently it doesn't depend upon anything else, correct?), at least
> > > not if ClassMap is the best justification we have for it.
> > >
> > > A lot of other packages use Collections, so adding a new dependency to
> > > Collections is adding a new dependency to a lot of modules.  We should
> > > be very careful and deliberate about that.
> > >
> > > > Much of the code for getting all the superclasses
> > > > and superinterfaces of a class is coded in the
> > > > upcoming [lang] reflection code. Maybe the next
> > > > collections release should depend on [lang]?
> > > >
> > > > Stephen
> > >
> > > --
> > > To unsubscribe, e-mail:  
> > > <ma...@jakarta.apache.org> For additional
> > > commands, e-mail: <ma...@jakarta.apache.org>
> >
> > --
> > To unsubscribe, e-mail:  
> > <ma...@jakarta.apache.org> For additional
> > commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections ClassMap.java)

[Henri Yandell <ba...@generationjava.com>]

*chants*
commons-core commons-core
*/chants*

:)

Also got the itch to have a solution to this. If a friend and I can iron
out our idea it might be worthy of mentioning.

On Fri, 25 Oct 2002, Michael A. Smith wrote:

> Agreed.  Care must be taken when adding dependencies, especially to
> collections and lang.  I have an alternative suggestion, but want to
> write it up as a more formal proposal.  Hopefully I'll get that done by
> the end of the weekend.
>
> regards,
> michael
>
> On Fri, 25 Oct 2002, Waldhoff, Rodney wrote:
> > Personally, I'd prefer not to have collections depend upon lang
> > (currently it doesn't depend upon anything else, correct?), at least
> > not if ClassMap is the best justification we have for it.
> >
> > A lot of other packages use Collections, so adding a new dependency to
> > Collections is adding a new dependency to a lot of modules.  We should
> > be very careful and deliberate about that.
> >
> > > Much of the code for getting all the superclasses
> > > and superinterfaces of a class is coded in the
> > > upcoming [lang] reflection code. Maybe the next
> > > collections release should depend on [lang]?
> >
> > > Stephen
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections ClassMap.java)

["Michael A. Smith" <ma...@apache.org>]

Agreed.  Care must be taken when adding dependencies, especially to 
collections and lang.  I have an alternative suggestion, but want to 
write it up as a more formal proposal.  Hopefully I'll get that done by 
the end of the weekend.  

regards,
michael

On Fri, 25 Oct 2002, Waldhoff, Rodney wrote:
> Personally, I'd prefer not to have collections depend upon lang
> (currently it doesn't depend upon anything else, correct?), at least
> not if ClassMap is the best justification we have for it.
> 
> A lot of other packages use Collections, so adding a new dependency to
> Collections is adding a new dependency to a lot of modules.  We should
> be very careful and deliberate about that.
> 
> > Much of the code for getting all the superclasses 
> > and superinterfaces of a class is coded in the 
> > upcoming [lang] reflection code. Maybe the next 
> > collections release should depend on [lang]?
> 
> > Stephen
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>