Re: About binary compatibility
Hi gary. The post looks good, but I think you can add more details about how we detect bc in commons. about plugin and other tool chains we used in such perpose, and result analyzing. Emmanuel Bourg 于 2020年6月15日周一 上午6:04写道： > Le 14/06/2020 à 15:41, Gary Gregory a écrit : > > In order to avoid posting the same answer here and on GitHib over and > over, > > I tried to explain BC here: > > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > > > Feedback is most welcome. > > Excellent post, thank you Gary. > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: About binary compatibility
Le 14/06/2020 à 15:41, Gary Gregory a écrit : > In order to avoid posting the same answer here and on GitHib over and over, > I tried to explain BC here: > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > Feedback is most welcome. Excellent post, thank you Gary. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: About binary compatibility
On Sun, Jun 14, 2020 at 12:58 PM Rob Spoor wrote: > On 14/06/2020 15:41, Gary Gregory wrote: > > In order to avoid posting the same answer here and on GitHib over and > over, > > I tried to explain BC here: > > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > > > Feedback is most welcome. > > > > Gary > > You mention that adding fields is fine. That's true for binary > compatibility, but it could cause serialization incompatibility. For > instance, if you add a primitive field, trying to deserialize an > existing blob will set the value to the default value of 0. That could > cause code to break. It's why I made the "end" field of > CharSequenceReader Integer instead of int; see > > https://github.com/apache/commons-io/blob/master/src/main/java/org/apache/commons/io/input/CharSequenceReader.java > . > > Indeed, but Serialization is not part of binary compatibility. Gary > Rob > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: About binary compatibility
On 14/06/2020 15:41, Gary Gregory wrote: In order to avoid posting the same answer here and on GitHib over and over, I tried to explain BC here: https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ Feedback is most welcome. Gary You mention that adding fields is fine. That's true for binary compatibility, but it could cause serialization incompatibility. For instance, if you add a primitive field, trying to deserialize an existing blob will set the value to the default value of 0. That could cause code to break. It's why I made the "end" field of CharSequenceReader Integer instead of int; see https://github.com/apache/commons-io/blob/master/src/main/java/org/apache/commons/io/input/CharSequenceReader.java. Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] can we delete release 20030203.000550 in maven central?
Hello, I don't think the "largest version detect" is done on the Repo. Maven central offers all available versions in the metadata, and Maven locally resolves the highest version (when latest is used) Also since Maven central is supposed to be immutable a new coordinate sooner or later is the only way to avoid everybody having to manually block the offender. (And of course always specifying a specific version in POMs) Bernd -- http://bernd.eckenfels.net Von: Gary Gregory Gesendet: Sunday, June 14, 2020 4:58:27 PM An: Commons Developers List Betreff: Re: [io] can we delete release 20030203.000550 in maven central? I suppose you can ask Sonatype to offer a sort by release date feature on that kid of query result. Gary On Sun, Jun 14, 2020, 10:44 Melloware Inc wrote: > Gary, > > Maven Central Search does not. Se ethos URL: > https://search.maven.org/search?q=g:commons-io > > Commons-IO 20030203.000550 is shown as the latest version incorrectly. > > Mello > > On Sun, Jun 14, 2020 at 10:29 AM Gary Gregory > wrote: > > > I'm not sure what you are using, but Maven Central sorts by release date: > > https://search.maven.org/artifact/commons-io/commons-io > > > > Gary > > > > On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess wrote: > > > > > It is strange to have an older version have a larger major version > number > > > than a newer version. > > > Of course we might never witness a major version whose number be > > 1000+ > > > in our life, but... > > > That just feels strange. > > > > > > > > > Gary Gregory 于2020年6月14日周日 下午9:52写道： > > > > > > > On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess > > wrote: > > > > > > > > > Or if we should create commons-io2 and commons-BeanUtils2 like > what > > > > > we've done in lang3, as @John Patrick suggested? > > > > > > > > > > > > > Why? > > > > > > > > Gary > > > > > > > > > > > > > > > > > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > > > > > > > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess > > > > wrote: > > > > > > > > > > > > > every time my update tool chain thinks 20030203.000550 is a > > greater > > > > > > version > > > > > > > than 2.7 (actually it is, if see it in number). > > > > > > > So have we some way to delete it from maven central? (or rename > > > it?) > > > > > > > > > > > > > > > > > > > Yes, but we will never do that. That would break applications > > > depending > > > > > on > > > > > > that version. There are rare cases where releases may be > withdrawn. > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > The same problem happened in BeanUtils, version 20030211.134440 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > == > Melloware > melloware...@gmail.com > http://melloware.com > == >
Re: About binary compatibility
> Sure, go for it. > > I think we can use the default goal in Maven and use it from both TravisCI > and GitHib Actions Done in https://github.com/apache/commons-lang/pull/555 Similar ways can be used on any project who use commons-parent as parent. Gary Gregory 于2020年6月14日周日 下午10:14写道： > Sure, go for it. > > I think we can use the default goal in Maven and use it from both TravisCI > and GitHib Actions. > > Gary > > On Sun, Jun 14, 2020, 09:52 Xeno Amess wrote: > > > why not add a bc detect in travis-ci scripts? > > > > Gary Gregory 于2020年6月14日周日 下午9:42写道： > > > > > In order to avoid posting the same answer here and on GitHib over and > > over, > > > I tried to explain BC here: > > > > > > > > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > > > > > Feedback is most welcome. > > > > > > Gary > > > > > >
Re: [geometry] Transition from PolyhedronSet to ??? (RegionBSPTree3D ?)
Hi Matt,
thanks for the help. With your hint I could refactor a lot of the old
code. There are two questions left:
I used the PolyhedronSet to determine the intersections with a line.
First I got a Plane and then I had to find the intersection with the Plane.
My code makes use of both, the Plane and the intersection.
1. Can I use RegionBSPTree3D.linecast for the intersection part ?
2. Is there a way to find out the intersected Plane ?
Regards,
Sven
On 6/11/20 3:57 AM, Matt Juntunen wrote:
Hi Sven,
No problem! To answer your question in the subject line, yes, RegionBSPTree3D
is the replacement for the old PolyhedronsSet. They both represent 3D regions
using BSP trees. As for your code example, you're probably going to want to use
Planes.indexedConvexPolygons() [1] or Planes.indexedTriangles() [2] to create a
list of ConvexPolygon3D instances and then use those to create a
RegionBSPTree3D:
public static PolyhedronsSet createPrism(
List basePolygon,
int upperBound,
int lowerBound) {
List vertices = createVertices(polygon, upperBound, lowerBound);
int[][] facets = createFacets(polygon);
List polys = Planes.indexedConvexPolygons(vertices,
facets, PRECISION_CONTEXT);
return RegionBSPTree3D.from(polys);
}
There is actually a unit test here [3] that does exactly this.
Note that if the region is convex and you have a large number of polygons to
insert, the resulting tree will be highly unbalanced and will suffer from poor
performance. To help with this, you can insert partitions into the BSP tree
that do not affect the represented region but help keep the tree balanced and
shallow. Here's an example:
public static PolyhedronsSet createPrism(
List basePolygon,
int upperBound,
int lowerBound) {
List vertices = createVertices(polygon, upperBound, lowerBound);
int[][] facets = createFacets(polygon);
// compute the region bounds and centroid
Bounds3D bounds = Bounds3D.from(vertices);
Vector3D centroid = bounds.getCentroid();
// create an empty region
RegionBSPTree3D tree = RegionBSPTree3D.empty();
// insert structural partitions into the tree (RegionCutRule.INHERIT) at
the centroid; the
// resulting tree has internal partitions but the represented region is
still empty
tree.insert(Planes.fromPointAndNormal(center, Vector3D.Unit.PLUS_X,
PRECISION_CONTEXT).span(), RegionCutRule.INHERIT);
tree.insert(Planes.fromPointAndNormal(center, Vector3D.Unit.PLUS_Y,
PRECISION_CONTEXT).span(), RegionCutRule.INHERIT);
tree.insert(Planes.fromPointAndNormal(center, Vector3D.Unit.PLUS_Z,
PRECISION_CONTEXT).span(), RegionCutRule.INHERIT);
// create and insert the region boundaries
List polys = Planes.indexedConvexPolygons(vertices,
facets, PRECISION_CONTEXT);
tree.insert(polys);
return tree;
}
I've created a RegionBSPTree.subdivided() factory method in my current working
branch that abstracts this internal partitioning so this should be less verbose
in the near future.
Let me know if you have any other questions or run into issues. I'm working now
on a tutorial focusing on the BSP tree usage (GEOMETRY-95) so if you find
anything that's confusing or messed up, I can try to address it.
Regards,
Matt
[1]
https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/Planes.java#L295
[2]
https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/Planes.java#L234
[3]
https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/test/java/org/apache/commons/geometry/euclidean/threed/PlanesTest.java#L448
From: Sven Rathgeber
Sent: Wednesday, June 10, 2020 3:28 AM
To: Commons Developers List
Subject: [geometry] Transition from PolyhedronSet to ??? (RegionBSPTree3D ?)
Hi Matt,
first of all:
Thanks a lot for all your work (rewrite) on the library
Could you give me a hint how to make the transition from PolyhedronSet
to the new data structures ?
This is my current code:
public static PolyhedronsSet createPrism(
List< Position2D > basePolygon,
int upperBound,
int lowerBound )
{
List< Vector3D > vertices = createVertices( polygon, upperBound,
lowerBound );
int[][] facets = createFacets( polygon );
return new PolyhedronsSet( vertices, Arrays.asList( facets ),
PRECISION_CONTEXT );
}
Cheers. Sven
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] can we delete release 20030203.000550 in maven central?
I suppose you can ask Sonatype to offer a sort by release date feature on that kid of query result. Gary On Sun, Jun 14, 2020, 10:44 Melloware Inc wrote: > Gary, > > Maven Central Search does not. Se ethos URL: > https://search.maven.org/search?q=g:commons-io > > Commons-IO 20030203.000550 is shown as the latest version incorrectly. > > Mello > > On Sun, Jun 14, 2020 at 10:29 AM Gary Gregory > wrote: > > > I'm not sure what you are using, but Maven Central sorts by release date: > > https://search.maven.org/artifact/commons-io/commons-io > > > > Gary > > > > On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess wrote: > > > > > It is strange to have an older version have a larger major version > number > > > than a newer version. > > > Of course we might never witness a major version whose number be > > 1000+ > > > in our life, but... > > > That just feels strange. > > > > > > > > > Gary Gregory 于2020年6月14日周日 下午9:52写道： > > > > > > > On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess > > wrote: > > > > > > > > > Or if we should create commons-io2 and commons-BeanUtils2 like > what > > > > > we've done in lang3, as @John Patrick suggested? > > > > > > > > > > > > > Why? > > > > > > > > Gary > > > > > > > > > > > > > > > > > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > > > > > > > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess > > > > wrote: > > > > > > > > > > > > > every time my update tool chain thinks 20030203.000550 is a > > greater > > > > > > version > > > > > > > than 2.7 (actually it is, if see it in number). > > > > > > > So have we some way to delete it from maven central? (or rename > > > it?) > > > > > > > > > > > > > > > > > > > Yes, but we will never do that. That would break applications > > > depending > > > > > on > > > > > > that version. There are rare cases where releases may be > withdrawn. > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > > > > The same problem happened in BeanUtils, version 20030211.134440 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > == > Melloware > melloware...@gmail.com > http://melloware.com > == >
Re: [io] can we delete release 20030203.000550 in maven central?
Gary, Maven Central Search does not. Se ethos URL: https://search.maven.org/search?q=g:commons-io Commons-IO 20030203.000550 is shown as the latest version incorrectly. Mello On Sun, Jun 14, 2020 at 10:29 AM Gary Gregory wrote: > I'm not sure what you are using, but Maven Central sorts by release date: > https://search.maven.org/artifact/commons-io/commons-io > > Gary > > On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess wrote: > > > It is strange to have an older version have a larger major version number > > than a newer version. > > Of course we might never witness a major version whose number be > 1000+ > > in our life, but... > > That just feels strange. > > > > > > Gary Gregory 于2020年6月14日周日 下午9:52写道： > > > > > On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess > wrote: > > > > > > > Or if we should create commons-io2 and commons-BeanUtils2 like what > > > > we've done in lang3, as @John Patrick suggested? > > > > > > > > > > Why? > > > > > > Gary > > > > > > > > > > > > > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > > > > > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess > > > wrote: > > > > > > > > > > > every time my update tool chain thinks 20030203.000550 is a > greater > > > > > version > > > > > > than 2.7 (actually it is, if see it in number). > > > > > > So have we some way to delete it from maven central? (or rename > > it?) > > > > > > > > > > > > > > > > Yes, but we will never do that. That would break applications > > depending > > > > on > > > > > that version. There are rare cases where releases may be withdrawn. > > > > > > > > > > Gary > > > > > > > > > > > > > > > > The same problem happened in BeanUtils, version 20030211.134440 > > > > > > > > > > > > > > > > > > > > > -- == Melloware melloware...@gmail.com http://melloware.com ==
Re: [io] can we delete release 20030203.000550 in maven central?
I'm not sure what you are using, but Maven Central sorts by release date: https://search.maven.org/artifact/commons-io/commons-io Gary On Sun, Jun 14, 2020 at 9:56 AM Xeno Amess wrote: > It is strange to have an older version have a larger major version number > than a newer version. > Of course we might never witness a major version whose number be 1000+ > in our life, but... > That just feels strange. > > > Gary Gregory 于2020年6月14日周日 下午9:52写道： > > > On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess wrote: > > > > > Or if we should create commons-io2 and commons-BeanUtils2 like what > > > we've done in lang3, as @John Patrick suggested? > > > > > > > Why? > > > > Gary > > > > > > > > > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > > > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess > > wrote: > > > > > > > > > every time my update tool chain thinks 20030203.000550 is a greater > > > > version > > > > > than 2.7 (actually it is, if see it in number). > > > > > So have we some way to delete it from maven central? (or rename > it?) > > > > > > > > > > > > > Yes, but we will never do that. That would break applications > depending > > > on > > > > that version. There are rare cases where releases may be withdrawn. > > > > > > > > Gary > > > > > > > > > > > > > The same problem happened in BeanUtils, version 20030211.134440 > > > > > > > > > > > > > > >
Re: About binary compatibility
Sure, go for it. I think we can use the default goal in Maven and use it from both TravisCI and GitHib Actions. Gary On Sun, Jun 14, 2020, 09:52 Xeno Amess wrote: > why not add a bc detect in travis-ci scripts? > > Gary Gregory 于2020年6月14日周日 下午9:42写道： > > > In order to avoid posting the same answer here and on GitHib over and > over, > > I tried to explain BC here: > > > > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > > > Feedback is most welcome. > > > > Gary > > >
Re: [io] can we delete release 20030203.000550 in maven central?
It is strange to have an older version have a larger major version number than a newer version. Of course we might never witness a major version whose number be 1000+ in our life, but... That just feels strange. Gary Gregory 于2020年6月14日周日 下午9:52写道： > On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess wrote: > > > Or if we should create commons-io2 and commons-BeanUtils2 like what > > we've done in lang3, as @John Patrick suggested? > > > > Why? > > Gary > > > > > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess > wrote: > > > > > > > every time my update tool chain thinks 20030203.000550 is a greater > > > version > > > > than 2.7 (actually it is, if see it in number). > > > > So have we some way to delete it from maven central? (or rename it?) > > > > > > > > > > Yes, but we will never do that. That would break applications depending > > on > > > that version. There are rare cases where releases may be withdrawn. > > > > > > Gary > > > > > > > > > > The same problem happened in BeanUtils, version 20030211.134440 > > > > > > > > > >
Re: About binary compatibility
why not add a bc detect in travis-ci scripts? Gary Gregory 于2020年6月14日周日 下午9:42写道： > In order to avoid posting the same answer here and on GitHib over and over, > I tried to explain BC here: > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ > > Feedback is most welcome. > > Gary >
Re: [io] can we delete release 20030203.000550 in maven central?
On Sun, Jun 14, 2020 at 9:51 AM Xeno Amess wrote: > Or if we should create commons-io2 and commons-BeanUtils2 like what > we've done in lang3, as @John Patrick suggested? > Why? Gary > > Gary Gregory 于2020年6月14日周日 下午9:39写道： > > > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote: > > > > > every time my update tool chain thinks 20030203.000550 is a greater > > version > > > than 2.7 (actually it is, if see it in number). > > > So have we some way to delete it from maven central? (or rename it?) > > > > > > > Yes, but we will never do that. That would break applications depending > on > > that version. There are rare cases where releases may be withdrawn. > > > > Gary > > > > > > > The same problem happened in BeanUtils, version 20030211.134440 > > > > > >
Re: [io] can we delete release 20030203.000550 in maven central?
Or if we should create commons-io2 and commons-BeanUtils2 like what we've done in lang3, as @John Patrick suggested? Gary Gregory 于2020年6月14日周日 下午9:39写道： > On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote: > > > every time my update tool chain thinks 20030203.000550 is a greater > version > > than 2.7 (actually it is, if see it in number). > > So have we some way to delete it from maven central? (or rename it?) > > > > Yes, but we will never do that. That would break applications depending on > that version. There are rare cases where releases may be withdrawn. > > Gary > > > > The same problem happened in BeanUtils, version 20030211.134440 > > >
About binary compatibility
In order to avoid posting the same answer here and on GitHib over and over, I tried to explain BC here: https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/ Feedback is most welcome. Gary
Re: [io] can we delete release 20030203.000550 in maven central?
On Sun, Jun 14, 2020 at 6:40 AM Xeno Amess wrote: > every time my update tool chain thinks 20030203.000550 is a greater version > than 2.7 (actually it is, if see it in number). > So have we some way to delete it from maven central? (or rename it?) > Yes, but we will never do that. That would break applications depending on that version. There are rare cases where releases may be withdrawn. Gary > The same problem happened in BeanUtils, version 20030211.134440 >
Re: [io] can we delete release 20030203.000550 in maven central?
"update toolchain" here means idea's package plugin, which seems have no
way to set up rules like rules in versions-maven-plugin.
[image: image.png]
Of course we can try to only use versions-maven-plugin.
But a setting like that just hides problem, it does not solve the problem.
The real problem is that "An older version have a larger version number
than a newer version"[1].
And nearly all rules about versioning forbids that [1].
Rob Spoor 于2020年6月14日周日 下午7:03写道：
> On 14/06/2020 12:40, Xeno Amess wrote:
> > every time my update tool chain thinks 20030203.000550 is a greater
> version
> > than 2.7 (actually it is, if see it in number).
> > So have we some way to delete it from maven central? (or rename it?)
> > The same problem happened in BeanUtils, version 20030211.134440
>
> That's why you can use a set of rules with the Maven versions plugin:
> https://www.mojohaus.org/versions-maven-plugin/version-rules.html
>
> For instance, here's part of the rules I use:
>
> artifactId="commons-collections">
>
>
> 200[34]\d{4}.*
>
>
>
> In a similar way, you can exclude alpha, beta, release-candidate and
> milestone versions. You just need to find the proper regex.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [io] can we delete release 20030203.000550 in maven central?
On 14/06/2020 12:40, Xeno Amess wrote:
every time my update tool chain thinks 20030203.000550 is a greater version
than 2.7 (actually it is, if see it in number).
So have we some way to delete it from maven central? (or rename it?)
The same problem happened in BeanUtils, version 20030211.134440
That's why you can use a set of rules with the Maven versions plugin:
https://www.mojohaus.org/versions-maven-plugin/version-rules.html
For instance, here's part of the rules I use:
artifactId="commons-collections">
200[34]\d{4}.*
In a similar way, you can exclude alpha, beta, release-candidate and
milestone versions. You just need to find the proper regex.
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [io] can we delete release 20030203.000550 in maven central?
I keep thinking that too, and ended up just using a custom versions rule to ignore it. Other idea maybe change to GAV to; 1) org.apache.commons:commons-io 2) org.apache.commons:commons-io2 So starting to match the commons-lang3 approach. I find commons-lang3 is a really good pattern and is much easier, as it supports older and newer versions on the classpath at the same time without conflict. Allowed phased upgrades. And an upgrade to lang3 from lang is just a find/replace "org.apache.commons.lang." to "org.apache.commons.lang3." and ticket off the build process to check it worked. Hopefully they will keep the same style for lang4 and it will just be another find/replace upgrade when i choose. On Sun, 14 Jun 2020 at 11:40, Xeno Amess wrote: > > every time my update tool chain thinks 20030203.000550 is a greater version > than 2.7 (actually it is, if see it in number). > So have we some way to delete it from maven central? (or rename it?) > The same problem happened in BeanUtils, version 20030211.134440 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[io] can we delete release 20030203.000550 in maven central?
every time my update tool chain thinks 20030203.000550 is a greater version than 2.7 (actually it is, if see it in number). So have we some way to delete it from maven central? (or rename it?) The same problem happened in BeanUtils, version 20030211.134440
