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
|