Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
gs-collections vs eclipse-collections
1 view
Skip to first unread message
Vincent Prat
Jan 6, 2021, 8:00:04 PM1/6/21
to
Dear all,
The latest version of NatTable (2.0.0) depends on Eclipse Collections
(https://www.eclipse.org/collections/).
Originally, it was called GS Collections, and was renamed when it
migrated to the Eclipse Foundation.
GS Collections is present in Debian (as gs-collections:
https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections.
Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package?
For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.
Best wishes for the new year
Vincent
The latest version of NatTable (2.0.0) depends on Eclipse Collections
(https://www.eclipse.org/collections/).
Originally, it was called GS Collections, and was renamed when it
migrated to the Eclipse Foundation.
GS Collections is present in Debian (as gs-collections:
https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections.
Should we package Eclipse Collections as a separate project (in which
case I will submit an ITP bug), or update and rename the existing package?
For your information, the package gs-collections has no reverse
dependency and has not been updated since September 2017.
Best wishes for the new year
Vincent
tony mancill
Jan 7, 2021, 10:20:02 AM1/7/21
to
Hi Vincent,
I see either choice as acceptable, but my suggestion is to update
the existing package (and rename it only if you think it is necessary).
It is the evolution of (and thus an update to) gs-collections. This
approach means you don't have to go through NEW, we don't have to
introduce a new package to archive, and developers who know the software
by gs-collections will still find it. Even if there aren't r-deps in
Debian, perhaps a downstream is using gs-collections and will benefit
from the update without a rename.
If you decide to create a new source package for eclipse-collections,
please also take the time to RM gs-collections. We don't need to keep
the old package around if we have a compatible replacement. (I'm
assuming that eclipse-collections is a drop-in replacement, or nearly so
- maybe just a Java package name change?)
> Best wishes for the new year
Same to you!
Cheers,
tony
the existing package (and rename it only if you think it is necessary).
It is the evolution of (and thus an update to) gs-collections. This
approach means you don't have to go through NEW, we don't have to
introduce a new package to archive, and developers who know the software
by gs-collections will still find it. Even if there aren't r-deps in
Debian, perhaps a downstream is using gs-collections and will benefit
from the update without a rename.
If you decide to create a new source package for eclipse-collections,
please also take the time to RM gs-collections. We don't need to keep
the old package around if we have a compatible replacement. (I'm
assuming that eclipse-collections is a drop-in replacement, or nearly so
- maybe just a Java package name change?)
> Best wishes for the new year
Cheers,
tony
Vincent Prat
Jan 7, 2021, 1:20:03 PM1/7/21
to
Hi Tony,
>> Should we package Eclipse Collections as a separate project (in which
>> case I will submit an ITP bug), or update and rename the existing package?
>> For your information, the package gs-collections has no reverse
>> dependency and has not been updated since September 2017.
> I see either choice as acceptable, but my suggestion is to update
> the existing package (and rename it only if you think it is necessary).
> It is the evolution of (and thus an update to) gs-collections. This
> approach means you don't have to go through NEW, we don't have to
> introduce a new package to archive, and developers who know the software
> by gs-collections will still find it. Even if there aren't r-deps in
> Debian, perhaps a downstream is using gs-collections and will benefit
> from the update without a rename.
What about developers who do not know the software and need Eclipse
Collections?
Do they have to guess that the Java package is provided by the Debian
package gs-collections?
Eclipse Collections is indeed the evolution of GS Collections, but the
latter still exists as such, even though only bug fixes are made.
By the way, the version present in Debian is out-of-date.
> If you decide to create a new source package for eclipse-collections,
> please also take the time to RM gs-collections. We don't need to keep
> the old package around if we have a compatible replacement. (I'm
> assuming that eclipse-collections is a drop-in replacement, or nearly so
> - maybe just a Java package name change?)
Yes, the Java package name is different. So, even if the API is
compatible, this would require downstream to change imports, classpaths,
etc.
In any case, since Emmanuel Bourg was the one who packaged
gs-collections in the first place, it would be nice to have his opinion
on the question.
Cheers,
Vincent
>> Should we package Eclipse Collections as a separate project (in which
>> case I will submit an ITP bug), or update and rename the existing package?
>> For your information, the package gs-collections has no reverse
>> dependency and has not been updated since September 2017.
> I see either choice as acceptable, but my suggestion is to update
> the existing package (and rename it only if you think it is necessary).
> It is the evolution of (and thus an update to) gs-collections. This
> approach means you don't have to go through NEW, we don't have to
> introduce a new package to archive, and developers who know the software
> by gs-collections will still find it. Even if there aren't r-deps in
> Debian, perhaps a downstream is using gs-collections and will benefit
> from the update without a rename.
Collections?
Do they have to guess that the Java package is provided by the Debian
package gs-collections?
Eclipse Collections is indeed the evolution of GS Collections, but the
latter still exists as such, even though only bug fixes are made.
By the way, the version present in Debian is out-of-date.
> If you decide to create a new source package for eclipse-collections,
> please also take the time to RM gs-collections. We don't need to keep
> the old package around if we have a compatible replacement. (I'm
> assuming that eclipse-collections is a drop-in replacement, or nearly so
> - maybe just a Java package name change?)
compatible, this would require downstream to change imports, classpaths,
etc.
In any case, since Emmanuel Bourg was the one who packaged
gs-collections in the first place, it would be nice to have his opinion
on the question.
Cheers,
Vincent
tony mancill
Jan 7, 2021, 3:10:03 PM1/7/21
to
On Thu, Jan 07, 2021 at 07:10:25PM +0100, Vincent Prat wrote:
> Hi Tony,
>
> >> Should we package Eclipse Collections as a separate project (in which
> >> case I will submit an ITP bug), or update and rename the existing package?
> >> For your information, the package gs-collections has no reverse
> >> dependency and has not been updated since September 2017.
> > I see either choice as acceptable, but my suggestion is to update
> > the existing package (and rename it only if you think it is necessary).
> > It is the evolution of (and thus an update to) gs-collections. This
> > approach means you don't have to go through NEW, we don't have to
> > introduce a new package to archive, and developers who know the software
> > by gs-collections will still find it. Even if there aren't r-deps in
> > Debian, perhaps a downstream is using gs-collections and will benefit
> > from the update without a rename.
>
> What about developers who do not know the software and need Eclipse
> Collections?
> Do they have to guess that the Java package is provided by the Debian
> package gs-collections?
Yes, this happens all of the time already.
> Hi Tony,
>
> >> Should we package Eclipse Collections as a separate project (in which
> >> case I will submit an ITP bug), or update and rename the existing package?
> >> For your information, the package gs-collections has no reverse
> >> dependency and has not been updated since September 2017.
> > I see either choice as acceptable, but my suggestion is to update
> > the existing package (and rename it only if you think it is necessary).
> > It is the evolution of (and thus an update to) gs-collections. This
> > approach means you don't have to go through NEW, we don't have to
> > introduce a new package to archive, and developers who know the software
> > by gs-collections will still find it. Even if there aren't r-deps in
> > Debian, perhaps a downstream is using gs-collections and will benefit
> > from the update without a rename.
>
> What about developers who do not know the software and need Eclipse
> Collections?
> Do they have to guess that the Java package is provided by the Debian
> package gs-collections?
> Eclipse Collections is indeed the evolution of GS Collections, but the
> latter still exists as such, even though only bug fixes are made.
> By the way, the version present in Debian is out-of-date.
>
> > If you decide to create a new source package for eclipse-collections,
> > please also take the time to RM gs-collections. We don't need to keep
> > the old package around if we have a compatible replacement. (I'm
> > assuming that eclipse-collections is a drop-in replacement, or nearly so
> > - maybe just a Java package name change?)
>
> Yes, the Java package name is different. So, even if the API is
> compatible, this would require downstream to change imports, classpaths,
> etc.
Debian?!?
> In any case, since Emmanuel Bourg was the one who packaged
> gs-collections in the first place, it would be nice to have his
> opinion on the question.
tony
Emmanuel Bourg
Jan 16, 2021, 6:10:03 AM1/16/21
to
Hi Vincent,
libgs-collections-java is still used to build libreactor-core-java.
eclipse-collections is incompatible with gs-collections because the
package name was changed to org.eclipse.collections.
For these reasons I suggest to keep the gs-collections package for now,
and create a new eclipse-collections source package building
libeclipse-collections-java. The gs-collections repository on Salsa can
be cloned and used as a starting point for the new package.
Emmanuel Bourg
libgs-collections-java is still used to build libreactor-core-java.
eclipse-collections is incompatible with gs-collections because the
package name was changed to org.eclipse.collections.
For these reasons I suggest to keep the gs-collections package for now,
and create a new eclipse-collections source package building
libeclipse-collections-java. The gs-collections repository on Salsa can
be cloned and used as a starting point for the new package.
Emmanuel Bourg
0 new messages