felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clement Escoffier <clement.escoff...@gmail.com>
Subject Re: maven-bundle-plugin
Date Thu, 24 May 2007 08:18:59 GMT

Tim has made a good and clear comparison. I add some comment on what we 
can obtain if we merge all ideas together.
> I quickly took a look at what Clement/Maxime has done.  This is how I 
> would compare them.  Clement, please correct me if misrepresent anything.
> Comparison
> ---------------
> My patch uses Modello to read/write the OBR file.  Modello is a Maven 
> plugin which creates the code to marshall/unmarshall the OBR XML.  
> This reduces the amount of source code but Modello has an issue where 
> it doesn't handle PCDATA in elements that have attributes.  As a 
> result, the <require> elements may no be backward-compatible.  
> Clement's plugin uses xerces and hand-generated code that uses Xerces 
> but it appears to be completely backward-compatible.
You're right. Is it any Modello-like plugin which can be compatible ? 
Using Xerces is not the best way, the parsing code is not really easy to 
understand (and to maintain).
> For the install goal, my patch doesn't require any changes to the 
> pom.xml file (unless you don't use the defaults).  Clement's plugin 
> requires configuration elements to be added to the pom.xml file.
Maxime's plugin needs metadata because it is an independent plugin. If 
we merge all in one Maven plugin, we reduce these metadata. Moreover, I 
think the configuration part can be optional (Maxime is it already done 
?). By example, using a repository.xml file at the root of the Maven 
local repository by default to avoid :

IMO, I prefer if no metadata are needed by default.
> For the install-file goal, my patch gets more info from the bundle's 
> manifest so has less command line arguments.  Clement's plugin is more 
> verbose to use.
About the install-file goal, some of the argument could be optional as 
the OBR repository file and hae default value. The main difference 
between Tim's plugin and Maxime's plugin on the install-file goal 
concerns the bundle identification. Tim (correct me if I'm wrong) uses 
the absolute path of the bundle (this bundle must be inside the maven 
repository before). Maxime identifies the bundle by indicating the 
artefactId, the groupId and the version. Maxime's way seems to be more 
'Maven compliant', and allows to install a file in the maven repository 
and in the OBR in one command using the same arguments :

    mvn install:install-file homega.tools:obrPlugin:install-file \
    -DartefactId=multicast.discovery \
    -DgroupId=homega.utils \
    -Dversion=1.0.0 \

(I suppose the OBRfile and others attributes can be optional).

> My patch uses the information from the manifest file which is 
> generated by bnd.  Clement's plugin uses bindex which might introduce 
> inconsistencies since the bundle information is coming from two 
> different places.  I have not looked at bindex so this may not be an 
> issue.
Bindex uses the Bundle Manifest to compute OBR metadata. So normally, 
the metadata should be the same for the two plugin. The pom is used if 
the symbolic name is not set in the manifest (I am not sure but I guess 
that bindex uses the presentation name as the symbolic name if the 
symbolic name is not set). Except the last case, the pom file is only 
used to add metadata (if not present in the Manifest) as the description 
or the documentation url ...
However, if we use BND, we can suppose that all useful information are 
in the manifest, and so, we do no more need to extract info from the pom 
> My patch doesn't provide any way to augment/override the bundle 
> information.  Clement's plugin can augment/override info by adding it 
> to the pom.xml file or an external file.
> Recommendations
> -----------------------
> If Modello hasn't been fixed and the my generated OBR isn't 
> backward-compatible, use Clement's solution.  If Modello has since 
> been fixed or my generated OBR is backward-compatible, then use my 
> solution since there is less code to maintain.
I agree, perhaps another Maven plugin Modello-like can solve the 
problem. Another way is to use Castor or any other XML-Java Mapping 
> Take advantage of using default arguments like my patch but add the 
> extra flexibility of Clement's plugin.
I agree too. By default using the plugin should no ask extra metadata. 
These extra-metadata need only be used for non-common projects (the 
repository file is not at the root of the Maven repo or already exists ...)
> Determine the best way to get the bundle info.  Either using bindex or 
> from the manifest file.  It may be possible to get this directly from 
> bnd now.  I haven't looked at the latest version.
That's a good question. If BND insert all useful information in the 
bundle manifest we can only use the Bundle Manifest (direct analyzing or 
by using bindex). Does BND add the pom description and documentation url 
(if not set in the <instructions> element).
> Definitely use Clement's method of augmenting/overriding the bundle info.

We definitely can converge in a pretty good OBR plugin easy to use and 


Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53

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