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.
-> 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
À : users@felix.apache.org; [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 À :
users@felix.apache.org 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
À : users@felix.apache.org
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 À :
users@felix.apache.org 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
À : users@felix.apache.org
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
