You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Nascif Abousalh-Neto <Na...@sas.com> on 2007/03/07 21:58:01 UTC
OSGi backend?
Hi everybody,
In my company we have a jar repository that implements the OSGi spec. It is basically a large directory with the same structure you would find under the Eclipse IDE "plugins" directory. Each of our jar files is stored as an Eclipse plugin, or as an OSGi bundle.
>From my first reading of the Ivy documentation, I believe I would be able to just configure a filesystem resolver to point to the repository with the appropriate pattern. But just out of curiosity, I thought I would ask to see if anybody has already implemented it since it and/or has suggestions on a different approach.
Thanks,
Nascif
Re: OSGi backend?
Posted by Steve Loughran <st...@apache.org>.
Cecile wrote:
> Steve,
>
> 2007/3/12, Steve Loughran <st...@apache.org>:
>> yes, but can you do dynamic code download?
>
> I'm not sure what you mean by "dynamic code download".
RMI can be used to send objects over the wire where the far end doesnt
have the .class files. The URLs to the files get sent over via the rmi
codebase list of URLs, which the far end instantiates and uses. This
lets RMI nodes share content dynamically, wich is used in jini a lot.
The problems we hit are related to the recipient not knowing which
bundle to load stuff in...the wire serialization doesnt include enough
data for a complete reconstruction.
>
> This might be a digression from Nascif's original question.
> RMI aside, I've written code with multiple implementations of a single
> interface (all residing in different bundles) and one my services
> would adapt itself depending on what other dependent services were
> running or disable itself if required services were not available. I
> have hunch that you're thinking of cross-VM service dependencies. i.e.
> A bundle in one VM accessing a class in another VM.
Sort of, but its mainly getting machines to talk to each other without
having all the artifacts pre-installed at the far end. I think OSGi
works best if whoever assembles the bundle knew exactly what was going
to be needed at all times.
anyway, this is a digression from the issues of building/using OSGi. I
think Ivy and Ant could be made OSGi friendly.
-have manifest information that can be used for both setting up the
classpaths at compile, and for making OSGi manifests
-at compile time, you only want the service interfaces
-tasks to do the packaging, create the metadata in the manifests
-A new ant resource, say, <osgipath> that sets up classloaders right
-an osgi-aware version of <java> that runs OSGi apps by setting things
up right.
just some thoughts; we may discuss this at apachecon in may, if you are
going to be in Amsterdam
-steve
Re: OSGi backend?
Posted by Cecile <ru...@gmail.com>.
Steve,
2007/3/12, Steve Loughran <st...@apache.org>:
> yes, but can you do dynamic code download?
I'm not sure what you mean by "dynamic code download".
This might be a digression from Nascif's original question.
RMI aside, I've written code with multiple implementations of a single
interface (all residing in different bundles) and one my services
would adapt itself depending on what other dependent services were
running or disable itself if required services were not available. I
have hunch that you're thinking of cross-VM service dependencies. i.e.
A bundle in one VM accessing a class in another VM.
Re: OSGi backend?
Posted by Steve Loughran <st...@apache.org>.
Cecile wrote:
> Steve,
>
>> could evolve to work better with OSGi dev. I have a colleague who is
>> trying to work out how to get RMI to work with OSGi properly, which is
>> v. hard because serialization info doesnt include any way to identify
>> which bundle something came from.
>
> I'm developing a remote management tool to access an OSGi container
> using JMX.
> My MBean interface and its implementation are in different bundles.
> And I run a local RMI registry. I can make remote calls (transparently
> via JMX) without any problems.
yes, but can you do dynamic code download?
Re: OSGi backend?
Posted by Cecile <ru...@gmail.com>.
Steve,
> could evolve to work better with OSGi dev. I have a colleague who is
> trying to work out how to get RMI to work with OSGi properly, which is
> v. hard because serialization info doesnt include any way to identify
> which bundle something came from.
I'm developing a remote management tool to access an OSGi container using JMX.
My MBean interface and its implementation are in different bundles.
And I run a local RMI registry. I can make remote calls (transparently
via JMX) without any problems.
Re: OSGi backend?
Posted by Steve Loughran <st...@apache.org>.
Nascif Abousalh-Neto wrote:
> Hi everybody,
>
> In my company we have a jar repository that implements the OSGi spec. It is basically a large directory with the same structure you would find under the Eclipse IDE "plugins" directory. Each of our jar files is stored as an Eclipse plugin, or as an OSGi bundle.
>
> From my first reading of the Ivy documentation, I believe I would be able to just configure a filesystem resolver to point to the repository with the appropriate pattern. But just out of curiosity, I thought I would ask to see if anybody has already implemented it since it and/or has suggestions on a different approach.
>
> Thanks,
> Nascif
OSGi has a different view of the world, on account of a clear separation
between published interfaces, implementations and dependency packages.
I'd be interested to see how you get on with Ivy -and how Ivy and Ant
could evolve to work better with OSGi dev. I have a colleague who is
trying to work out how to get RMI to work with OSGi properly, which is
v. hard because serialization info doesnt include any way to identify
which bundle something came from.
-steve
Re: Eclipse integration
Posted by Xavier Hanin <xa...@gmail.com>.
On 3/12/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Reports are great and definitely a step in the right direction; but the
> larger the scope of your build, the larger the chance that someone won't
> look at them close enough. So it is safer to have automated safeguards, like
> IDE-based notification and build failures.
But you can also automatically look at your reports. Ivy reports are xml
based, and you can get their xml versions easily. So some xpath should be
enough to break a build based on your reports. But that's just another idea
than ConflictManager.
- Xavier
I like the idea of managing this at the conflict manager level, could be
> useful too.
>
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Saturday, March 10, 2007 4:48 AM
> To: ivy-user@incubator.apache.org
> Subject: Re: Eclipse integration
>
> On 3/9/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
> >
> > Sorry I was not clear. Here is the scenario: in a large corporation,
> > you have the concept of a major release. At that milestone, you want
> > to ship hundreds of jars in dozens of products. Many of those jars are
> > common dependencies accross projects, OK?
> >
> > The scenario is: you don't want to ship different versions of those
> > shared dependencies - you want only the latest version of each one. So
> > while you can allow some flexibility during the development phase
> > (different projects using different versions), as you get closer to
> > the release you want to enforce some "convergence" so that X weeks
> > before launching everbody is on the same page.
> >
> > This is what I meant by "failing the resolve task if ivy.xml has more
> > then X% old dependencies..."
> >
> > But perhaps the right answer is to just make sure everybody is
> > building against the integration version at that point.
>
>
> Even if there's nothing automated to do what you want, I think that using
> reports can be useful: You can for example create an ivy file for your major
> release, declaring dependencies on all your products. Then if you resolve
> the dependencies you will see in the report how many conflicts you have. You
> can even define your own conflict manager to make the build fail if you have
> too many conflicts. Or parse the xml report to create a warning if
> dependencies are not aligned. Is it the kind of thing you were thinking
> about?
>
> - Xavier
>
> Thanks,
> > Nascif
> >
> > -----Original Message-----
> > From: Dmitriy Korobskiy [mailto:dk.root@verizon.net]
> > Sent: Wednesday, March 07, 2007 9:53 PM
> > To: Nascif Abousalh-Neto
> > Subject: Re: Eclipse integration
> >
> > Hi, Nascif
> > Re: your e-mail from Wednesday, March 7, 2007 5:47 PM
> >
> > NAN> Another newbie question - does Ivy provide any support to alert
> > NAN> the user that it is time to update the dependency versions in
> ivy.xml?
> >
> > NAN> For example, an IDE view of the repository with decorators
> > NAN> showing
> > which dependencies are "out-of-date"?
> >
> > NAN> One of the most common fears I encounter when "evangelizing" the
> > NAN> dependency management approach is that developers will stay too
> > NAN> long on their "island of code" while their dependencies drift
> > NAN> away to newer and newer versions. I am trying to think of ways
> > NAN> that would make it easier to enforce some kind of motility - and
> > NAN> a visual indication that your dependencies are getting old would
> > NAN> be a
> > great help.
> >
> > NAN> Perhaps some way of failing the resolve task if ivy.xml has more
> > NAN> then
> > X% old dependencies...
> >
> > NAN> Does anybody has a similar use case?
> >
> > If you are simply trying to "get the latest version" you can use
> > dynamic revisions in your Ivy files (for example, <dependency
> name="commons-logging"
> > rev="latest.integration" conf="default"/>
> >
> > Perhaps, I am not quite understanding what you are trying to achieve.
> >
> > Dmitriy <1-127-441 @ICQ, DKroot @Skype, DKroot1 @AIM,
> > dkroot1_at_gmail_dot_com @Google Talk>
> >
> >
>
RE: Eclipse integration
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
Reports are great and definitely a step in the right direction; but the larger the scope of your build, the larger the chance that someone won't look at them close enough. So it is safer to have automated safeguards, like IDE-based notification and build failures.
I like the idea of managing this at the conflict manager level, could be useful too.
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Saturday, March 10, 2007 4:48 AM
To: ivy-user@incubator.apache.org
Subject: Re: Eclipse integration
On 3/9/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Sorry I was not clear. Here is the scenario: in a large corporation,
> you have the concept of a major release. At that milestone, you want
> to ship hundreds of jars in dozens of products. Many of those jars are
> common dependencies accross projects, OK?
>
> The scenario is: you don't want to ship different versions of those
> shared dependencies - you want only the latest version of each one. So
> while you can allow some flexibility during the development phase
> (different projects using different versions), as you get closer to
> the release you want to enforce some "convergence" so that X weeks
> before launching everbody is on the same page.
>
> This is what I meant by "failing the resolve task if ivy.xml has more
> then X% old dependencies..."
>
> But perhaps the right answer is to just make sure everybody is
> building against the integration version at that point.
Even if there's nothing automated to do what you want, I think that using reports can be useful: You can for example create an ivy file for your major release, declaring dependencies on all your products. Then if you resolve the dependencies you will see in the report how many conflicts you have. You can even define your own conflict manager to make the build fail if you have too many conflicts. Or parse the xml report to create a warning if dependencies are not aligned. Is it the kind of thing you were thinking about?
- Xavier
Thanks,
> Nascif
>
> -----Original Message-----
> From: Dmitriy Korobskiy [mailto:dk.root@verizon.net]
> Sent: Wednesday, March 07, 2007 9:53 PM
> To: Nascif Abousalh-Neto
> Subject: Re: Eclipse integration
>
> Hi, Nascif
> Re: your e-mail from Wednesday, March 7, 2007 5:47 PM
>
> NAN> Another newbie question - does Ivy provide any support to alert
> NAN> the user that it is time to update the dependency versions in ivy.xml?
>
> NAN> For example, an IDE view of the repository with decorators
> NAN> showing
> which dependencies are "out-of-date"?
>
> NAN> One of the most common fears I encounter when "evangelizing" the
> NAN> dependency management approach is that developers will stay too
> NAN> long on their "island of code" while their dependencies drift
> NAN> away to newer and newer versions. I am trying to think of ways
> NAN> that would make it easier to enforce some kind of motility - and
> NAN> a visual indication that your dependencies are getting old would
> NAN> be a
> great help.
>
> NAN> Perhaps some way of failing the resolve task if ivy.xml has more
> NAN> then
> X% old dependencies...
>
> NAN> Does anybody has a similar use case?
>
> If you are simply trying to "get the latest version" you can use
> dynamic revisions in your Ivy files (for example, <dependency name="commons-logging"
> rev="latest.integration" conf="default"/>
>
> Perhaps, I am not quite understanding what you are trying to achieve.
>
> Dmitriy <1-127-441 @ICQ, DKroot @Skype, DKroot1 @AIM,
> dkroot1_at_gmail_dot_com @Google Talk>
>
>
Re: Eclipse integration
Posted by Xavier Hanin <xa...@gmail.com>.
On 3/9/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Sorry I was not clear. Here is the scenario: in a large corporation, you
> have the concept of a major release. At that milestone, you want to ship
> hundreds of jars in dozens of products. Many of those jars are common
> dependencies accross projects, OK?
>
> The scenario is: you don't want to ship different versions of those shared
> dependencies - you want only the latest version of each one. So while you
> can allow some flexibility during the development phase (different projects
> using different versions), as you get closer to the release you want to
> enforce some "convergence" so that X weeks before launching everbody is on
> the same page.
>
> This is what I meant by "failing the resolve task if ivy.xml has more then
> X% old dependencies..."
>
> But perhaps the right answer is to just make sure everybody is building
> against the integration version at that point.
Even if there's nothing automated to do what you want, I think that using
reports can be useful: You can for example create an ivy file for your major
release, declaring dependencies on all your products. Then if you resolve
the dependencies you will see in the report how many conflicts you have. You
can even define your own conflict manager to make the build fail if you have
too many conflicts. Or parse the xml report to create a warning if
dependencies are not aligned. Is it the kind of thing you were thinking
about?
- Xavier
Thanks,
> Nascif
>
> -----Original Message-----
> From: Dmitriy Korobskiy [mailto:dk.root@verizon.net]
> Sent: Wednesday, March 07, 2007 9:53 PM
> To: Nascif Abousalh-Neto
> Subject: Re: Eclipse integration
>
> Hi, Nascif
> Re: your e-mail from Wednesday, March 7, 2007 5:47 PM
>
> NAN> Another newbie question - does Ivy provide any support to alert the
> NAN> user that it is time to update the dependency versions in ivy.xml?
>
> NAN> For example, an IDE view of the repository with decorators showing
> which dependencies are "out-of-date"?
>
> NAN> One of the most common fears I encounter when "evangelizing" the
> NAN> dependency management approach is that developers will stay too
> NAN> long on their "island of code" while their dependencies drift away
> NAN> to newer and newer versions. I am trying to think of ways that
> NAN> would make it easier to enforce some kind of motility - and a
> NAN> visual indication that your dependencies are getting old would be a
> great help.
>
> NAN> Perhaps some way of failing the resolve task if ivy.xml has more then
> X% old dependencies...
>
> NAN> Does anybody has a similar use case?
>
> If you are simply trying to "get the latest version" you can use dynamic
> revisions in your Ivy files (for example, <dependency name="commons-logging"
> rev="latest.integration" conf="default"/>
>
> Perhaps, I am not quite understanding what you are trying to achieve.
>
> Dmitriy <1-127-441 @ICQ, DKroot @Skype, DKroot1 @AIM,
> dkroot1_at_gmail_dot_com @Google Talk>
>
>
RE: Eclipse integration
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
Sorry I was not clear. Here is the scenario: in a large corporation, you have the concept of a major release. At that milestone, you want to ship hundreds of jars in dozens of products. Many of those jars are common dependencies accross projects, OK?
The scenario is: you don't want to ship different versions of those shared dependencies - you want only the latest version of each one. So while you can allow some flexibility during the development phase (different projects using different versions), as you get closer to the release you want to enforce some "convergence" so that X weeks before launching everbody is on the same page.
This is what I meant by "failing the resolve task if ivy.xml has more then X% old dependencies..."
But perhaps the right answer is to just make sure everybody is building against the integration version at that point.
Thanks,
Nascif
-----Original Message-----
From: Dmitriy Korobskiy [mailto:dk.root@verizon.net]
Sent: Wednesday, March 07, 2007 9:53 PM
To: Nascif Abousalh-Neto
Subject: Re: Eclipse integration
Hi, Nascif
Re: your e-mail from Wednesday, March 7, 2007 5:47 PM
NAN> Another newbie question - does Ivy provide any support to alert the
NAN> user that it is time to update the dependency versions in ivy.xml?
NAN> For example, an IDE view of the repository with decorators showing which dependencies are "out-of-date"?
NAN> One of the most common fears I encounter when "evangelizing" the
NAN> dependency management approach is that developers will stay too
NAN> long on their "island of code" while their dependencies drift away
NAN> to newer and newer versions. I am trying to think of ways that
NAN> would make it easier to enforce some kind of motility - and a
NAN> visual indication that your dependencies are getting old would be a great help.
NAN> Perhaps some way of failing the resolve task if ivy.xml has more then X% old dependencies...
NAN> Does anybody has a similar use case?
If you are simply trying to "get the latest version" you can use dynamic revisions in your Ivy files (for example, <dependency name="commons-logging" rev="latest.integration" conf="default"/>
Perhaps, I am not quite understanding what you are trying to achieve.
Dmitriy <1-127-441 @ICQ, DKroot @Skype, DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk>
Re: Eclipse integration
Posted by Dmitriy Korobskiy <dk...@verizon.net>.
Hi, Nascif
Re: your e-mail from Wednesday, March 7, 2007 5:47 PM
NAN> Another newbie question - does Ivy provide any support to alert the user
NAN> that it is time to update the dependency versions in ivy.xml?
NAN> For example, an IDE view of the repository with decorators showing which dependencies are "out-of-date"?
NAN> One of the most common fears I encounter when "evangelizing" the
NAN> dependency management approach is that developers will stay too long on
NAN> their "island of code" while their dependencies drift away to newer and
NAN> newer versions. I am trying to think of ways that would make it easier to
NAN> enforce some kind of motility - and a visual indication that your
NAN> dependencies are getting old would be a great help.
NAN> Perhaps some way of failing the resolve task if ivy.xml has more then X% old dependencies...
NAN> Does anybody has a similar use case?
If you are simply trying to "get the latest version" you can use dynamic revisions in your Ivy files (for example,
<dependency name="commons-logging" rev="latest.integration" conf="default"/>
Perhaps, I am not quite understanding what you are trying to achieve.
Dmitriy <1-127-441 @ICQ, DKroot @Skype, DKroot1 @AIM, dkroot1_at_gmail_dot_com @Google Talk>
Re: Eclipse integration
Posted by Xavier Hanin <xa...@gmail.com>.
On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Another newbie question - does Ivy provide any support to alert the user
> that it is time to update the dependency versions in ivy.xml?
>
> For example, an IDE view of the repository with decorators showing which
> dependencies are "out-of-date"?
No, there is no such view or alerts. This is something feasible, because you
can actually resolve dependencies without downloading artifacts using Ivy
API, so you could implement this kind of feature in IvyDE quite easily (but
it may take time to compute the information, so I think this is something
that would better be done on purpose, the same way a Team Synchronize is
done).
One of the most common fears I encounter when "evangelizing" the dependency
> management approach is that developers will stay too long on their "island
> of code" while their dependencies drift away to newer and newer versions. I
> am trying to think of ways that would make it easier to enforce some kind of
> motility - and a visual indication that your dependencies are getting old
> would be a great help.
>
> Perhaps some way of failing the resolve task if ivy.xml has more then X%
> old dependencies...
I'm not sure to understand, how would you get the more recent versions if
your resolve is failing? From my experience it's a habit to take, to update
dependencies approximately as often as you update your codebase from your
SCM. Maybe an option in IvyDE to automatically call resolve when you do an
update could be fine, but it's not easy, because you can update files one by
one...
- Xavier
Does anybody has a similar use case?
>
Re: Eclipse integration
Posted by Steve Loughran <st...@apache.org>.
Nascif Abousalh-Neto wrote:
> Another newbie question - does Ivy provide any support to alert the user that it is time to update the dependency versions in ivy.xml?
>
> For example, an IDE view of the repository with decorators showing which dependencies are "out-of-date"?
>
> One of the most common fears I encounter when "evangelizing" the dependency management approach is that developers will stay too long on their "island of code" while their dependencies drift away to newer and newer versions. I am trying to think of ways that would make it easier to enforce some kind of motility - and a visual indication that your dependencies are getting old would be a great help.
>
> Perhaps some way of failing the resolve task if ivy.xml has more then X% old dependencies...
>
> Does anybody has a similar use case?
>
1. We keep our list of versions in a file, libraries.properties. This
locks down everything that is built and shipped with.
2. I dont want random developers updating that file, though they are
free to override it in build.properties to experiment with.
3. I guess I would like to track versions, but that could be done via an
RSS subscription of some sort, say mvnrepo.com, to let me know which
artifacts of interest were newer.
-steve
Eclipse integration
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
Another newbie question - does Ivy provide any support to alert the user that it is time to update the dependency versions in ivy.xml?
For example, an IDE view of the repository with decorators showing which dependencies are "out-of-date"?
One of the most common fears I encounter when "evangelizing" the dependency management approach is that developers will stay too long on their "island of code" while their dependencies drift away to newer and newer versions. I am trying to think of ways that would make it easier to enforce some kind of motility - and a visual indication that your dependencies are getting old would be a great help.
Perhaps some way of failing the resolve task if ivy.xml has more then X% old dependencies...
Does anybody has a similar use case?
RE: OSGi backend?
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
Excellent, thanks for the tip.
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Wednesday, March 07, 2007 5:10 PM
To: ivy-user@incubator.apache.org
Subject: Re: OSGi backend?
On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Thanks for the quick reply. I will give the filesystem a try.
>
> Actually we have an in-house developed dependency management system
> (that I hope to replace with Ivy) that supercedes the module
> descriptors in the osgi manifest; fortunately its dependency files are
> easy to parse and will give me a starting point to create the ivy.xml.
> Unfortunately, they won't be of any use to the community.
Note that you can provide a customm module descriptor parser and continue to use your own format if you prefer. It depends on why you migrate away from your existing dependency management system.
But if later we migrate to a true OSGi system and I have something more
> standard, I would be happy to share it.
>
> Thanks,
> Nascif
>
> PS: I might have to create an extension anyway because in some cases I
> have to check for extra metadata about the artifact before deciding it
> should be considered or not. Basically I would have to look into the
> manifest for the presence of a flag; if it is there I would like to
> evict the artifact, even if the version is a good match (and somehow
> provide an indication of that in a report).
>
> Would that be better done in a filesystem extention/replacement as a
> new resolver, or any of the other kinds of ivy plugins?
With a custom dependency resolver you can do it with no problem, but it might be somewhat complex , because DependencyResolver have quite a lot of responsibilities, so it makes them more difficult to extend / customize.
Maybe what you want could be easily achieved with a VersionMatcher: you can consider your version with the flag as "not matching" and this should be enough.
- Xavier
-----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Wednesday, March 07, 2007 4:18 PM
> To: ivy-user@incubator.apache.org
> Subject: Re: OSGi backend?
>
> On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
> >
> > Hi everybody,
> >
> > In my company we have a jar repository that implements the OSGi spec.
> > It is basically a large directory with the same structure you would
> > find under the Eclipse IDE "plugins" directory. Each of our jar
> > files is stored as an Eclipse plugin, or as an OSGi bundle.
> >
> > From my first reading of the Ivy documentation, I believe I would
> > be able to just configure a filesystem resolver to point to the
> > repository with the appropriate pattern. But just out of curiosity,
> > I thought I would ask to see if anybody has already implemented it
> > since it and/or has suggestions on a different approach.
>
>
> I think using a filesystem resolver should be fine. Note that if you
> want to use transitive dependencies, you will have either to write ivy
> files for your bundles, or write a custom parser able to parse osgi
> manifest as a module descriptor. This way to go is more interesting
> IMO, because this is something that could be shared with the
> community. I'd be glad to help to write such a parser. Another thing
> that may cause some troubles is that OSGi bundles do not separate the organization and module name concepts.
> Everything is in the bundle symbolic name. The easiest solution I see
> to this problem is to consider the part of the symbolic name before
> the last dot to be the organisation, and the remaining part the name.
> But this is only a suggestion.
>
> HTH,
> - Xavier
>
> Thanks,
> > Nascif
> >
> >
> >
>
Re: OSGi backend?
Posted by Xavier Hanin <xa...@gmail.com>.
On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Thanks for the quick reply. I will give the filesystem a try.
>
> Actually we have an in-house developed dependency management system (that
> I hope to replace with Ivy) that supercedes the module descriptors in the
> osgi manifest; fortunately its dependency files are easy to parse and will
> give me a starting point to create the ivy.xml. Unfortunately, they won't
> be of any use to the community.
Note that you can provide a customm module descriptor parser and continue to
use your own format if you prefer. It depends on why you migrate away from
your existing dependency management system.
But if later we migrate to a true OSGi system and I have something more
> standard, I would be happy to share it.
>
> Thanks,
> Nascif
>
> PS: I might have to create an extension anyway because in some cases I
> have to check for extra metadata about the artifact before deciding it
> should be considered or not. Basically I would have to look into the
> manifest for the presence of a flag; if it is there I would like to evict
> the artifact, even if the version is a good match (and somehow provide an
> indication of that in a report).
>
> Would that be better done in a filesystem extention/replacement as a new
> resolver, or any of the other kinds of ivy plugins?
With a custom dependency resolver you can do it with no problem, but it
might be somewhat complex , because DependencyResolver have quite a lot of
responsibilities, so it makes them more difficult to extend / customize.
Maybe what you want could be easily achieved with a VersionMatcher: you can
consider your version with the flag as "not matching" and this should be
enough.
- Xavier
-----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Wednesday, March 07, 2007 4:18 PM
> To: ivy-user@incubator.apache.org
> Subject: Re: OSGi backend?
>
> On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
> >
> > Hi everybody,
> >
> > In my company we have a jar repository that implements the OSGi spec.
> > It is basically a large directory with the same structure you would
> > find under the Eclipse IDE "plugins" directory. Each of our jar files
> > is stored as an Eclipse plugin, or as an OSGi bundle.
> >
> > From my first reading of the Ivy documentation, I believe I would be
> > able to just configure a filesystem resolver to point to the
> > repository with the appropriate pattern. But just out of curiosity, I
> > thought I would ask to see if anybody has already implemented it since
> > it and/or has suggestions on a different approach.
>
>
> I think using a filesystem resolver should be fine. Note that if you want
> to use transitive dependencies, you will have either to write ivy files for
> your bundles, or write a custom parser able to parse osgi manifest as a
> module descriptor. This way to go is more interesting IMO, because this is
> something that could be shared with the community. I'd be glad to help to
> write such a parser. Another thing that may cause some troubles is that OSGi
> bundles do not separate the organization and module name concepts.
> Everything is in the bundle symbolic name. The easiest solution I see to
> this problem is to consider the part of the symbolic name before the last
> dot to be the organisation, and the remaining part the name. But this is
> only a suggestion.
>
> HTH,
> - Xavier
>
> Thanks,
> > Nascif
> >
> >
> >
>
RE: OSGi backend?
Posted by Nascif Abousalh-Neto <Na...@sas.com>.
Thanks for the quick reply. I will give the filesystem a try.
Actually we have an in-house developed dependency management system (that I hope to replace with Ivy) that supercedes the module descriptors in the osgi manifest; fortunately its dependency files are easy to parse and will give me a starting point to create the ivy.xml. Unfortunately, they won't be of any use to the community.
But if later we migrate to a true OSGi system and I have something more standard, I would be happy to share it.
Thanks,
Nascif
PS: I might have to create an extension anyway because in some cases I have to check for extra metadata about the artifact before deciding it should be considered or not. Basically I would have to look into the manifest for the presence of a flag; if it is there I would like to evict the artifact, even if the version is a good match (and somehow provide an indication of that in a report).
Would that be better done in a filesystem extention/replacement as a new resolver, or any of the other kinds of ivy plugins?
-----Original Message-----
From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
Sent: Wednesday, March 07, 2007 4:18 PM
To: ivy-user@incubator.apache.org
Subject: Re: OSGi backend?
On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Hi everybody,
>
> In my company we have a jar repository that implements the OSGi spec.
> It is basically a large directory with the same structure you would
> find under the Eclipse IDE "plugins" directory. Each of our jar files
> is stored as an Eclipse plugin, or as an OSGi bundle.
>
> From my first reading of the Ivy documentation, I believe I would be
> able to just configure a filesystem resolver to point to the
> repository with the appropriate pattern. But just out of curiosity, I
> thought I would ask to see if anybody has already implemented it since
> it and/or has suggestions on a different approach.
I think using a filesystem resolver should be fine. Note that if you want to use transitive dependencies, you will have either to write ivy files for your bundles, or write a custom parser able to parse osgi manifest as a module descriptor. This way to go is more interesting IMO, because this is something that could be shared with the community. I'd be glad to help to write such a parser. Another thing that may cause some troubles is that OSGi bundles do not separate the organization and module name concepts.
Everything is in the bundle symbolic name. The easiest solution I see to this problem is to consider the part of the symbolic name before the last dot to be the organisation, and the remaining part the name. But this is only a suggestion.
HTH,
- Xavier
Thanks,
> Nascif
>
>
>
Re: OSGi backend?
Posted by Xavier Hanin <xa...@gmail.com>.
On 3/7/07, Nascif Abousalh-Neto <Na...@sas.com> wrote:
>
> Hi everybody,
>
> In my company we have a jar repository that implements the OSGi spec. It
> is basically a large directory with the same structure you would find under
> the Eclipse IDE "plugins" directory. Each of our jar files is stored as an
> Eclipse plugin, or as an OSGi bundle.
>
> From my first reading of the Ivy documentation, I believe I would be able
> to just configure a filesystem resolver to point to the repository with the
> appropriate pattern. But just out of curiosity, I thought I would ask to see
> if anybody has already implemented it since it and/or has suggestions on a
> different approach.
I think using a filesystem resolver should be fine. Note that if you want to
use transitive dependencies, you will have either to write ivy files for
your bundles, or write a custom parser able to parse osgi manifest as a
module descriptor. This way to go is more interesting IMO, because this is
something that could be shared with the community. I'd be glad to help to
write such a parser. Another thing that may cause some troubles is that OSGi
bundles do not separate the organization and module name concepts.
Everything is in the bundle symbolic name. The easiest solution I see to
this problem is to consider the part of the symbolic name before the last
dot to be the organisation, and the remaining part the name. But this is
only a suggestion.
HTH,
- Xavier
Thanks,
> Nascif
>
>
>