You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Henri Gomez <he...@gmail.com> on 2009/01/27 12:24:30 UTC
maven / osgi / repositories
Hi to all,
We're using maven to build all our company projects for about 6 months
and are very happy with it.
Some of our projects, mainly Eclipse RCP plugins, are also mavenized.
We know think about OSGIfing more of our projects (server side) and
track ASF projects Felix of course core but also ServiceMix Kernel.
BTW, we wonder if there is a consensus or strategy about OSGIfied
artifacts and their location in external repositories.
- Should we repackage our current projects to produce both jar and plugins ?
- How and where to store these artifacts to make sure Felix could get
it (did a Nexus repository could do the job).
- How to 'mark' artifacts to indicate the difference between strict
jar and OSIG jars (bundles). Eclipse prefix then with org.eclipse, SS
with com.springsource ?
Advices and experience are more than welcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Henri Gomez <he...@gmail.com>.
>> One thing I have been toying with for a while is to auto-magically
>> extend maven-jar-plugin to add the OSGi headers.
> I really don't think this is a great idea. I think for a bundle to be useful
> someone needs to provide proper imports and exports.
Right, but it make took years ;(
>> I haven't given a lot of thought into what I need to do, but if I
>> recall correctly, getting a simple OSGified jar isn't much work and if
>> Maven did this out of the box then the maven repository would become
>> OSGified over time as projects release their artifacts.
> We've toyed around with this idea, but if you want something useful I think
> it's really hard to infer something useful. Making a manifest that is
> workable with OSGi is not that hard and the author of a package is probably
> the person to do it. I think what we can do is give a brief guideline as to
> what's commonly expected and help people create correct and useful bundles.
> Maven central is the biggest bundle repository in waiting :-)
So you recommand education and lobbying.
May be ASF should show the way, there is tons of projects today still
not OSGIfied in ASF repo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: maven / osgi / repositories
Posted by "Edelson, Justin" <Ju...@mtvstaff.com>.
> I think what we can do is
> give a brief guideline as to what's commonly expected and help people
> create correct and useful bundles.
Clearing up the version vs. classifier issue would be a good first step.
________________________________
From: Jason van Zyl [mailto:jvanzyl@sonatype.com]
Sent: Tue 1/27/2009 10:43 PM
To: Maven Users List
Subject: Re: maven / osgi / repositories
On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote:
>> repositories. They might become OBRs at some point when OSGi becomes
>> more "mainstream".
>
> One thing I have been toying with for a while is to auto-magically
> extend maven-jar-plugin to add the OSGi headers.
>
I really don't think this is a great idea. I think for a bundle to be
useful someone needs to provide proper imports and exports.
> I haven't given a lot of thought into what I need to do, but if I
> recall correctly, getting a simple OSGified jar isn't much work and if
> Maven did this out of the box then the maven repository would become
> OSGified over time as projects release their artifacts.
>
We've toyed around with this idea, but if you want something useful I
think it's really hard to infer something useful. Making a manifest
that is workable with OSGi is not that hard and the author of a
package is probably the person to do it. I think what we can do is
give a brief guideline as to what's commonly expected and help people
create correct and useful bundles. Maven central is the biggest bundle
repository in waiting :-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, Jan 28, 2009 at 2:13 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote:
>
>>> repositories. They might become OBRs at some point when OSGi becomes
>>> more "mainstream".
>>
>> One thing I have been toying with for a while is to auto-magically
>> extend maven-jar-plugin to add the OSGi headers.
>>
>
> I really don't think this is a great idea. I think for a bundle to be useful
> someone needs to provide proper imports and exports.
>
>> I haven't given a lot of thought into what I need to do, but if I
>> recall correctly, getting a simple OSGified jar isn't much work and if
>> Maven did this out of the box then the maven repository would become
>> OSGified over time as projects release their artifacts.
>>
>
> We've toyed around with this idea, but if you want something useful I think
> it's really hard to infer something useful. Making a manifest that is
> workable with OSGi is not that hard and the author of a package is probably
> the person to do it. I think what we can do is give a brief guideline as to
> what's commonly expected and help people create correct and useful bundles.
> Maven central is the biggest bundle repository in waiting :-)
I agree it is sub-optimal.
I think I would be suggesting a very broad approach.
* OSGi bundle id matching group/artifactId combos.
* exporting everything that is within the current artifact
* wiring OSGi dependencies to match artifact dependencies probably
without version ranges.
Without thinking about it properly I think that would get people
80%-90% there with OSGi without having to re-wrap artifacts.
I can't see how it will make things worse.
This approach has some down sides
* it exposes more than the author would expect
* the dependencies may not yet be OSGified (but as they get released
via maven that would get fixed)
* OSGi headers may not be what the author would prefer (but they would
be consistent with maven guidelines)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by lukewpatterson <lu...@gmail.com>.
Jason van Zyl-5 wrote:
>
>
> On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote:
>
>>> repositories. They might become OBRs at some point when OSGi becomes
>>> more "mainstream".
>>
>> One thing I have been toying with for a while is to auto-magically
>> extend maven-jar-plugin to add the OSGi headers.
>>
>
> I really don't think this is a great idea. I think for a bundle to be
> useful someone needs to provide proper imports and exports.
>
>> I haven't given a lot of thought into what I need to do, but if I
>> recall correctly, getting a simple OSGified jar isn't much work and if
>> Maven did this out of the box then the maven repository would become
>> OSGified over time as projects release their artifacts.
>>
>
> We've toyed around with this idea, but if you want something useful I
> think it's really hard to infer something useful. Making a manifest
> that is workable with OSGi is not that hard and the author of a
> package is probably the person to do it. I think what we can do is
> give a brief guideline as to what's commonly expected and help people
> create correct and useful bundles. Maven central is the biggest bundle
> repository in waiting :-)
>
>
I'm sure my views aren't unique, and I'm probably rehashing what someone
else already said, but here goes:
When you see that a dependency isn't OSGi-ified, first put yourself in the
shoes of its authors, and consider the possible reasons:
* "No one has requested OSGi-ification." This is pretty common. The
author's don't even know that there is a demand because no one asked. Even
if there is no time to wait on the authors and you have to custom-deploy a
wrapped-version, at least file a bug to get the ball rolling.
* "It's just a packaging concern, you can download a wrapped bundle from
www.blah......" The Maven community has the most to lose from this approach
to OSGi-ification. This wreaks havoc with the coordinate system. Sometimes
the authors don't even know that others (1..*) have published wrapped
versions of their jars. The dependency authors should be made aware that
these workarounds do not serve the Maven+OSGi community well.
* "We would add it, but how could we test it and maintain it?" This is very
common too and I don't think there is an easy answer yet. Much of the
testing infrastructure isn't even OSGi-ified yet.
When filing requests for OSGi-ification, it would be nice if I could direct
the dependency authors to a site/mailing-list where all their
OSGi-ification/Maven-alignment questions could be answered. Does such a
resource exist?
I recently filed a request with Mockito, please take a look and let me know
if I should have done anything differently:
http://code.google.com/p/mockito/issues/detail?id=67
--
View this message in context: http://www.nabble.com/maven---osgi---repositories-tp21683632p22770424.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Jason van Zyl <jv...@sonatype.com>.
On 27-Jan-09, at 6:41 PM, Barrie Treloar wrote:
>> repositories. They might become OBRs at some point when OSGi becomes
>> more "mainstream".
>
> One thing I have been toying with for a while is to auto-magically
> extend maven-jar-plugin to add the OSGi headers.
>
I really don't think this is a great idea. I think for a bundle to be
useful someone needs to provide proper imports and exports.
> I haven't given a lot of thought into what I need to do, but if I
> recall correctly, getting a simple OSGified jar isn't much work and if
> Maven did this out of the box then the maven repository would become
> OSGified over time as projects release their artifacts.
>
We've toyed around with this idea, but if you want something useful I
think it's really hard to infer something useful. Making a manifest
that is workable with OSGi is not that hard and the author of a
package is probably the person to do it. I think what we can do is
give a brief guideline as to what's commonly expected and help people
create correct and useful bundles. Maven central is the biggest bundle
repository in waiting :-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Barrie Treloar <ba...@gmail.com>.
> repositories. They might become OBRs at some point when OSGi becomes
> more "mainstream".
One thing I have been toying with for a while is to auto-magically
extend maven-jar-plugin to add the OSGi headers.
I haven't given a lot of thought into what I need to do, but if I
recall correctly, getting a simple OSGified jar isn't much work and if
Maven did this out of the box then the maven repository would become
OSGified over time as projects release their artifacts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: m2eclipse CTRL-SHIFT-T "Open Type" dialog is missing
Posted by "Lincoln Baxter, III" <li...@gmail.com>.
Thanks! You nailed it.
For some reason the Maven plugin disabled my Perspective -> Customize ->
Commands -> Java Open Type option.
Happier...
--Lincoln
On Thu, 2009-01-29 at 12:53 +0100, Mateusz Grzechociński wrote:
> 2009/1/28 Lincoln Baxter, III <li...@gmail.com>:
> > Hi Mavenites,
> >
> > When I install the m2eclipse plugin, version 0.9.6, my Open Type dialog
> > box disappears. I can't bring it up with a shortcut. The menu item is
> > gone. It's just missing.
> > Is this intentional? I really rely on this dialog quite a bit. How can I
> > get it back?
>
> Hi, I had the same issue and In my case restoring default shortcuts in
> Eclipse Preferences solved this problem
>
> Cheers
> Matthew
Re: m2eclipse CTRL-SHIFT-T "Open Type" dialog is missing
Posted by Mateusz Grzechociński <ma...@grzechocinski.net>.
2009/1/28 Lincoln Baxter, III <li...@gmail.com>:
> Hi Mavenites,
>
> When I install the m2eclipse plugin, version 0.9.6, my Open Type dialog
> box disappears. I can't bring it up with a shortcut. The menu item is
> gone. It's just missing.
> Is this intentional? I really rely on this dialog quite a bit. How can I
> get it back?
Hi, I had the same issue and In my case restoring default shortcuts in
Eclipse Preferences solved this problem
Cheers
Matthew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
m2eclipse CTRL-SHIFT-T "Open Type" dialog is missing
Posted by "Lincoln Baxter, III" <li...@gmail.com>.
Hi Mavenites,
When I install the m2eclipse plugin, version 0.9.6, my Open Type dialog
box disappears. I can't bring it up with a shortcut. The menu item is
gone. It's just missing.
Is this intentional? I really rely on this dialog quite a bit. How can I
get it back?
Thanks,
Lincoln
RE : maven / osgi / repositories
Posted by "Deneux, Christophe" <ch...@capgemini.com>.
Isn't the role of the "classifier" field ?
instead of :
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
we could use :
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
<classifier>osgi</classifier>
________________________________
De: Henri Gomez [mailto:henri.gomez@gmail.com]
Date: mar. 27/01/2009 23:00
À: Maven Users List
Objet : Re: maven / osgi / repositories
> as you point it out there is definitely an issue with the renaming of
> groupId /artifactId as it will 'break' maven dependency management.
> However I don't think that anyone but the project owner(s) should be
> allowed to deploy a jar with their groupId/artifactId (to the public
> repo). I believe this is why the springsource guys renamed theirs.
>
> I feel like the issue with non-OSGi jars is very similar to what
> happened when first moving all libraries from the maven1 repository to
> the maven2 repository. This is even more complicated as this time the
> "metadata" in inside the jar. Until all projects make the effort of
> having a correct OSGi compatible MANIFEST in their jars we'll have to
> deal with it ourselves.
>
> The only way that I can think of it working is to have your own
> repository with OSGi-ified versions of the libraries you need. The
> most sensible thing to do is probably changing the version so that it
> identifies the jar as being OSGi. This will let you use maven's
> dependency management to some extent. You will have to use the
> "dependencyManagement" section of your POMs though to enforce OSGi
> versions of the libraries. I don't think those jars can go to the
> public repo though.
Good idea.
instead of :
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
we could use :
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1-osgi</version>
> Practically I would consider creating maven projects on your side of
> things using the shade plugin to create an OSGi version of the library
> you want, just overriding/merging the MANIFEST and changing the
> version. This would simply be a pom.xml and a MANIFEST file.
> Another thing is definitely to create issues and provide patches to
> those project so that they can start make their jars OSGi compatible.
That's a huge task and may be a duplicate works from what is done by
SpringSource and Eclipse ;(
BTW, I'll be happy to see a sample pom.xml for such task, if you have
one, it's more than welcome
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this message.
Re: maven / osgi / repositories
Posted by Henri Gomez <he...@gmail.com>.
> as you point it out there is definitely an issue with the renaming of
> groupId /artifactId as it will 'break' maven dependency management.
> However I don't think that anyone but the project owner(s) should be
> allowed to deploy a jar with their groupId/artifactId (to the public
> repo). I believe this is why the springsource guys renamed theirs.
>
> I feel like the issue with non-OSGi jars is very similar to what
> happened when first moving all libraries from the maven1 repository to
> the maven2 repository. This is even more complicated as this time the
> "metadata" in inside the jar. Until all projects make the effort of
> having a correct OSGi compatible MANIFEST in their jars we'll have to
> deal with it ourselves.
>
> The only way that I can think of it working is to have your own
> repository with OSGi-ified versions of the libraries you need. The
> most sensible thing to do is probably changing the version so that it
> identifies the jar as being OSGi. This will let you use maven's
> dependency management to some extent. You will have to use the
> "dependencyManagement" section of your POMs though to enforce OSGi
> versions of the libraries. I don't think those jars can go to the
> public repo though.
Good idea.
instead of :
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1</version>
we could use :
<groupId>org.apache.ant</groupId>
<artifactId>ant</artifactId>
<version>1.7.1-osgi</version>
> Practically I would consider creating maven projects on your side of
> things using the shade plugin to create an OSGi version of the library
> you want, just overriding/merging the MANIFEST and changing the
> version. This would simply be a pom.xml and a MANIFEST file.
> Another thing is definitely to create issues and provide patches to
> those project so that they can start make their jars OSGi compatible.
That's a huge task and may be a duplicate works from what is done by
SpringSource and Eclipse ;(
BTW, I'll be happy to see a sample pom.xml for such task, if you have
one, it's more than welcome
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Samuel Le Berrigaud <sa...@gmail.com>.
Hi,
as you point it out there is definitely an issue with the renaming of
groupId /artifactId as it will 'break' maven dependency management.
However I don't think that anyone but the project owner(s) should be
allowed to deploy a jar with their groupId/artifactId (to the public
repo). I believe this is why the springsource guys renamed theirs.
I feel like the issue with non-OSGi jars is very similar to what
happened when first moving all libraries from the maven1 repository to
the maven2 repository. This is even more complicated as this time the
"metadata" in inside the jar. Until all projects make the effort of
having a correct OSGi compatible MANIFEST in their jars we'll have to
deal with it ourselves.
The only way that I can think of it working is to have your own
repository with OSGi-ified versions of the libraries you need. The
most sensible thing to do is probably changing the version so that it
identifies the jar as being OSGi. This will let you use maven's
dependency management to some extent. You will have to use the
"dependencyManagement" section of your POMs though to enforce OSGi
versions of the libraries. I don't think those jars can go to the
public repo though.
Practically I would consider creating maven projects on your side of
things using the shade plugin to create an OSGi version of the library
you want, just overriding/merging the MANIFEST and changing the
version. This would simply be a pom.xml and a MANIFEST file.
Another thing is definitely to create issues and provide patches to
those project so that they can start make their jars OSGi compatible.
SaM
On Wed, Jan 28, 2009 at 12:18 AM, Henri Gomez <he...@gmail.com> wrote:
>> Hi Henri,
>>
>> it seems to me that OSGi jars are not meant to be anything else that
>> traditional jars with extra information in their MANIFEST. I would
>> definitely recomment deploying them as standard jar as you would do
>> for any normal maven project.
>
> Simple jar with MANIFEST, but today very few maven artifact are
> OSGIfied, so so should geth OSGIfied jars elsewhere or with a
> different group/artifact id ;(
>
>> One thing that could/would differentiate your OSGi jars is that if you
>> use the maven bundle plugin
>> [http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html]
>> then the pom deployed along side your jar will have the packaging set
>> to "bundle". To me it seems like enough information.
>
> For inhouse projects, it's not a problem and we allready do that from
> our RCP projects, but the problem is still here for external projects,
> ie ant, jaxws...
>
>> Another point of reference you might consider is how the springsource
>> guys make OSGi-ified version of many java libraries in their bundle
>> repository [http://www.springsource.com/repository/]. This acts pretty
>> much as a simple maven repository delivering jars.
>
> I see that but the group/artifact is not the same that the one used in
> developpement, hard after that to get a clean trace from developpment
> to runtime :(
>
>> Also I know that the Felix guys have an initiative around an OSGi
>> Bundle Repository (OBR)
>> [http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html].
>> This is meant to be a repository that is more OSGi specific. I could
>> help with dependency resolution -- just as maven does -- by
>> introspecting jars MANIFESTs.
>
> A good idea, it will be nice to get it as maven central.
>
> And in the long term, get all 'maven' artifact converted to
> osgi-bundle (very long term).
>
> Or may by specializing maven request, ie I need ant-1.7.2 jar,
> ant-1.7.2 osgi-bundle.
> So we could have simple jar and bundle at the same location in maven repo.
>
>> Archiva or Nexus would most probably satisfy your needs for maven
>> repositories. They might become OBRs at some point when OSGi becomes
>> more "mainstream".
>
> I think there is plan for this in Nexus.
>
>> Hope this helps,
>> SaM
>
> Thanks for your time Sam, it was helpfull :)
>
>> On Tue, Jan 27, 2009 at 10:24 PM, Henri Gomez <he...@gmail.com> wrote:
>>> Hi to all,
>>>
>>> We're using maven to build all our company projects for about 6 months
>>> and are very happy with it.
>>> Some of our projects, mainly Eclipse RCP plugins, are also mavenized.
>>>
>>> We know think about OSGIfing more of our projects (server side) and
>>> track ASF projects Felix of course core but also ServiceMix Kernel.
>>>
>>> BTW, we wonder if there is a consensus or strategy about OSGIfied
>>> artifacts and their location in external repositories.
>>>
>>> - Should we repackage our current projects to produce both jar and plugins ?
>>>
>>> - How and where to store these artifacts to make sure Felix could get
>>> it (did a Nexus repository could do the job).
>>>
>>> - How to 'mark' artifacts to indicate the difference between strict
>>> jar and OSIG jars (bundles). Eclipse prefix then with org.eclipse, SS
>>> with com.springsource ?
>>>
>>>
>>> Advices and experience are more than welcome.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Henri Gomez <he...@gmail.com>.
> Hi Henri,
>
> it seems to me that OSGi jars are not meant to be anything else that
> traditional jars with extra information in their MANIFEST. I would
> definitely recomment deploying them as standard jar as you would do
> for any normal maven project.
Simple jar with MANIFEST, but today very few maven artifact are
OSGIfied, so so should geth OSGIfied jars elsewhere or with a
different group/artifact id ;(
> One thing that could/would differentiate your OSGi jars is that if you
> use the maven bundle plugin
> [http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html]
> then the pom deployed along side your jar will have the packaging set
> to "bundle". To me it seems like enough information.
For inhouse projects, it's not a problem and we allready do that from
our RCP projects, but the problem is still here for external projects,
ie ant, jaxws...
> Another point of reference you might consider is how the springsource
> guys make OSGi-ified version of many java libraries in their bundle
> repository [http://www.springsource.com/repository/]. This acts pretty
> much as a simple maven repository delivering jars.
I see that but the group/artifact is not the same that the one used in
developpement, hard after that to get a clean trace from developpment
to runtime :(
> Also I know that the Felix guys have an initiative around an OSGi
> Bundle Repository (OBR)
> [http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html].
> This is meant to be a repository that is more OSGi specific. I could
> help with dependency resolution -- just as maven does -- by
> introspecting jars MANIFESTs.
A good idea, it will be nice to get it as maven central.
And in the long term, get all 'maven' artifact converted to
osgi-bundle (very long term).
Or may by specializing maven request, ie I need ant-1.7.2 jar,
ant-1.7.2 osgi-bundle.
So we could have simple jar and bundle at the same location in maven repo.
> Archiva or Nexus would most probably satisfy your needs for maven
> repositories. They might become OBRs at some point when OSGi becomes
> more "mainstream".
I think there is plan for this in Nexus.
> Hope this helps,
> SaM
Thanks for your time Sam, it was helpfull :)
> On Tue, Jan 27, 2009 at 10:24 PM, Henri Gomez <he...@gmail.com> wrote:
>> Hi to all,
>>
>> We're using maven to build all our company projects for about 6 months
>> and are very happy with it.
>> Some of our projects, mainly Eclipse RCP plugins, are also mavenized.
>>
>> We know think about OSGIfing more of our projects (server side) and
>> track ASF projects Felix of course core but also ServiceMix Kernel.
>>
>> BTW, we wonder if there is a consensus or strategy about OSGIfied
>> artifacts and their location in external repositories.
>>
>> - Should we repackage our current projects to produce both jar and plugins ?
>>
>> - How and where to store these artifacts to make sure Felix could get
>> it (did a Nexus repository could do the job).
>>
>> - How to 'mark' artifacts to indicate the difference between strict
>> jar and OSIG jars (bundles). Eclipse prefix then with org.eclipse, SS
>> with com.springsource ?
>>
>>
>> Advices and experience are more than welcome.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Henri Gomez <he...@gmail.com>.
>> Another point of reference you might consider is how the springsource
>> guys make OSGi-ified version of many java libraries in their bundle
>> repository [http://www.springsource.com/repository/]. This acts pretty
>> much as a simple maven repository delivering jars.
>
> ..with renamed group/artifactIds, which _completely_ destroys the entire
> transitive dependency resolution.
That's one of my concern.
Different group/artifactid make a split between developpement and runtime ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Holger Hoffstaette <ho...@wizards.de>.
On Tue, 27 Jan 2009 22:53:10 +1100, Samuel Le Berrigaud wrote:
> Another point of reference you might consider is how the springsource
> guys make OSGi-ified version of many java libraries in their bundle
> repository [http://www.springsource.com/repository/]. This acts pretty
> much as a simple maven repository delivering jars.
..with renamed group/artifactIds, which _completely_ destroys the entire
transitive dependency resolution.
-h
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven / osgi / repositories
Posted by Samuel Le Berrigaud <sa...@gmail.com>.
Hi Henri,
it seems to me that OSGi jars are not meant to be anything else that
traditional jars with extra information in their MANIFEST. I would
definitely recomment deploying them as standard jar as you would do
for any normal maven project.
One thing that could/would differentiate your OSGi jars is that if you
use the maven bundle plugin
[http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html]
then the pom deployed along side your jar will have the packaging set
to "bundle". To me it seems like enough information.
Another point of reference you might consider is how the springsource
guys make OSGi-ified version of many java libraries in their bundle
repository [http://www.springsource.com/repository/]. This acts pretty
much as a simple maven repository delivering jars.
Also I know that the Felix guys have an initiative around an OSGi
Bundle Repository (OBR)
[http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html].
This is meant to be a repository that is more OSGi specific. I could
help with dependency resolution -- just as maven does -- by
introspecting jars MANIFESTs.
Archiva or Nexus would most probably satisfy your needs for maven
repositories. They might become OBRs at some point when OSGi becomes
more "mainstream".
Hope this helps,
SaM
On Tue, Jan 27, 2009 at 10:24 PM, Henri Gomez <he...@gmail.com> wrote:
> Hi to all,
>
> We're using maven to build all our company projects for about 6 months
> and are very happy with it.
> Some of our projects, mainly Eclipse RCP plugins, are also mavenized.
>
> We know think about OSGIfing more of our projects (server side) and
> track ASF projects Felix of course core but also ServiceMix Kernel.
>
> BTW, we wonder if there is a consensus or strategy about OSGIfied
> artifacts and their location in external repositories.
>
> - Should we repackage our current projects to produce both jar and plugins ?
>
> - How and where to store these artifacts to make sure Felix could get
> it (did a Nexus repository could do the job).
>
> - How to 'mark' artifacts to indicate the difference between strict
> jar and OSIG jars (bundles). Eclipse prefix then with org.eclipse, SS
> with com.springsource ?
>
>
> Advices and experience are more than welcome.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org