> -----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 its 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. Clement > > > > Regards > > Felix > > > > > > > > -> richard > > > > > > Felix Meschberger wrote: > > > > Hi, > > > > > > > > I have been thinking about this issue and been discussing it with > > > > Carsten. And we came up with a very simple solution: The main > point is, > > > > that the repository.xml file and the artifacts referred to need > not be > > > > in the same location, right ? > > > > > > > > Starting from this, the solution would be that we might provide > the > > > > repository.xml file from the Felix site and have the bundles > where they > > > > already are: in the maven repository. > > > > > > > > So upon the release of one of the Felix bundles, we just add a > record > > > > for the bundle into the repository.xml pointing to the maven > > repository. > > > > That's it, I would say. > > > > > > > > So far so good. But there will be other projects -- just talking > of > > > > Apache for the moment, but OPS4J also comes to mind -- which have > > > > bundles to distribute. Here comes the <referral> element of the > > > > repository.xml file (section 5.5.4 in OSGi RFC 112): We create a > > central > > > > repository.xml file, into which referrals to other projects may > be > > > > entered. Each project thus maintains its own repository.xml. > > > > > > > > For example: > > > > > > > > global-repository.xml > > > > ---> referral to Apache Felix repository.xml > > > > ---> referral to Apache Sling repository.xml > > > > ---> referral to Apache Commons repository.xml > > > > > > > > I think, this solution can be easily and quickly implemented and > does > > > > not need too much additional network traffic. > > > > > > > > A further development step could be to have separate > repository.xml > > > > files for releases and SNAPSHOTs. We could arrange to update the > > > > SNAPSHOT repository.xml file by means of the maven-bundle-plugin > (would > > > > require to be able to specify the actual location repository.xml > file) > > > > upon deplyoment of the SNAPSHOTs... > > > > > > > > > > > > WDYT ? > > > > > > > > Regards > > > > Felix > > > > > > > > > > > > Am Freitag, den 16.05.2008, 10:40 -0400 schrieb Richard S. Hall: > > > > > > > >> If I understand correctly, Clement is proposing something like > this: > > > >> > > > >> releases/ > > > >> bundleA-v1/ > > > >> bundleA-v2/ > > > >> bundleB-v1/ > > > >> bundleC-v1/ > > > >> bundleC-v2/ > > > >> pom.xml > > > >> > > > >> The above represents the structure of our releases directory. > The > > > >> pom.xml will refer to the most recent version of each release > bundle, > > e.g.: > > > >> > > > >> pom.xml > > > >> artifactId=bundleA,version=2 > > > >> artifactId=bundleB,version=1 > > > >> artifactId=bundleC,version=2 > > > >> > > > >> The purpose of this pom file is largely to document which > subprojects > > > >> should be made available in our repo. However, if you use it to > issue > > > >> the mvn deploy command on this pom, then it will deploy the set > of all > > > >> current releases to the repo. > > > >> > > > >> This is obviously inefficient if only one bundle has been > updated > > since > > > >> it will deploy all bundles. To avoid this, though, you can > simply 'cd' > > > >> into the precise subproject release directory and issue that mvn > > deploy > > > >> command from there, then only the newly released bundle will be > > deployed. > > > >> > > > >> Clearly, this process is simplistic, but it is probably better > than > > > >> nothing, which is the current approach. The idea here is that we > could > > > >> just incorporate it as part of our normal release process, where > after > > > >> we tag a released bundle in the releases directory, then we > update the > > > >> version in the pom.xml and then deploy it to the repo. > > > >> > > > >> What do you think? > > > >> > > > >> -> richard > > > >> > > > >> [EMAIL PROTECTED] wrote: > > > >> > > > >>> If I understand well, Clement's proposal supposes that somebody > > deploys the whole set of felix bundles in a centralized manner. > > > >>> > > > >>> Another possibility is to incrementally evolve the remote > > repository.xml file, in a similar manner to the local repository.xml > file. > > Using this method for the official felix site would allow the person > > responsable for deploying some felix subproject on the maven > repository to > > deploy the same bundles on the obr. > > > >>> > > > >>> This means using the same kind of command line as Clement, but > at a > > subproject level (not at the root): > > > >>> mvn deploy -DremoteOBR > > -DaltDeploymentRepository=plop- > plop.felix.releases::default::scp://deploymentmachine/mypath > > deploys the artifacts on the remote obr AND updates the remote > > repository.xml file . > > > >>> > > > >>> I'm not involved in felix development, so I don't know what the > > policy is concerning deployment on the maven repository. If one > considers > > that felix contains some subprojects (sets of bundles) that evolve > rather > > independently from eachother, this incremental method can be > relevant. > > > >>> > > > >>> Regards, > > > >>> > > > >>> Anne > > > >>> > > > >>> -----Message d'origine----- > > > >>> De : Richard S. Hall [mailto:[EMAIL PROTECTED] > > > >>> Envoyé : jeudi 15 mai 2008 15:43 > > > >>> À : [email protected]; [EMAIL PROTECTED] > > > >>> Objet : Re: obr for felix bundles? > > > >>> > > > >>> I think the stylesheet can be figured out one way or the > other...what > > we really need to do is decide if we like the approach that Clement > has > > proposed and, if so, where should physically generate the > repository... > > > >>> > > > >>> -> richard > > > >>> > > > >>> Clement Escoffier wrote: > > > >>> > > > >>> > > > >>>> Hi, > > > >>>> > > > >>>> I change the XSLT file, now there is colors :-) > > > >>>> > > > >>>> Clement > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>>> -----Message d'origine----- > > > >>>>> De : [EMAIL PROTECTED] [mailto: > > [EMAIL PROTECTED] > > > >>>>> ftgroup.com] Envoyé : jeudi 15 mai 2008 03:37 À : > > > >>>>> [email protected] Objet : RE: obr for felix bundles? > > > >>>>> > > > >>>>> Hi Clement ! > > > >>>>> I have personally a slight preference for the stylesheet > coming > > from > > > >>>>> the OSGi Web site (attached file) . > > > >>>>> Apart from the style itself (better for presbyopian eyes), it > sorts > > > >>>>> the bundles alphabetically. I see you have commented this > feature > > in > > > >>>>> yuor xsl file. > > > >>>>> Of course that's a matter of personal preference, and that's > not > > the > > > >>>>> main point ! > > > >>>>> Best regards, > > > >>>>> Anne > > > >>>>> -----Message d'origine----- > > > >>>>> De : Clement Escoffier [mailto:[EMAIL PROTECTED] > > > >>>>> Envoyé : jeudi 15 mai 2008 03:42 > > > >>>>> À : [email protected] > > > >>>>> Objet : RE: obr for felix bundles? > > > >>>>> > > > >>>>> Hello, > > > >>>>> > > > >>>>> I attach the Didier's XSLT stylesheet to the generated XML > file. > > > >>>>> The result is available here : > > > >>>>> http://plop-plop.net/obr/repository.xml > > > >>>>> > > > >>>>> Clement > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>> -----Message d'origine----- > > > >>>>>> De : [EMAIL PROTECTED] > > > >>>>>> [mailto:[EMAIL PROTECTED] ftgroup.com] Envoyé : mardi > 13 mai > > 2008 06:25 À : > > > >>>>>> [email protected] Objet : RE: obr for felix bundles? > > > >>>>>> > > > >>>>>> Great idea ! > > > >>>>>> > > > >>>>>> Not only it will ease people getting started with felix, but > it > > can > > > >>>>>> help convince people giving a try : > > > >>>>>> if your repository.xml refers to an obr2html.xsl file, and > you > > show > > > >>>>>> people the repository in a browser, you will have the same > "waw" > > > >>>>>> effect as with the old Oscar repository. You see a nice list > of > > > >>>>>> already existing bundles, and if you follow the "doc" link > it goes > > > >>>>>> to the doc etc.. > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Anne > > > >>>>>> > > > >>>>>> -----Message d'origine----- > > > >>>>>> De : peter.doornbosch [mailto:[EMAIL PROTECTED] > > > >>>>>> Envoyé : samedi 10 mai 2008 11:43 > > > >>>>>> À : [email protected] > > > >>>>>> Objet : Re: obr for felix bundles? > > > >>>>>> > > > >>>>>> Hi Richard, > > > >>>>>> > > > >>>>>> I think it would be great if you can arrange this. I think > that > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>> people > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>> that are new to OSGi can have a hard time to get started > with > > felix > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>> (i > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>> noticed this a few times) and i think that being able to > install > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>> felix > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>> bundles in a simple and convenient way might help. > > > >>>>>> > > > >>>>>> Regards, > > > >>>>>> Peer > > > >>>>>> > > > >>>>>> > > > >>>>>> On 9 May , 2008, at 16:11 , Richard S. Hall wrote: > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> There currently is not. We definitely need this. It > basically > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> involves > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> determining at least two things: > > > >>>>>>> > > > >>>>>>> 1. How should we go about generating the repo? > > > >>>>>>> * We have the capability to generate OBR repository > > files, > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> but > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> how do we get one generated for our current set > of > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>> released > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>> bundle versions? > > > >>>>>>> 2. Where do we put the repository? > > > >>>>>>> > > > >>>>>>> I don't really know the best way to do (1). As for (2), I > am not > > > >>>>>>> sure if it matters, I don't think it needs to be hosted on > our > > > >>>>>>> Apache > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> site. > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> I could put the repo on my own personal web site or we > could just > > > >>>>>>> put them on the Source Forge web site. > > > >>>>>>> > > > >>>>>>> -> richard > > > >>>>>>> > > > >>>>>>> p.s. Sorry to cross post, it is not necessary to cross post > > > >>>>>>> replies...I just want to make sure that this discussion is > seen > > on > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>> the > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>> dev list. > > > >>>>>>> > > > >>>>>>> peter.doornbosch wrote: > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>>> Hi, > > > >>>>>>>> > > > >>>>>>>> I wonder if there is an obr repository for the (current > versions > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>> of > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>>> the) felix bundles. When i start felix (1.0.4), obr is > > configured > > > >>>>>>>> with the url http://oscar- > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>> osgi.sourceforge.net/obr2/repository.xml, > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>>> which contains only a few really old bundles.... > > > >>>>>>>> > > > >>>>>>>> Regards, > > > >>>>>>>> Peter > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > ------------------------------------------------------------------ > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>> - > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>>> - > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>> - > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >>>>>>>> For additional commands, e-mail: users- > [EMAIL PROTECTED] > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > ------------------------------------------------------------------- > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>> - > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>>>> - To unsubscribe, e-mail: users- > [EMAIL PROTECTED] > > > >>>>>>> For additional commands, e-mail: users- > [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] > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>> > > --------------------------------------------------------------------- > > > >>>>> 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] > > > >>> > > > >>> > > > >>> --------------------------------------------------------------- > ------ > > > >>> 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] > > > > > > > > > > > > > > ------------------------------------------------------------------- > -- > > > 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] > > > > > > > -- > Cheers, Stuart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
