maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Lewis <sle...@simulalabs.com>
Subject Re: maven2 repository of eclipse jars
Date Tue, 12 Dec 2006 00:00:05 GMT
Hi Fabrizio,

Fabrizio Giustina wrote:
> On 12/11/06, Scott Lewis <slewis@simulalabs.com> wrote:
>> There is a (recently proposed/adopted) version numbering spec that
>> describes using the qualifier segment to distinguish between release,
>> integration, and nightly builds.  See here for the details:
>
> I can see that the docs outline rules in choosing a qualifier name for
> specific branches, but I still can't see anything useful that could be
> used to identify a final release (maybe I don't look in the correct
> place?).

I suppose I'm a little confused by what you mean by 'final release'.  
Each plugin/bundle within Eclipse can/potentially does have  a distinct 
version identifier, and so different configurations of bundles/plugins 
(including Eclipse the IDE) have a variety of different versions of 
various bundles/plugins (and different version dependencies...as 
described by "How to specify plug-in requirements" section on this page).

The Eclipse platform and IDE has a convention of naming the Eclipse IDE 
yearly 'release' according to 2005: 3.1.0, 2006: 3.2.0, 2007: 3.2.0, 
etc.  All the dependencies on the versions of the various plugins that 
go into the Eclipse platform are expressed via the manifest.mf as 
described by the version number page. 

There is the additional concept of a 'feature' in Eclipse (and 
Eclipse-based apps) that has it's own version number (a feature is an 
arbitrary set of plugins...like, for example, Eclipse IDE itself).  For 
many applications (like Eclipse IDE itself), the 'final release' version 
number is frequently associated with the number specified for a 
top-level feature rather than the individual plugins that make up that 
feature.

>
> To be clear, this is the list of differences between eclipse and maven
> versioning that I tried to solve (or still needs to be solved):
>
> - in maven final releases don't have a build number attached, while
> snapshots do. For eclipse everything has a build number attached and
> there is no way to distinguish between snapshot-equivalent builds and
> releases (this needs to be done manually by passing the
> -DstripQualifier=true flag to make-artifacts)

At the plugin level, that's true.  But it's not necessarily true at the 
feature level (i.e. features can/do have distinction between 
snapshot-equivalent builds and releases).

>
> - the eclipse qualifier (=the maven build number, or "the 4th token")
> can be a string, in maven MUST be numeric (the make-artifacts support
> a forced qualifier/build number for this)
>
> - the 4th token MUST be separated with "-" in maven, while in osgi
> MUST be "." (this is handled by the make-artifacts goal actually). A
> version like 1.2.3-4 in maven is parsed as [major 1, minor 2, patch 3,
> build 4], a version like 1.2.3.4 is parsed as [major 0, minor 0, patch
> 0, build 0, qualifier "1.2.3.4"] (funny, I discovered this only
> recently by looking at DefaultVersion unit tests... I can't say I like
> it but that's how maven works and it's expected to work, you will
> never notice it till you will experiment 4 digits version numbers, and
> osgi bundles HAVE 4 digits version numbers).
>
> - not a problem, but just a note: in eclipse each artifact in a single
> build can have a different qualifiers: this makes linking projects
> from the same release a real mess (the make-artifacts supports
> replacing qualifier with a forced build number for this too)
>
> - osgi bundles can specify a dependency without a version number,
> maven can't (this is handled by make-artifacts by adding a "any
> version >0" version tag)
>
> - not strictly a problem, just another note: version ranges in osgi
> bundles are hard requirements, while maven usually uses soft
> requirements. This makes the correct versioning number more and more
> required since you can easily run into "over-costrained version"
> problems: for example you will run into it when org.apache.xerces is
> deployed with a build number, and another osgi bundles depends on it
> using a strict requirement with a 3 digit only version (which in OSGI
> also matches a build with a qualifier, in maven doesn't).
>
> - last but not least: package-level dependencies can't be handled by
> maven as is. IMHO this could not be a big problem at the moment: you
> could be forced to manually add transitive dependencies  but at the
> end it doesn't really hurt (BTW, in eclipse builds package-level
> dependencies are very rare)
>
> this is what I found out by months of trial and errors, I will be
> happy to complete this list with any other issue found by users.

Good idea.  This is a very useful list.

Thanks,

Scott



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


Mime
View raw message