Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » B3 » four part versions?
four part versions? [message #1174196] Thu, 07 November 2013 01:20 Go to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Recently I started using the b3 aggregator to create mixed p2 / maven repos.

Purpose: make OSGi artifacts with p2 dependencies consumable for a non-OSGi application build (Maven). This looks very promising, but ...

First surprise: the use of this hybrid repo easily pulls in some Orbit dependencies, like p2.osgi.bundle:com.google.guava, which then duplicate any com.google:guava artefacts which might be pulled in from some other maven module. If version numbers don't match by chance, this can cause any trouble you like, right?

First solution: Use a maven mapping in .b3aggr to map some known bundles back to their original names. In the same course I also mapped org.eclipse.foo.bar to org.eclipse.foo:org.eclipse.foo.bar. (regex are really at their limits when you have to squeeze several mapping rules into one regex). This worked for a while, until ...

Second surprise: At some unexpected point in time someone uploaded a similar artefact like one of my dependencies to Maven central.

Now my application indirectly tries to resolve, e.g.:
org.eclipse.emf:org.eclipse.emf.ecore:2.9.1.v20130827-0309
(this one exists in my b3-transformed repo),
and Maven central provides:
org.eclipse.emf:org.eclipse.emf.ecore:2.9.1-v20130827-0309

Result: EMF 2.9.1 cannot be resolved by Maven. Build Failure.

What? Two identical but different versions result in none resolvable?

So I started to read a bit about Maven version numbers:

<major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])

So how do both versions relate?
To answer this, we have to split both versions into their parts and see:
the OSGi-derived version is not parseable as a Maven version, right?
It seems that Maven not only falls back to plain string comparison of the
entire version, it also chokes so badly that it prefers to tell you that
EMF 2.9.1.v20130827-0309 cannot be found (which of course is wrong).


From naive thinking maybe b3 aggregator could easily avoid this problem
by not only mapping GAV but also version numbers, like replacing any
extraneous dots (that's anything more than two dots) with a hyphen, to turn
the OSGi version into a legal Maven version. Given that tycho is fine with
consuming 4-part versions, I believe b3 would indeed by the right place
to transform the 4-part versions into proper Maven versions.

Has this been considered? Would that make sense?
Should I file a bug?

The current state is really quite painful: a working repo can be killed by anyone independently uploading the same artefact with a legal Maven version to a public repo.

thanks
Stephan





Re: four part versions? [message #1176272 is a reply to message #1174196] Fri, 08 November 2013 08:23 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3240
Registered: July 2009
Senior Member
HI Stephan,

Yes, please file a bug on this. It makes a lot of sense to improve this.

- thomas

On 2013-11-07 02:20, Stephan Herrmann wrote:
> Recently I started using the b3 aggregator to create mixed p2 / maven repos.
>
> Purpose: make OSGi artifacts with p2 dependencies consumable for a non-OSGi application build (Maven). This looks very
> promising, but ...
>
> First surprise: the use of this hybrid repo easily pulls in some Orbit dependencies, like
> p2.osgi.bundle:com.google.guava, which then duplicate any com.google:guava artefacts which might be pulled in from some
> other maven module. If version numbers don't match by chance, this can cause any trouble you like, right?
>
> First solution: Use a maven mapping in .b3aggr to map some known bundles back to their original names. In the same
> course I also mapped org.eclipse.foo.bar to org.eclipse.foo:org.eclipse.foo.bar. (regex are really at their limits when
> you have to squeeze several mapping rules into one regex). This worked for a while, until ...
>
> Second surprise: At some unexpected point in time someone uploaded a similar artefact like one of my dependencies to
> Maven central.
>
> Now my application indirectly tries to resolve, e.g.:
> org.eclipse.emf:org.eclipse.emf.ecore:2.9.1.v20130827-0309
> (this one exists in my b3-transformed repo),
> and Maven central provides:
> org.eclipse.emf:org.eclipse.emf.ecore:2.9.1-v20130827-0309
>
> Result: EMF 2.9.1 cannot be resolved by Maven. Build Failure.
>
> What? Two identical but different versions result in none resolvable?
>
> So I started to read a bit about Maven version numbers:
>
> <major>.<minor>.<revision>([ -<qualififer> ] | [ -<build> ])
>
> So how do both versions relate?
> To answer this, we have to split both versions into their parts and see:
> the OSGi-derived version is not parseable as a Maven version, right?
> It seems that Maven not only falls back to plain string comparison of the
> entire version, it also chokes so badly that it prefers to tell you that
> EMF 2.9.1.v20130827-0309 cannot be found (which of course is wrong).
>
>
> From naive thinking maybe b3 aggregator could easily avoid this problem
> by not only mapping GAV but also version numbers, like replacing any extraneous dots (that's anything more than two
> dots) with a hyphen, to turn
> the OSGi version into a legal Maven version. Given that tycho is fine with
> consuming 4-part versions, I believe b3 would indeed by the right place
> to transform the 4-part versions into proper Maven versions.
>
> Has this been considered? Would that make sense?
> Should I file a bug?
>
> The current state is really quite painful: a working repo can be killed by anyone independently uploading the same
> artefact with a legal Maven version to a public repo.
>
> thanks
> Stephan
>
>
>
>
>
>
Re: four part versions? [message #1178373 is a reply to message #1176272] Sat, 09 November 2013 16:03 Go to previous message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Thomas Hallgren wrote on Fri, 08 November 2013 09:23
HI Stephan,

Yes, please file a bug on this. It makes a lot of sense to improve this.


I added some comments to https://bugs.eclipse.org/314992

cheers,
Stephan
Previous Topic:b3 editor in Kepler
Next Topic:ppc64le not valid in latest b3 aggregator download
Goto Forum:
  


Current Time: Tue Mar 19 08:15:36 GMT 2024

Powered by FUDForum. Page generated in 0.03165 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top