Re: [collections] jar file names

[Rodney Waldhoff <rw...@apache.org>]

On Tue, 30 Sep 2003, Stephen Colebourne wrote:

> My aim with this change was to keep the name commons-collections
> for the object only jar. Unfortunately it was late and I read
> the ant file as only producing two jars, one object and one
> primitive. Also, I had thought that was what was agreed
> (ie. no combined jar file).
>
> To be clear this time, my choice for jars is for:
> - commons-collections.jar - object only as it always
> has been
> - commons-collections-primitves.jar - an optional
> additional jar of primitives
> No combination jar, as that leads to
> classpath/version issues.

Commons-collections.jar hasn't always been "object only", indeed, up until
three days ago it contained the primitive collections, as it has since
they were first committed nearly 18 months ago.

I'm not strongly opposed to commons-collections.jar excluding the
primitive collections, as long as some all-inclusive JAR is available.
I'm not sure why you're trying to prohibit that.  A number of projects
(e.g., log4j) and components (e.g., commons-logging) distribute
overlapping JARs without signficant problems.  I'll suggest these
"classpath/version issues" are a hyptothetical problem.  I don't imagaine
anyone is going to be profoundly confused as to whether or not
commons-collections-all.jar contains all of commons-collections.  But as
we saw yesterday, not providing a complete JAR has caused actual classpath
and versioning issues.

> Of course, my view remains that primitives are a
> specialised extension to collections, not part of
> the main code. As you know, I don't believe that
> they should be directly managed with [collections].
> For example, I was going to invite you to write
> the release notes for primitvies, as you are
> the only coder in those packages.
>
> You need to understand that I am far from
> comfortable with managing/releasing these
> classes in this way. Despite being release
> manager, I sometimes feel like -1ing
> my own release.

Don't do anything you're not comfortable with, but frankly I'm beginning
to resent repeated attempts to ghettoize this code base.  The primitive
collections have just as many committers, and quite likely more users, as
other collections sub-packages (notably collections.observed.*). They are
designed around real-world user experience. They have 100% test coverage.
They have been stable for nearly 9 months.  Just because you personally
aren't interested in using this code (or more accurately, just because
you're interested in exploring alternative implementations of this code)
doesn't justify ostracizing it from the rest of the package.  You're
trying to make the primitive collections a second-class citizen here.

As before, if you want to make primitive collections a first class citizen
in another commons proper component, then propose that, but it will
require some extra work to extract the shared bits from the
commons-collections code base.

>
> Stephen
>

- Rod

PS: Now maven and ant generate different commons-collections.jar files,
by the way.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [collections] jar file names

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Rob Oxspring" <ro...@apache.org>
> Is there any reason why both full words couldn't be used? I'm imagining a
> component called collections-primitive that involves no repackaging.  I
> guess it might clash with a future primitives subpackage of collections
> but that's surely not on the cards is it?
>
> > Are you happy for the package to be pcollections?
>
> Can't remember if its in any charter or not but my thinking is that the
> package should always match the compontent name.  When the jar name also
> follows suit and maintanence is so much easier for the end user.

Possible, but I think probably more confusing in the long term. It seems
worth taking a package rename now for the greater clarity.

Stephen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [collections] jar file names

[Rob Oxspring <ro...@apache.org>]

On Thu, 2 Oct 2003 22:25:17 +0100, "Stephen Colebourne"
<sc...@btopenworld.com> said:
> From: "Rodney Waldhoff" <rw...@apache.org>
> > Assuming "pcollections" is up and running (not necessarily released, but
> > with the code moved over, existing as commons proper component with
> > nightly builds and all that) before anything is removed, deprecated or
> > passed over for release from commons-collections, I think I'd support such
> > a proposal.
> All sounds OK. I've created a shell project on my PC, so we just need to
> have a vote for a new commons-proper component I guess. I've attached a
> proposal for you to check out. Let me know if you think it needs changes.
> 
> > On the bikeshed side, I'm not a fan of the name "pcollections", but I
> > don't have anything better either, so I suppose that'll do.
> I don't have anything else better either.

Is there any reason why both full words couldn't be used? I'm imagining a
component called collections-primitive that involves no repackaging.  I
guess it might clash with a future primitives subpackage of collections
but that's surely not on the cards is it?

> 
> Are you happy for the package to be pcollections?

Can't remember if its in any charter or not but my thinking is that the
package should always match the compontent name.  When the jar name also
follows suit and maintanence is so much easier for the end user.

Just more colours,

Rob

> 
> Are you familiar with the website creation aspect (I've not updated the
> website yet :-). Is there a doc/guide? DO we want to use maven for the
> site?
> 
> Stephen
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [collections] jar file names

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

On Thu, 2 Oct 2003, Stephen Colebourne wrote:

> Are you familiar with the website creation aspect (I've not updated the
> website yet :-). Is there a doc/guide? DO we want to use maven for the site?

Let me know if you want help here.

Hen


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [collections] jar file names

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Rodney Waldhoff" <rw...@apache.org>
> Assuming "pcollections" is up and running (not necessarily released, but
> with the code moved over, existing as commons proper component with
> nightly builds and all that) before anything is removed, deprecated or
> passed over for release from commons-collections, I think I'd support such
> a proposal.
All sounds OK. I've created a shell project on my PC, so we just need to
have a vote for a new commons-proper component I guess. I've attached a
proposal for you to check out. Let me know if you think it needs changes.

> On the bikeshed side, I'm not a fan of the name "pcollections", but I
> don't have anything better either, so I suppose that'll do.
I don't have anything else better either.

Are you happy for the package to be pcollections?

Are you familiar with the website creation aspect (I've not updated the
website yet :-). Is there a doc/guide? DO we want to use maven for the site?

Stephen

Re: [collections] jar file names

[Rodney Waldhoff <rw...@apache.org>]

On Wed, 1 Oct 2003, Stephen Colebourne wrote:
> > As before, if you want to make primitive collections a first class citizen
> > in another commons proper component, then propose that, but it will
> > require some extra work to extract the shared bits from the
> > commons-collections code base.
> OK I'll make a proposal:
> 1) We create a new commons-proper component pcollections? to maintain
> primitive collections.
> 2) Code is copied into pcollections, renaming the package. (or maybe it
> could keep the same package?)
> 3) The code in collections is deprecated, with a snapshot jar being made so
> backwards compatability works.
> 4) [collections] produces a commons-collections-tests.jar file to enable the
> tests to work. This contains only the abstract test class framework from
> collections.

Assuming "pcollections" is up and running (not necessarily released, but
with the code moved over, existing as commons proper component with
nightly builds and all that) before anything is removed, deprecated or
passed over for release from commons-collections, I think I'd support such
a proposal.

On the bikeshed side, I'm not a fan of the name "pcollections", but I
don't have anything better either, so I suppose that'll do.

> I am willing to do most of the work.
>
> Stephen

- 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: [collections] jar file names

[__matthewHawthorne <ma...@phreaker.net>]

For what it's worth, I think your proposal may be the best idea.  The 
primitive collections would probably take up the bulk of the 
[primitives] project anyway, and may create some of the same issues in 
that code base as it has with [collections].

It appears that this situation involves a plan to deprecate something 
that hasn't been released yet.  This seems backwards to me.  No matter 
how stable or great the primitive collections have proven to be, they 
haven't been released, so I think it's of utmost importance to make the 
right decision here.  Releasing these classes only to deprecate them in 
a few months isn't any better for users then keeping them in the sandbox 
for a few months until they are promoted and released.   Actually, I 
think the latter is better.

Maybe a larger [vote] is required but I think that moving the primitive 
collections out will be better in the long run for everybody.  The 
benefit of releasing these classes as part of collections 3.0 isn't 
apparent to me.




Stephen Colebourne wrote:

> From: "Rodney Waldhoff" <rw...@apache.org>
> 
>>>Of course, my view remains that primitives are a
>>>specialised extension to collections, not part of
>>>the main code. As you know, I don't believe that
>>>they should be directly managed with [collections].
>>>For example, I was going to invite you to write
>>>the release notes for primitvies, as you are
>>>the only coder in those packages.
>>
>>Don't do anything you're not comfortable with, but frankly I'm beginning
>>to resent repeated attempts to ghettoize this code base.  The primitive
>>collections have just as many committers, and quite likely more users, as
>>other collections sub-packages (notably collections.observed.*). They are
>>designed around real-world user experience. They have 100% test coverage.
>>They have been stable for nearly 9 months.
> 
> I want to be clear that I have no problems with the quality, stability or
> user-base of this code. Good code should be released and used.
> 
> I see this as independence, rather than ghettoization, and I believe it to
> be in the best interests of both areas of code.
> 
> My regret is that I did not fully consider the implications of including the
> primitive packages in collections at the outset. Simply counting java files
> shows that the primitives packages are now about 50% of [collections]. And
> there are no Map implementations yet, or decorators other than a few
> unmodifiable ones.
> 
> In addition the release notes factor weighs on my mind. The document
> describing the release will be very large just with objects, and naturally
> breaks into two.
> 
> 
>>Just because you personally
>>aren't interested in using this code (or more accurately, just because
>>you're interested in exploring alternative implementations of this code)
>>doesn't justify ostracizing it from the rest of the package.  You're
>>trying to make the primitive collections a second-class citizen here.
> 
> Although I can understand how this appears, I was uncomfortable with the
> primitives code in [collections] before starting the sandbox primitives.
> Clearly I should have raised my concerns earlier.
> 
> 
>>As before, if you want to make primitive collections a first class citizen
>>in another commons proper component, then propose that, but it will
>>require some extra work to extract the shared bits from the
>>commons-collections code base.
> 
> OK I'll make a proposal:
> 1) We create a new commons-proper component pcollections? to maintain
> primitive collections.
> 2) Code is copied into pcollections, renaming the package. (or maybe it
> could keep the same package?)
> 3) The code in collections is deprecated, with a snapshot jar being made so
> backwards compatability works.
> 4) [collections] produces a commons-collections-tests.jar file to enable the
> tests to work. This contains only the abstract test class framework from
> collections.
> I am willing to do most of the work.
> 
> Stephen
> PS. The ant script should be reverted now.



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [collections] jar file names

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Rodney Waldhoff" <rw...@apache.org>
> > Of course, my view remains that primitives are a
> > specialised extension to collections, not part of
> > the main code. As you know, I don't believe that
> > they should be directly managed with [collections].
> > For example, I was going to invite you to write
> > the release notes for primitvies, as you are
> > the only coder in those packages.
> Don't do anything you're not comfortable with, but frankly I'm beginning
> to resent repeated attempts to ghettoize this code base.  The primitive
> collections have just as many committers, and quite likely more users, as
> other collections sub-packages (notably collections.observed.*). They are
> designed around real-world user experience. They have 100% test coverage.
> They have been stable for nearly 9 months.
I want to be clear that I have no problems with the quality, stability or
user-base of this code. Good code should be released and used.

I see this as independence, rather than ghettoization, and I believe it to
be in the best interests of both areas of code.

My regret is that I did not fully consider the implications of including the
primitive packages in collections at the outset. Simply counting java files
shows that the primitives packages are now about 50% of [collections]. And
there are no Map implementations yet, or decorators other than a few
unmodifiable ones.

In addition the release notes factor weighs on my mind. The document
describing the release will be very large just with objects, and naturally
breaks into two.

> Just because you personally
> aren't interested in using this code (or more accurately, just because
> you're interested in exploring alternative implementations of this code)
> doesn't justify ostracizing it from the rest of the package.  You're
> trying to make the primitive collections a second-class citizen here.
Although I can understand how this appears, I was uncomfortable with the
primitives code in [collections] before starting the sandbox primitives.
Clearly I should have raised my concerns earlier.

> As before, if you want to make primitive collections a first class citizen
> in another commons proper component, then propose that, but it will
> require some extra work to extract the shared bits from the
> commons-collections code base.
OK I'll make a proposal:
1) We create a new commons-proper component pcollections? to maintain
primitive collections.
2) Code is copied into pcollections, renaming the package. (or maybe it
could keep the same package?)
3) The code in collections is deprecated, with a snapshot jar being made so
backwards compatability works.
4) [collections] produces a commons-collections-tests.jar file to enable the
tests to work. This contains only the abstract test class framework from
collections.
I am willing to do most of the work.

Stephen
PS. The ant script should be reverted now.



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org