Richard S. Hall a écrit :
IMO, I prefer if no metadata are needed by default.
However, if we want to use this plugin as a way to generate OBR XML
files for released bundles or for Felix Commons bundles, don't we need
someway to specify that specific bundles in our build should be added
to specific repository XML files so that when we do new releases, we
can generate a new OBR file for our repositories of released bundles?
-> richard
That's definitively a needed feature. We need to be able to manage
several repository files. It could be useful when you work on different
projects...
Clement
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 \
-Dpackaging=jar
(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 file.
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
technology.
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 flexible.
Clement
--
Clement Escoffier
Grenoble University
LSR - Bat. C
220, Rue de la Chimie
BP 53
38041 GRENOBLE CEDEX 9
04.76.51.40.24
http://clement.plop-plop.net
