Hello,
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 :
<configuration>
<pathRepo>file:/c:\repository.xml</pathRepo>
</configuration>
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 \
-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
