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: [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]
