Hi Fabrizio,
Fabrizio Giustina wrote:
On 12/11/06, Scott Lewis <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
