> -----Message d'origine----- > De : Felix Meschberger [mailto:[EMAIL PROTECTED] > Envoyé : vendredi 30 mai 2008 02:08 > À : [email protected] > Objet : RE: obr for felix bundles? > > 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.
Hi, I mention that as a possible extension (in fact it's more an extension of the obr-checker than the maven-bundle-plugin). In fact, if your OBR contains thousands of bundles, it could be a pain to find to understand possible deployment, so filters to create views could be useful. Of course, the generated OBR file contains all versions. The OBR that I generated contains only one as the pom file that I used contains only one version of each artifact (maven-restriction), but you can see now two versions of the configuration admin. Once this OBR is set, it should be possible to generate a consistent subset of this repository with only "latest" versions (if possible), or with a different filter. The naïve algorithm to generate this view (as it is not a real repository) could be : Select every bundles and check the consistency For each bundles with several versions try to remove the oldest version and check the consistency. Loop while you found an un-consistency or there is only one version of the bundle. But, it's just an idea. While the repository is not huge, this kind of mechanisms isn't worthwhile. Regards, Clement > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
