Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <46558B80.6060508@ungoverned.org>
Date: Thu, 24 May 2007 08:56:32 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 2.0.0.0 (X11/20070419)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: maven-bundle-plugin
References: <81f0d9c0705162354tf8a785eq701c56d4e0a07c50@mail.gmail.com>
 <464D4E05.7030203@gmail.com> <4652DDC2.9020205@ungoverned.org>
 <81f0d9c0705220705i3b0862fcob26b627046cef3a9@mail.gmail.com>
 <46543F33.6060407@ungoverned.org> <4654D625.9090502@verizon.net>
 <46554A73.90906@gmail.com>
In-Reply-To: <46554A73.90906@gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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
>