Hi, Sounds very good ! Let's go ;-)
One question, though: You said the remote OBR deployment would just leave a single version of the bundle in the repository.xml file. While this may be usefull in general, it would pose problems in some use cases. For example at our company we might provide an application consisting of multiple bundles. Over time we generate releases of the bundles but some customers will still be working with older versions of the bundles. To be able to support such customers, it would probably be required to have the older versions also available in the repository. So, could there be a switch to enable/disable this replacement functionality ? This might not be needed right now - having the OBR available in the first place is IMHO more important. Thanks and Regards Felix Am Donnerstag, den 29.05.2008, 13:34 -0400 schrieb Clement Escoffier: > I finally merge the goal that I created with the deploy AND the deploy-file > goals. In fact, I add to merge with both because the deploy-file goal does > not support multi-module projects (and it's normal, just I don't expect to > have this issue yesterday). > > Finally, the resulting plug-in is very similar to the actual one: > > The deploy goal can take an prefix attribute used to compute absolute URLs. > This allows deploying an OBR file with pointing on bundles located on > another server (the configured deployment repository and the > altDeploymentRepository attribute are generally used to deploy the OBR file, > but I add an url attribute to differentiate the two potential locations). If > the prefix is not specified, the process is executed normally and the url > attribute is ignored. > > The deploy-file goal checks if a project is attached to the build. If it is, > it uses this project. This allows simplifying the usage (no more need to > specify the pom file and the obr.xml file). The url attribute (giving > information to upload the repository file) supports the maven syntax too. > Absolute URLs are computed if the bundleURL (that can be an absolute url) > attribute and file attribute are not specified. In this case, the prefix > attribute is used to computes the URL. This attribute has a default value > pointing on repo1.maven.org/maven2. > > The repository file http://oscar-osgi.sf.net/obr-repo/releases.xml was > generated with the plugin. > > I commit the modifications in my sandbox : > https://svn.apache.org/repos/asf/felix/sandbox/clement/obr-utils/maven-bundl > e-plugin. > > WDYT? > > Clement > > > > -----Message d'origine----- > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Stuart > > McCulloch > > Envoyé : mercredi 28 mai 2008 09:10 > > À : [email protected] > > Objet : Re: obr for felix bundles? > > > > On 28/05/2008, Clement Escoffier <[EMAIL PROTECTED]> wrote: > > > > > > > -----Message d'origine----- > > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de > > Stuart > > > > McCulloch > > > > Envoyé : mercredi 28 mai 2008 08:15 > > > > > > > À : [email protected] > > > > Objet : Re: obr for felix bundles? > > > > > > > > > > > 2008/5/28 Felix Meschberger <[EMAIL PROTECTED]>: > > > > > > > > > Hi Richard, > > > > > > > > > > Am Dienstag, den 27.05.2008, 21:55 -0400 schrieb Richard S. Hall: > > > > > > Felix, > > > > > > > > > > > > I don't have a problem with this approach (or any approach for > > that > > > > > matter). > > > > > > > > > > > > My only request is that we devise a method that is easy for us > > to > > > > update > > > > > > any time we have a new release. > > > > > > > > > > That would be mine, too. Clement seems to be working on a maven > > > > plugin > > > > > to update repository.xml files, with entries of deployed > > artifacts > > > > with > > > > > absolute URIs such that the repository.xml need not be located at > > the > > > > > maven repository root. > > > > > > > > > > > > > note that this is already possible, just use the bundle:deploy-file > > > > goal... > > > > > > > > > > > > http://felix.apache.org/site/apache-felix-maven-bundle-plugin- > > > > bnd.html#ApacheFelixMavenBundlePlugin(BND)-bundle%3Adeployfile > > > > > > > > you can set the bundle URL separately from the repository location. > > > > > > > > > I agree, the goal that I'm developing is very close of the deploy- > > file > > > goal. > > > In fact it's a mix between the deploy and the deploy-file goals. > > Instead of > > > giving the absolute bundle URL (required in the deploy-file if you > > want > > > absolute URL), the goal computes the URL from a given prefix > > > (http://repo1.maven.org or can be specified by the user) and from the > > > artifact. You don't have to specify the pom file to use, as it uses > > the > > > project pom file. The repository file access is given by following > > the > > > "maven way" (name::default::url). > > > > > > In fact, it's just a specific kind of deploy-file goal. Right now, > > it's a > > > separate goal, but it is easily "mergeable" with the deploy-file > > goal. > > > > > > sounds like a useful addition, if it reduces configuration :) > > > > Clement > > > > > > > -- > > Cheers, Stuart > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
