Clement Escoffier wrote:
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.
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
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
