felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: [Maven Plugin] Additional fixes...
Date Tue, 30 May 2006 15:16:11 GMT
Niclas Hedhman <hedhman@gmail.com> wrote on 05/30/2006 03:00:53 AM:
> There are a few restrictions imposed by Maven.
>  * ArtifactID WILL become part of the filename together with Versionand 
>    <finalname> is NOT respected for repository uploads. This would 
require the
>    FQDN style to use the FQDN in both group and artifact, generally
>    discouraged by the Maven peeps, but totally doable.

Maven question:  Why is the group id influenced by the name chosen for the 
artifact?  That is, why would FQDN need to be used for both?

>  * Versions are appended to filename (as well as being part of the 
>    structure) with a DASH. Underscore is not possible.

Dash is technically feasible for us to allow in Eclipse.  It would be 
interesting to see if Maven could allow underscore.

>  * Versions during development contains -SNAPSHOT, which Equinox does 
not like
>    anywhere, and OSGi doesn't like in its own versioning (handled by 

This looks like an incompatibility between Maven and OSGi.  As I 
understand your point, the maven-osgi plugin does some sort of 
transformation to make the version number acceptable at runtime.  The OSGi 
spec does not allow '-' separators in the version number and Eclipse tools 
the OSGi spec.  So this one may be harder to work around.

> So, from my PoV it seems that Eclipse vs Maven is fairly incompatible on 
> point, and I can only see three ways out;
>  * Equinox makes concessions to support Maven's style.

As pointed out above, we can certainly look at supporting '-' in the JAR 
file name.  The only place we care is in some of the boot code that needs 
to search for bundles.  We try to avoid doing this at all costs and are 
generally successful but given that our version numbers change very 
frequently (every build) some level of searching at boot time seems 

>  * Maven makes concessions to support Equinox's style.

I would rephrase as enhancing Maven to better support OSGi.  Certainly if 
Maven allowed _ as the name/version separator in the JAR name that would 
be ideal but the other issues seem more fundamental/important.

>  * We make a program that takes the published Maven artifacts, rename 
>    republish to an Eclipse Update site, and possibly an OBR as well.

This is interesting.  Are you saying that when an artifact is taken out of 
the repo it should be renamed for use at runtime?  This feels like a 
potential disconnect.  We've been working really hard to make seamless the 
path between development time and runtime.  That is, you run the bundles 
you develop against without doing a deployment step or some such.

To me the essential point is that a bundle be standalone so that it can be 
used, unmodified, in many contexts. This means that it be self-describing 
and that the bundle JAR be uniquely named.   As I understand the current 
situation, Maven avoids collisons by having a groupID/artifactID structure 
in the repo.  For example, you could take the 
org.eclipse.core.runtime_3.2.0.jar bundle and make "org.eclipse" the group 
id and "core.runtime" the artifact id (with "3.2.0" the version and "jar" 
the type).  Is that correct?

This works well as long as you have a repo (local or remote) structure 
that includes groupids.  When shipping a product (either on the media or 
on the provisioning server) you may not have this level of control and 
maintaining this structure complicates management agents.  The crux of the 
problem is that the bundle jar itself is not standalone since its name is 
not unique.  The JAR is only unique in a context (i.e., group). 

Side comment: publishing as an update site is interesting but we are 
certainly not pushing for that (at this time).  I would rather see update 
get more flexible to it can better understand other repo formats than try 
to get everyone to adopt our structure.  Note also that to date, the vast 
majority of our installations come as zips or product installs and do not 
involve update sites (at least not in the initial provisioning).

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message