[collections] Cleanup of trunk

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[collections] Cleanup of trunk

Thomas Neidhart
Hi,

I recently started to work more on collections and cleaning up the trunk
to make it a candidate for a release and would like to ask a few questions:

 - there is still lots of javadoc missing, moving the source code level
   to Java 1.6 would allow the use of @Override in more places (instead
   of putting a /** {inheritDoc} */ everywhere)

   this has been discussed for vfs a few weeks ago, and my
   understanding was that this proposal was well received, so what do
   you think about doing the same for collections?

 - unit tests: there are currently two unit tests for certain classes
   that are almost similar, e.g. TestListOrderedMap and
   TestListOrderedMap2. Does anybody know why this exists?

   also I would like to go to annotation based unit tests like in the
   other components and rename the tests to the common style:
   ClassNameTest.

 - consistency with commons rules. There are several things that are
   different to other components atm:

   o authors contained in source files
   o no changes.xml to track changes
   o since and version tags are a bit different
   o package.html should be package-info.java

   and I guess other things too that I have not spotted yet.


Are there any objections / suggestions to continue with the cleanup?

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

sebb-2-2
On 24 June 2012 10:28, Thomas Neidhart <[hidden email]> wrote:
> Hi,
>
> I recently started to work more on collections and cleaning up the trunk
> to make it a candidate for a release and would like to ask a few questions:
>
>  - there is still lots of javadoc missing, moving the source code level
>   to Java 1.6 would allow the use of @Override in more places (instead
>   of putting a /** {inheritDoc} */ everywhere)

AFAICT Javadoc is automatically inherited for methods that implement
an interface.
Being able to add @Override to an interface implementation does not
gain anything.

>   this has been discussed for vfs a few weeks ago, and my
>   understanding was that this proposal was well received, so what do
>   you think about doing the same for collections?

No, we should only require Java 6 if strictly necessary for some new
functionality it provides.
Javadoc is not a good enough reason.

>  - unit tests: there are currently two unit tests for certain classes
>   that are almost similar, e.g. TestListOrderedMap and
>   TestListOrderedMap2. Does anybody know why this exists?
>
>   also I would like to go to annotation based unit tests like in the
>   other components and rename the tests to the common style:
>   ClassNameTest.

OK.

>  - consistency with commons rules. There are several things that are
>   different to other components atm:
>
>   o authors contained in source files

OK, but original authors still need to be creditted e.g. in pom.xml.

>   o no changes.xml to track changes
>   o since and version tags are a bit different
>   o package.html should be package-info.java

OK.

>   and I guess other things too that I have not spotted yet.
>
>
> Are there any objections / suggestions to continue with the cleanup?

I object to moving to Java 6 without a compelling reason.

> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

garydgregory
In reply to this post by Thomas Neidhart
I am +1 to all your proposed changes.

Gary

On Jun 24, 2012, at 5:29, Thomas Neidhart <[hidden email]> wrote:

> Hi,
>
> I recently started to work more on collections and cleaning up the trunk
> to make it a candidate for a release and would like to ask a few questions:
>
> - there is still lots of javadoc missing, moving the source code level
>   to Java 1.6 would allow the use of @Override in more places (instead
>   of putting a /** {inheritDoc} */ everywhere)
>
>   this has been discussed for vfs a few weeks ago, and my
>   understanding was that this proposal was well received, so what do
>   you think about doing the same for collections?
>
> - unit tests: there are currently two unit tests for certain classes
>   that are almost similar, e.g. TestListOrderedMap and
>   TestListOrderedMap2. Does anybody know why this exists?
>
>   also I would like to go to annotation based unit tests like in the
>   other components and rename the tests to the common style:
>   ClassNameTest.
>
> - consistency with commons rules. There are several things that are
>   different to other components atm:
>
>   o authors contained in source files
>   o no changes.xml to track changes
>   o since and version tags are a bit different
>   o package.html should be package-info.java
>
>   and I guess other things too that I have not spotted yet.
>
>
> Are there any objections / suggestions to continue with the cleanup?
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Benedikt Ritter-2
Are we going through that Java 5 vs Java 6 discussion again? ;)

Thomas: I always wanted to work on collections but there hasn't been much activity since I joined the ML. I'd be happy to contribute some patches.

Benedikt

Von meinem iPhone gesendet

Am 24.06.2012 um 14:10 schrieb Gary Gregory <[hidden email]>:

> I am +1 to all your proposed changes.
>
> Gary
>
> On Jun 24, 2012, at 5:29, Thomas Neidhart <[hidden email]> wrote:
>
>> Hi,
>>
>> I recently started to work more on collections and cleaning up the trunk
>> to make it a candidate for a release and would like to ask a few questions:
>>
>> - there is still lots of javadoc missing, moving the source code level
>>  to Java 1.6 would allow the use of @Override in more places (instead
>>  of putting a /** {inheritDoc} */ everywhere)
>>
>>  this has been discussed for vfs a few weeks ago, and my
>>  understanding was that this proposal was well received, so what do
>>  you think about doing the same for collections?
>>
>> - unit tests: there are currently two unit tests for certain classes
>>  that are almost similar, e.g. TestListOrderedMap and
>>  TestListOrderedMap2. Does anybody know why this exists?
>>
>>  also I would like to go to annotation based unit tests like in the
>>  other components and rename the tests to the common style:
>>  ClassNameTest.
>>
>> - consistency with commons rules. There are several things that are
>>  different to other components atm:
>>
>>  o authors contained in source files
>>  o no changes.xml to track changes
>>  o since and version tags are a bit different
>>  o package.html should be package-info.java
>>
>>  and I guess other things too that I have not spotted yet.
>>
>>
>> Are there any objections / suggestions to continue with the cleanup?
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Adrian Crum-3
In reply to this post by sebb-2-2
On 6/24/2012 12:25 PM, sebb wrote:

> On 24 June 2012 10:28, Thomas Neidhart <[hidden email]> wrote:
>> Hi,
>>
>> I recently started to work more on collections and cleaning up the trunk
>> to make it a candidate for a release and would like to ask a few questions:
>>
>>   - there is still lots of javadoc missing, moving the source code level
>>    to Java 1.6 would allow the use of @Override in more places (instead
>>    of putting a /** {inheritDoc} */ everywhere)
> AFAICT Javadoc is automatically inherited for methods that implement
> an interface.
> Being able to add @Override to an interface implementation does not
> gain anything.

True, you don't gain anything in JavaDocs, but it is still worth adding
because the compiler will let you know if your implementation does not
match the interface.

-Adrian


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

sebb-2-2
On 24 June 2012 13:42, Adrian Crum <[hidden email]> wrote:

> On 6/24/2012 12:25 PM, sebb wrote:
>>
>> On 24 June 2012 10:28, Thomas Neidhart <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I recently started to work more on collections and cleaning up the trunk
>>> to make it a candidate for a release and would like to ask a few
>>> questions:
>>>
>>>  - there is still lots of javadoc missing, moving the source code level
>>>   to Java 1.6 would allow the use of @Override in more places (instead
>>>   of putting a /** {inheritDoc} */ everywhere)
>>
>> AFAICT Javadoc is automatically inherited for methods that implement
>> an interface.
>> Being able to add @Override to an interface implementation does not
>> gain anything.
>
>
> True, you don't gain anything in JavaDocs, but it is still worth adding
> because the compiler will let you know if your implementation does not match
> the interface.

Not in the short term, as the most likely scenario is to just add
@Override to all implementing methods when prompted by the
compiler/IDE.

There are likely too many methods to examine each to see if it should
be an implementing method or not.
And if there is an existing method that was intended to implement an
interface, but does not, it won't catch that.
The only way to catch that is to look at each method individually and
see if it should override or implement something.

This checking can be done already in any decent IDE.

In the longer term, the most likely benefit is that it will flag
unused implementations, e.g. if a class drops an interface.
It will only help with maintenance if the committer adds @Override as
part of any new code.
That often does not happen with Java 5 overrides, so the same will be
true of interface overrides.

That's not to say it should not be used, but at best it is a
side-benefit of Java 6.
It's not a good reason on its own to move to Java 6.

> -Adrian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Thomas Neidhart
Hi,

thanks for all the feedback. I will then postpone all Java 6 related
changes but start with the other ones.

I hope my activity will spark some more interest by other people as it
would be a pity to never release a generic version of collections if it is
there and ready to be used.

Thomas
Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Xavier Detant
Hi,

even if my English is not as good as I'd like, I'd be happy to work with
you on it.

Furthermore, I +1 all your proposition (even if Java 6 dependency may be
discussed).

2012/6/25 Thomas Neidhart <[hidden email]>

> Hi,
>
> thanks for all the feedback. I will then postpone all Java 6 related
> changes but start with the other ones.
>
> I hope my activity will spark some more interest by other people as it
> would be a pity to never release a generic version of collections if it is
> there and ready to be used.
>
> Thomas
>



--
Xavier DETANT
Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

jodastephen
In reply to this post by sebb-2-2
On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
Sebb, someone needs to check to see if any collections in
[collections] could implement the new interfaces added in Java 6 -
NavigableSet, NavigableMap and so on.

Stephen



On 24 June 2012 12:25, sebb <[hidden email]> wrote:

> On 24 June 2012 10:28, Thomas Neidhart <[hidden email]> wrote:
>> Hi,
>>
>> I recently started to work more on collections and cleaning up the trunk
>> to make it a candidate for a release and would like to ask a few questions:
>>
>>  - there is still lots of javadoc missing, moving the source code level
>>   to Java 1.6 would allow the use of @Override in more places (instead
>>   of putting a /** {inheritDoc} */ everywhere)
>
> AFAICT Javadoc is automatically inherited for methods that implement
> an interface.
> Being able to add @Override to an interface implementation does not
> gain anything.
>
>>   this has been discussed for vfs a few weeks ago, and my
>>   understanding was that this proposal was well received, so what do
>>   you think about doing the same for collections?
>
> No, we should only require Java 6 if strictly necessary for some new
> functionality it provides.
> Javadoc is not a good enough reason.
>
>>  - unit tests: there are currently two unit tests for certain classes
>>   that are almost similar, e.g. TestListOrderedMap and
>>   TestListOrderedMap2. Does anybody know why this exists?
>>
>>   also I would like to go to annotation based unit tests like in the
>>   other components and rename the tests to the common style:
>>   ClassNameTest.
>
> OK.
>
>>  - consistency with commons rules. There are several things that are
>>   different to other components atm:
>>
>>   o authors contained in source files
>
> OK, but original authors still need to be creditted e.g. in pom.xml.
>
>>   o no changes.xml to track changes
>>   o since and version tags are a bit different
>>   o package.html should be package-info.java
>
> OK.
>
>>   and I guess other things too that I have not spotted yet.
>>
>>
>> Are there any objections / suggestions to continue with the cleanup?
>
> I object to moving to Java 6 without a compelling reason.
>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

James Carman-3
If none of the existing collections could use it, write a new one!  Java 6
FTW!
On Jun 25, 2012 9:10 AM, "Stephen Colebourne" <[hidden email]> wrote:

> On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
> Sebb, someone needs to check to see if any collections in
> [collections] could implement the new interfaces added in Java 6 -
> NavigableSet, NavigableMap and so on.
>
> Stephen
>
>
>
> On 24 June 2012 12:25, sebb <[hidden email]> wrote:
> > On 24 June 2012 10:28, Thomas Neidhart <[hidden email]>
> wrote:
> >> Hi,
> >>
> >> I recently started to work more on collections and cleaning up the trunk
> >> to make it a candidate for a release and would like to ask a few
> questions:
> >>
> >>  - there is still lots of javadoc missing, moving the source code level
> >>   to Java 1.6 would allow the use of @Override in more places (instead
> >>   of putting a /** {inheritDoc} */ everywhere)
> >
> > AFAICT Javadoc is automatically inherited for methods that implement
> > an interface.
> > Being able to add @Override to an interface implementation does not
> > gain anything.
> >
> >>   this has been discussed for vfs a few weeks ago, and my
> >>   understanding was that this proposal was well received, so what do
> >>   you think about doing the same for collections?
> >
> > No, we should only require Java 6 if strictly necessary for some new
> > functionality it provides.
> > Javadoc is not a good enough reason.
> >
> >>  - unit tests: there are currently two unit tests for certain classes
> >>   that are almost similar, e.g. TestListOrderedMap and
> >>   TestListOrderedMap2. Does anybody know why this exists?
> >>
> >>   also I would like to go to annotation based unit tests like in the
> >>   other components and rename the tests to the common style:
> >>   ClassNameTest.
> >
> > OK.
> >
> >>  - consistency with commons rules. There are several things that are
> >>   different to other components atm:
> >>
> >>   o authors contained in source files
> >
> > OK, but original authors still need to be creditted e.g. in pom.xml.
> >
> >>   o no changes.xml to track changes
> >>   o since and version tags are a bit different
> >>   o package.html should be package-info.java
> >
> > OK.
> >
> >>   and I guess other things too that I have not spotted yet.
> >>
> >>
> >> Are there any objections / suggestions to continue with the cleanup?
> >
> > I object to moving to Java 6 without a compelling reason.
> >
> >> Thomas
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Liviu Tudor
In reply to this post by Thomas Neidhart
Hi Thomas,

A bit late with my reply, sorry -- but if you could do with an extra pair
of hands on this I'd be happy to help!
Regards,


Liv
 
Liviu Tudor
 
E: [hidden email]
C: +1 650-2833815 (USA)
M: +44 (0)7591540313 (UK, Europe)
W: http://about.me/liviutudor
Skype: liviutudor
 
I'm nobody, nobody's perfect -- therefore I'm perfect!

 





On 25/06/2012 05:14, "Thomas Neidhart" <[hidden email]> wrote:

>Hi,
>
>thanks for all the feedback. I will then postpone all Java 6 related
>changes but start with the other ones.
>
>I hope my activity will spark some more interest by other people as it
>would be a pity to never release a generic version of collections if it is
>there and ready to be used.
>
>Thomas



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Thomas Neidhart
On 06/25/2012 08:41 PM, Liviu Tudor wrote:
> Hi Thomas,
>
> A bit late with my reply, sorry -- but if you could do with an extra pair
> of hands on this I'd be happy to help!

Hi,

apart from the normal cleanup, adding unit tests and javadoc, I would
like to see the following features added:

 - add useful collections from mina (COLLECTIONS-342, COLLECTIONS-354)
 - add the patricia tree implementation (COLLECTIONS-225), 9 votes
 - add a generalized suffix tree implementation
   (see https://github.com/abahgat/suffixtree)

so if somebody has the time and interest to provide patches for this is
very welcome ;-).

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Liviu Tudor
Hi Thomas,

Thanks for your reply! I'll have a look at those tickets and let you know
which ones I (think I) can handle.
Thanks again,


Liv
 
Liviu Tudor
 
E: [hidden email]
C: +1 650-2833815 (USA)
M: +44 (0)7591540313 (UK, Europe)
W: http://about.me/liviutudor
Skype: liviutudor
 
I'm nobody, nobody's perfect -- therefore I'm perfect!

 





On 25/06/2012 12:32, "Thomas Neidhart" <[hidden email]> wrote:

>On 06/25/2012 08:41 PM, Liviu Tudor wrote:
>> Hi Thomas,
>>
>> A bit late with my reply, sorry -- but if you could do with an extra
>>pair
>> of hands on this I'd be happy to help!
>
>Hi,
>
>apart from the normal cleanup, adding unit tests and javadoc, I would
>like to see the following features added:
>
> - add useful collections from mina (COLLECTIONS-342, COLLECTIONS-354)
> - add the patricia tree implementation (COLLECTIONS-225), 9 votes
> - add a generalized suffix tree implementation
>   (see https://github.com/abahgat/suffixtree)
>
>so if somebody has the time and interest to provide patches for this is
>very welcome ;-).
>
>Thomas
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Simone Tripodi-2
In reply to this post by Thomas Neidhart
Hi all,

at [graph] we also have the following collections implementations that
could be imported to [collections]:

 - Fibonacci Heap
<http://staff.ustc.edu.cn/~csli/graduate/algorithms/book6/chap21.htm>
 - DisjointSet <http://en.wikipedia.org/wiki/Disjoint-set_data_structure>

I think they can fit the new current [collection] development, as
proposed time ago. Thoughts?

Have a nice day, all the best,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Mon, Jun 25, 2012 at 9:32 PM, Thomas Neidhart
<[hidden email]> wrote:

> On 06/25/2012 08:41 PM, Liviu Tudor wrote:
>> Hi Thomas,
>>
>> A bit late with my reply, sorry -- but if you could do with an extra pair
>> of hands on this I'd be happy to help!
>
> Hi,
>
> apart from the normal cleanup, adding unit tests and javadoc, I would
> like to see the following features added:
>
>  - add useful collections from mina (COLLECTIONS-342, COLLECTIONS-354)
>  - add the patricia tree implementation (COLLECTIONS-225), 9 votes
>  - add a generalized suffix tree implementation
>   (see https://github.com/abahgat/suffixtree)
>
> so if somebody has the time and interest to provide patches for this is
> very welcome ;-).
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Jörg Schaible
In reply to this post by Thomas Neidhart
Hi Thomas,

Thomas Neidhart wrote:

> Hi,
>
> I recently started to work more on collections and cleaning up the trunk
> to make it a candidate for a release and would like to ask a few
> questions:
>
>  - there is still lots of javadoc missing, moving the source code level
>    to Java 1.6 would allow the use of @Override in more places (instead
>    of putting a /** {inheritDoc} */ everywhere)
>
>    this has been discussed for vfs a few weeks ago, and my
>    understanding was that this proposal was well received, so what do
>    you think about doing the same for collections?
>
>  - unit tests: there are currently two unit tests for certain classes
>    that are almost similar, e.g. TestListOrderedMap and
>    TestListOrderedMap2. Does anybody know why this exists?
>
>    also I would like to go to annotation based unit tests like in the
>    other components and rename the tests to the common style:
>    ClassNameTest.
>
>  - consistency with commons rules. There are several things that are
>    different to other components atm:
>
>    o authors contained in source files
>    o no changes.xml to track changes
>    o since and version tags are a bit different
>    o package.html should be package-info.java
>
>    and I guess other things too that I have not spotted yet.
>
>
> Are there any objections / suggestions to continue with the cleanup?

A short overview clearly indicates that cc4 won't be a drop-in replacement
for cc3. Therefore we have to change the groupId/artifactId now to
org.apache.commons:commons-collections4 and the package should be renamed to
org.apache.commons.collections4 (according the rules we used for lang3).

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Thomas Neidhart
On 07/03/2012 11:04 PM, Jörg Schaible wrote:

> Hi Thomas,
>
> Thomas Neidhart wrote:
>
>> Hi,
>>
>> I recently started to work more on collections and cleaning up the trunk
>> to make it a candidate for a release and would like to ask a few
>> questions:
>>
>>  - there is still lots of javadoc missing, moving the source code level
>>    to Java 1.6 would allow the use of @Override in more places (instead
>>    of putting a /** {inheritDoc} */ everywhere)
>>
>>    this has been discussed for vfs a few weeks ago, and my
>>    understanding was that this proposal was well received, so what do
>>    you think about doing the same for collections?
>>
>>  - unit tests: there are currently two unit tests for certain classes
>>    that are almost similar, e.g. TestListOrderedMap and
>>    TestListOrderedMap2. Does anybody know why this exists?
>>
>>    also I would like to go to annotation based unit tests like in the
>>    other components and rename the tests to the common style:
>>    ClassNameTest.
>>
>>  - consistency with commons rules. There are several things that are
>>    different to other components atm:
>>
>>    o authors contained in source files
>>    o no changes.xml to track changes
>>    o since and version tags are a bit different
>>    o package.html should be package-info.java
>>
>>    and I guess other things too that I have not spotted yet.
>>
>>
>> Are there any objections / suggestions to continue with the cleanup?
>
> A short overview clearly indicates that cc4 won't be a drop-in replacement
> for cc3. Therefore we have to change the groupId/artifactId now to
> org.apache.commons:commons-collections4 and the package should be renamed to
> org.apache.commons.collections4 (according the rules we used for lang3).

Yes, there is already an issue for this: COLLECTIONS-382. The question
is do we change asap or shortly before a release (the way it was done
for commons-math afaik)?

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

sebb-2-2
On 3 July 2012 22:43, Thomas Neidhart <[hidden email]> wrote:

> On 07/03/2012 11:04 PM, Jörg Schaible wrote:
>> Hi Thomas,
>>
>> Thomas Neidhart wrote:
>>
>>> Hi,
>>>
>>> I recently started to work more on collections and cleaning up the trunk
>>> to make it a candidate for a release and would like to ask a few
>>> questions:
>>>
>>>  - there is still lots of javadoc missing, moving the source code level
>>>    to Java 1.6 would allow the use of @Override in more places (instead
>>>    of putting a /** {inheritDoc} */ everywhere)
>>>
>>>    this has been discussed for vfs a few weeks ago, and my
>>>    understanding was that this proposal was well received, so what do
>>>    you think about doing the same for collections?
>>>
>>>  - unit tests: there are currently two unit tests for certain classes
>>>    that are almost similar, e.g. TestListOrderedMap and
>>>    TestListOrderedMap2. Does anybody know why this exists?
>>>
>>>    also I would like to go to annotation based unit tests like in the
>>>    other components and rename the tests to the common style:
>>>    ClassNameTest.
>>>
>>>  - consistency with commons rules. There are several things that are
>>>    different to other components atm:
>>>
>>>    o authors contained in source files
>>>    o no changes.xml to track changes
>>>    o since and version tags are a bit different
>>>    o package.html should be package-info.java
>>>
>>>    and I guess other things too that I have not spotted yet.
>>>
>>>
>>> Are there any objections / suggestions to continue with the cleanup?
>>
>> A short overview clearly indicates that cc4 won't be a drop-in replacement
>> for cc3. Therefore we have to change the groupId/artifactId now to
>> org.apache.commons:commons-collections4 and the package should be renamed to
>> org.apache.commons.collections4 (according the rules we used for lang3).
>
> Yes, there is already an issue for this: COLLECTIONS-382. The question
> is do we change asap or shortly before a release (the way it was done
> for commons-math afaik)?

Doing the package rename just before release makes it possible to
easily run Clirr.
This can be used to help in creating the release notes - we'll need to
document how to upgrade.

AFAIK there's no benefit in changing the package rename earlier.

>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

James Carman-3
Early adopters who can provide valuable feedback might run into the
troubles we try to address by the package and group/artifact I'd changes.
Other than that, I would agree that there doesn't seem to be any reason to
change it now.

Sent from tablet device.  Please excuse typos and brevity.
On Jul 3, 2012 5:58 PM, "sebb" <[hidden email]> wrote:

> On 3 July 2012 22:43, Thomas Neidhart <[hidden email]> wrote:
> > On 07/03/2012 11:04 PM, Jörg Schaible wrote:
> >> Hi Thomas,
> >>
> >> Thomas Neidhart wrote:
> >>
> >>> Hi,
> >>>
> >>> I recently started to work more on collections and cleaning up the
> trunk
> >>> to make it a candidate for a release and would like to ask a few
> >>> questions:
> >>>
> >>>  - there is still lots of javadoc missing, moving the source code level
> >>>    to Java 1.6 would allow the use of @Override in more places (instead
> >>>    of putting a /** {inheritDoc} */ everywhere)
> >>>
> >>>    this has been discussed for vfs a few weeks ago, and my
> >>>    understanding was that this proposal was well received, so what do
> >>>    you think about doing the same for collections?
> >>>
> >>>  - unit tests: there are currently two unit tests for certain classes
> >>>    that are almost similar, e.g. TestListOrderedMap and
> >>>    TestListOrderedMap2. Does anybody know why this exists?
> >>>
> >>>    also I would like to go to annotation based unit tests like in the
> >>>    other components and rename the tests to the common style:
> >>>    ClassNameTest.
> >>>
> >>>  - consistency with commons rules. There are several things that are
> >>>    different to other components atm:
> >>>
> >>>    o authors contained in source files
> >>>    o no changes.xml to track changes
> >>>    o since and version tags are a bit different
> >>>    o package.html should be package-info.java
> >>>
> >>>    and I guess other things too that I have not spotted yet.
> >>>
> >>>
> >>> Are there any objections / suggestions to continue with the cleanup?
> >>
> >> A short overview clearly indicates that cc4 won't be a drop-in
> replacement
> >> for cc3. Therefore we have to change the groupId/artifactId now to
> >> org.apache.commons:commons-collections4 and the package should be
> renamed to
> >> org.apache.commons.collections4 (according the rules we used for lang3).
> >
> > Yes, there is already an issue for this: COLLECTIONS-382. The question
> > is do we change asap or shortly before a release (the way it was done
> > for commons-math afaik)?
>
> Doing the package rename just before release makes it possible to
> easily run Clirr.
> This can be used to help in creating the release notes - we'll need to
> document how to upgrade.
>
> AFAIK there's no benefit in changing the package rename earlier.
>
> >
> > Thomas
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Jörg Schaible-3
In reply to this post by jodastephen
Stephen Colebourne wrote:

> On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
> Sebb, someone needs to check to see if any collections in
> [collections] could implement the new interfaces added in Java 6 -
> NavigableSet, NavigableMap and so on.

I am definitely +1 here. Java 6 comes with more interesting  interfaces
(Deque) and implementations (ArrayDeque explicitly as replacement for Stack)
that make more of our stuff obsolete.

Anyone who still uses Java 5 has either made the best of 4-year-old cc3 or
switched to a different library. And in the light that Java 6 is probably
EOL before we release cc4, I see also no reason to stick with Java 5.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collections] Cleanup of trunk

Simone Tripodi-2
FWIW, +1 as well!!! :)

-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Wed, Jul 4, 2012 at 9:59 AM, Jörg Schaible
<[hidden email]> wrote:

> Stephen Colebourne wrote:
>
>> On Java 5/6, I'm in favour of Java 6 at this point. To justify it for
>> Sebb, someone needs to check to see if any collections in
>> [collections] could implement the new interfaces added in Java 6 -
>> NavigableSet, NavigableMap and so on.
>
> I am definitely +1 here. Java 6 comes with more interesting  interfaces
> (Deque) and implementations (ArrayDeque explicitly as replacement for Stack)
> that make more of our stuff obsolete.
>
> Anyone who still uses Java 5 has either made the best of 4-year-old cc3 or
> switched to a different library. And in the light that Java 6 is probably
> EOL before we release cc4, I see also no reason to stick with Java 5.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12