You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Emily Jiang <em...@googlemail.com> on 2011/03/08 23:37:46 UTC
[Discussion] Provide an OBR repository generator
In Apache Aries, our resolver is able to take in any external repositories.
It is also able to generate repository xml by using the following code
snippet (lifted from the module of application itest,
OBRResolverAdvancedTest.java). *By the way, the repository xml generated by
apache aries includes the blueprint service/reference infomation, which
cannot be achived by bindex (a repository generator).*
private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
throws Exception
{
Set<ModelledResource> mrs = new HashSet<ModelledResource>();
FileOutputStream fout = new FileOutputStream("repository.xml");
RepositoryGenerator repositoryGenerator =
getOsgiService(RepositoryGenerator.class);
ModelledResourceManager modelledResourceManager =
getOsgiService(ModelledResourceManager.class);
for (String fileName : bundleFiles) {
File bundleFile = new File(fileName);
IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
String uri = "";
if (!!!nullURI) {
uri = bundleFile.toURI().toString();
}
mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
}
repositoryGenerator.generateRepository("Test repo description", mrs,
fout);
fout.close();
}
In order to get a repository xml, end users have to write the code snippet
above, which is not ideal. I propose to provide a jar file containing all
classes needed to generate the repository. The end user will just execute
the jar file and pass in the location of bundles in order to generate a
repository xml.
At the moment, the classes required for generating repository files are in
the modules of org.apache.aries.application.utils,
org.apache.aries.application.api, org.apache.aries.application.modeller,
org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
repository. However, I don't want to duplicate the classes due to future
maintence concern.
Any suggestions on how we can best achive this.
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: [Discussion] Provide an OBR repository generator
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
Create a new module for your code snippet, add the dependencies to the pom and then set Private-Package to include any packages you need and o believe they will be sucked into your jar.
There is a property for setting private package, but I can't recall the exact name.
Good luck.
Alasdair Nottingham
On 8 Mar 2011, at 22:37, Emily Jiang <em...@googlemail.com> wrote:
> In Apache Aries, our resolver is able to take in any external repositories.
> It is also able to generate repository xml by using the following code
> snippet (lifted from the module of application itest,
> OBRResolverAdvancedTest.java). *By the way, the repository xml generated by
> apache aries includes the blueprint service/reference infomation, which
> cannot be achived by bindex (a repository generator).*
>
> private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
> throws Exception
> {
> Set<ModelledResource> mrs = new HashSet<ModelledResource>();
> FileOutputStream fout = new FileOutputStream("repository.xml");
> RepositoryGenerator repositoryGenerator =
> getOsgiService(RepositoryGenerator.class);
> ModelledResourceManager modelledResourceManager =
> getOsgiService(ModelledResourceManager.class);
> for (String fileName : bundleFiles) {
> File bundleFile = new File(fileName);
> IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
> String uri = "";
> if (!!!nullURI) {
> uri = bundleFile.toURI().toString();
> }
> mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
> }
> repositoryGenerator.generateRepository("Test repo description", mrs,
> fout);
> fout.close();
> }
>
> In order to get a repository xml, end users have to write the code snippet
> above, which is not ideal. I propose to provide a jar file containing all
> classes needed to generate the repository. The end user will just execute
> the jar file and pass in the location of bundles in order to generate a
> repository xml.
>
> At the moment, the classes required for generating repository files are in
> the modules of org.apache.aries.application.utils,
> org.apache.aries.application.api, org.apache.aries.application.modeller,
> org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
> repository. However, I don't want to duplicate the classes due to future
> maintence concern.
>
> Any suggestions on how we can best achive this.
>
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
Re: [Discussion] Provide an OBR repository generator
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Mar 9, 2011 at 10:58, Alasdair Nottingham <no...@apache.org> wrote:
> On 9 March 2011 07:25, Guillaume Nodet <gn...@gmail.com> wrote:
>> The felix bundlerepository contains all the code needed to generate
>> OBR repositories. This code is leveraged by the maven bundle plugin
>> to generate the obr xml files at compilation time. This plugin also
>> includes a bindex goal (see bundle:index goal on
>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html).
>> Two more things: the blueprint information is indirectly leveraged
>> already through the use of manifest headers that are generated by the
>> maven bundle plugin after parsing the blueprint configuration (we've
>> already discussed that, but I tend to think it's more flexible as it
>> can also cover DS, iPojo or other osgi technologies).
>
> -1 -1 -1 obviously, and lets not go on here.
>
>> Last, the OSGi
>> alliance is working on an OBR spec and the felix bundlerepository is
>> supposed to be the reference implementation.
>> Maybe it would make sense to improve the felix implementation rather
>> than having duplicated code ?
>
> I disagree. First of all we already have the code to do this in apache aries
> as indicated by Emily. Secondly she isn't trying to create a maven plugin
> but something that can be used from a command line to generate an OBR based
> on a directory containing bundles. This is very different from what the
> maven-bundle-plugin does and is, in my view, valuable.
The code predates the one in aries. The code is in the felix
bundlerepository jar, so it's not a maven bundle plugin. The maven
bundle plugin just happen to use that code too.
The code could easily be enhanced to parse blueprint too if that's a
requirement for you.
I just wanted to express the fact that the code in felix will be
improved and enhanced to implement the OBR spec when it's out, so the
same work will have to be done in aries too.
I just think it's a waste of time to maintain this duplicated code,
but it's not my time ...
>
>>
>>
>> On Tue, Mar 8, 2011 at 23:37, Emily Jiang <em...@googlemail.com> wrote:
>>> In Apache Aries, our resolver is able to take in any external repositories.
>>> It is also able to generate repository xml by using the following code
>>> snippet (lifted from the module of application itest,
>>> OBRResolverAdvancedTest.java). *By the way, the repository xml generated by
>>> apache aries includes the blueprint service/reference infomation, which
>>> cannot be achived by bindex (a repository generator).*
>>>
>>> private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
>>> throws Exception
>>> {
>>> Set<ModelledResource> mrs = new HashSet<ModelledResource>();
>>> FileOutputStream fout = new FileOutputStream("repository.xml");
>>> RepositoryGenerator repositoryGenerator =
>>> getOsgiService(RepositoryGenerator.class);
>>> ModelledResourceManager modelledResourceManager =
>>> getOsgiService(ModelledResourceManager.class);
>>> for (String fileName : bundleFiles) {
>>> File bundleFile = new File(fileName);
>>> IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
>>> String uri = "";
>>> if (!!!nullURI) {
>>> uri = bundleFile.toURI().toString();
>>> }
>>> mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
>>> }
>>> repositoryGenerator.generateRepository("Test repo description", mrs,
>>> fout);
>>> fout.close();
>>> }
>>>
>>> In order to get a repository xml, end users have to write the code snippet
>>> above, which is not ideal. I propose to provide a jar file containing all
>>> classes needed to generate the repository. The end user will just execute
>>> the jar file and pass in the location of bundles in order to generate a
>>> repository xml.
>>>
>>> At the moment, the classes required for generating repository files are in
>>> the modules of org.apache.aries.application.utils,
>>> org.apache.aries.application.api, org.apache.aries.application.modeller,
>>> org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
>>> repository. However, I don't want to duplicate the classes due to future
>>> maintence concern.
>>>
>>> Any suggestions on how we can best achive this.
>>>
>>> Thanks
>>> Emily
>>> =================
>>> Emily Jiang
>>> ejiang@apache.org
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [Discussion] Provide an OBR repository generator
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
As Guillaume said: Apache Felix BundleRepository has the code and it is
used by the Maven Bundle Plugin.
If you want to create some command line tool, which I think is an
excellent idea, you should really leverage what's there in the Apche
Felix BundleRepository code.
Because, and this is the most important point: This will allow users of
the tools a seamless experience and a single point of fixing issues.
Regards
Felix
Am Mittwoch, den 09.03.2011, 10:10 +0000 schrieb Emily Jiang:
> Thanks to Alasdiar for your recommendation. I will give it a go.
>
> Guillaume, thanks for your input. Felix bundle repositiory generation takes
> care of blueprint, DS etc info if the bundles are generated using maven
> bundle plugin. The fact is that not every bundle is generated by using maven
> plugin. We need to cater for all scenarios. Therefore, I think we should
> provide our own generator.
>
> On Wed, Mar 9, 2011 at 9:58 AM, Alasdair Nottingham <no...@apache.org> wrote:
>
> > On 9 March 2011 07:25, Guillaume Nodet <gn...@gmail.com> wrote:
> > > The felix bundlerepository contains all the code needed to generate
> > > OBR repositories. This code is leveraged by the maven bundle plugin
> > > to generate the obr xml files at compilation time. This plugin also
> > > includes a bindex goal (see bundle:index goal on
> > > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html).
> > > Two more things: the blueprint information is indirectly leveraged
> > > already through the use of manifest headers that are generated by the
> > > maven bundle plugin after parsing the blueprint configuration (we've
> > > already discussed that, but I tend to think it's more flexible as it
> > > can also cover DS, iPojo or other osgi technologies).
> >
> > -1 -1 -1 obviously, and lets not go on here.
> >
> > > Last, the OSGi
> > > alliance is working on an OBR spec and the felix bundlerepository is
> > > supposed to be the reference implementation.
> > > Maybe it would make sense to improve the felix implementation rather
> > > than having duplicated code ?
> >
> > I disagree. First of all we already have the code to do this in apache
> > aries
> > as indicated by Emily. Secondly she isn't trying to create a maven plugin
> > but something that can be used from a command line to generate an OBR based
> > on a directory containing bundles. This is very different from what the
> > maven-bundle-plugin does and is, in my view, valuable.
> >
> > >
> > >
> > > On Tue, Mar 8, 2011 at 23:37, Emily Jiang <em...@googlemail.com>
> > wrote:
> > >> In Apache Aries, our resolver is able to take in any external
> > repositories.
> > >> It is also able to generate repository xml by using the following code
> > >> snippet (lifted from the module of application itest,
> > >> OBRResolverAdvancedTest.java). *By the way, the repository xml generated
> > by
> > >> apache aries includes the blueprint service/reference infomation, which
> > >> cannot be achived by bindex (a repository generator).*
> > >>
> > >> private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
> > >> throws Exception
> > >> {
> > >> Set<ModelledResource> mrs = new HashSet<ModelledResource>();
> > >> FileOutputStream fout = new FileOutputStream("repository.xml");
> > >> RepositoryGenerator repositoryGenerator =
> > >> getOsgiService(RepositoryGenerator.class);
> > >> ModelledResourceManager modelledResourceManager =
> > >> getOsgiService(ModelledResourceManager.class);
> > >> for (String fileName : bundleFiles) {
> > >> File bundleFile = new File(fileName);
> > >> IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
> > >> String uri = "";
> > >> if (!!!nullURI) {
> > >> uri = bundleFile.toURI().toString();
> > >> }
> > >> mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
> > >> }
> > >> repositoryGenerator.generateRepository("Test repo description", mrs,
> > >> fout);
> > >> fout.close();
> > >> }
> > >>
> > >> In order to get a repository xml, end users have to write the code
> > snippet
> > >> above, which is not ideal. I propose to provide a jar file containing
> > all
> > >> classes needed to generate the repository. The end user will just
> > execute
> > >> the jar file and pass in the location of bundles in order to generate a
> > >> repository xml.
> > >>
> > >> At the moment, the classes required for generating repository files are
> > in
> > >> the modules of org.apache.aries.application.utils,
> > >> org.apache.aries.application.api, org.apache.aries.application.modeller,
> > >> org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
> > >> repository. However, I don't want to duplicate the classes due to future
> > >> maintence concern.
> > >>
> > >> Any suggestions on how we can best achive this.
> > >>
> > >> Thanks
> > >> Emily
> > >> =================
> > >> Emily Jiang
> > >> ejiang@apache.org
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Blog: http://gnodet.blogspot.com/
> > > ------------------------
> > > Open Source SOA
> > > http://fusesource.com
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
Re: [Discussion] Provide an OBR repository generator
Posted by Emily Jiang <em...@googlemail.com>.
Thanks to Alasdiar for your recommendation. I will give it a go.
Guillaume, thanks for your input. Felix bundle repositiory generation takes
care of blueprint, DS etc info if the bundles are generated using maven
bundle plugin. The fact is that not every bundle is generated by using maven
plugin. We need to cater for all scenarios. Therefore, I think we should
provide our own generator.
On Wed, Mar 9, 2011 at 9:58 AM, Alasdair Nottingham <no...@apache.org> wrote:
> On 9 March 2011 07:25, Guillaume Nodet <gn...@gmail.com> wrote:
> > The felix bundlerepository contains all the code needed to generate
> > OBR repositories. This code is leveraged by the maven bundle plugin
> > to generate the obr xml files at compilation time. This plugin also
> > includes a bindex goal (see bundle:index goal on
> > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html).
> > Two more things: the blueprint information is indirectly leveraged
> > already through the use of manifest headers that are generated by the
> > maven bundle plugin after parsing the blueprint configuration (we've
> > already discussed that, but I tend to think it's more flexible as it
> > can also cover DS, iPojo or other osgi technologies).
>
> -1 -1 -1 obviously, and lets not go on here.
>
> > Last, the OSGi
> > alliance is working on an OBR spec and the felix bundlerepository is
> > supposed to be the reference implementation.
> > Maybe it would make sense to improve the felix implementation rather
> > than having duplicated code ?
>
> I disagree. First of all we already have the code to do this in apache
> aries
> as indicated by Emily. Secondly she isn't trying to create a maven plugin
> but something that can be used from a command line to generate an OBR based
> on a directory containing bundles. This is very different from what the
> maven-bundle-plugin does and is, in my view, valuable.
>
> >
> >
> > On Tue, Mar 8, 2011 at 23:37, Emily Jiang <em...@googlemail.com>
> wrote:
> >> In Apache Aries, our resolver is able to take in any external
> repositories.
> >> It is also able to generate repository xml by using the following code
> >> snippet (lifted from the module of application itest,
> >> OBRResolverAdvancedTest.java). *By the way, the repository xml generated
> by
> >> apache aries includes the blueprint service/reference infomation, which
> >> cannot be achived by bindex (a repository generator).*
> >>
> >> private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
> >> throws Exception
> >> {
> >> Set<ModelledResource> mrs = new HashSet<ModelledResource>();
> >> FileOutputStream fout = new FileOutputStream("repository.xml");
> >> RepositoryGenerator repositoryGenerator =
> >> getOsgiService(RepositoryGenerator.class);
> >> ModelledResourceManager modelledResourceManager =
> >> getOsgiService(ModelledResourceManager.class);
> >> for (String fileName : bundleFiles) {
> >> File bundleFile = new File(fileName);
> >> IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
> >> String uri = "";
> >> if (!!!nullURI) {
> >> uri = bundleFile.toURI().toString();
> >> }
> >> mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
> >> }
> >> repositoryGenerator.generateRepository("Test repo description", mrs,
> >> fout);
> >> fout.close();
> >> }
> >>
> >> In order to get a repository xml, end users have to write the code
> snippet
> >> above, which is not ideal. I propose to provide a jar file containing
> all
> >> classes needed to generate the repository. The end user will just
> execute
> >> the jar file and pass in the location of bundles in order to generate a
> >> repository xml.
> >>
> >> At the moment, the classes required for generating repository files are
> in
> >> the modules of org.apache.aries.application.utils,
> >> org.apache.aries.application.api, org.apache.aries.application.modeller,
> >> org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
> >> repository. However, I don't want to duplicate the classes due to future
> >> maintence concern.
> >>
> >> Any suggestions on how we can best achive this.
> >>
> >> Thanks
> >> Emily
> >> =================
> >> Emily Jiang
> >> ejiang@apache.org
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: [Discussion] Provide an OBR repository generator
Posted by Alasdair Nottingham <no...@apache.org>.
On 9 March 2011 07:25, Guillaume Nodet <gn...@gmail.com> wrote:
> The felix bundlerepository contains all the code needed to generate
> OBR repositories. This code is leveraged by the maven bundle plugin
> to generate the obr xml files at compilation time. This plugin also
> includes a bindex goal (see bundle:index goal on
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html).
> Two more things: the blueprint information is indirectly leveraged
> already through the use of manifest headers that are generated by the
> maven bundle plugin after parsing the blueprint configuration (we've
> already discussed that, but I tend to think it's more flexible as it
> can also cover DS, iPojo or other osgi technologies).
-1 -1 -1 obviously, and lets not go on here.
> Last, the OSGi
> alliance is working on an OBR spec and the felix bundlerepository is
> supposed to be the reference implementation.
> Maybe it would make sense to improve the felix implementation rather
> than having duplicated code ?
I disagree. First of all we already have the code to do this in apache aries
as indicated by Emily. Secondly she isn't trying to create a maven plugin
but something that can be used from a command line to generate an OBR based
on a directory containing bundles. This is very different from what the
maven-bundle-plugin does and is, in my view, valuable.
>
>
> On Tue, Mar 8, 2011 at 23:37, Emily Jiang <em...@googlemail.com> wrote:
>> In Apache Aries, our resolver is able to take in any external repositories.
>> It is also able to generate repository xml by using the following code
>> snippet (lifted from the module of application itest,
>> OBRResolverAdvancedTest.java). *By the way, the repository xml generated by
>> apache aries includes the blueprint service/reference infomation, which
>> cannot be achived by bindex (a repository generator).*
>>
>> private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
>> throws Exception
>> {
>> Set<ModelledResource> mrs = new HashSet<ModelledResource>();
>> FileOutputStream fout = new FileOutputStream("repository.xml");
>> RepositoryGenerator repositoryGenerator =
>> getOsgiService(RepositoryGenerator.class);
>> ModelledResourceManager modelledResourceManager =
>> getOsgiService(ModelledResourceManager.class);
>> for (String fileName : bundleFiles) {
>> File bundleFile = new File(fileName);
>> IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
>> String uri = "";
>> if (!!!nullURI) {
>> uri = bundleFile.toURI().toString();
>> }
>> mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
>> }
>> repositoryGenerator.generateRepository("Test repo description", mrs,
>> fout);
>> fout.close();
>> }
>>
>> In order to get a repository xml, end users have to write the code snippet
>> above, which is not ideal. I propose to provide a jar file containing all
>> classes needed to generate the repository. The end user will just execute
>> the jar file and pass in the location of bundles in order to generate a
>> repository xml.
>>
>> At the moment, the classes required for generating repository files are in
>> the modules of org.apache.aries.application.utils,
>> org.apache.aries.application.api, org.apache.aries.application.modeller,
>> org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
>> repository. However, I don't want to duplicate the classes due to future
>> maintence concern.
>>
>> Any suggestions on how we can best achive this.
>>
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [Discussion] Provide an OBR repository generator
Posted by Guillaume Nodet <gn...@gmail.com>.
The felix bundlerepository contains all the code needed to generate
OBR repositories. This code is leveraged by the maven bundle plugin
to generate the obr xml files at compilation time. This plugin also
includes a bindex goal (see bundle:index goal on
http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html).
Two more things: the blueprint information is indirectly leveraged
already through the use of manifest headers that are generated by the
maven bundle plugin after parsing the blueprint configuration (we've
already discussed that, but I tend to think it's more flexible as it
can also cover DS, iPojo or other osgi technologies). Last, the OSGi
alliance is working on an OBR spec and the felix bundlerepository is
supposed to be the reference implementation.
Maybe it would make sense to improve the felix implementation rather
than having duplicated code ?
On Tue, Mar 8, 2011 at 23:37, Emily Jiang <em...@googlemail.com> wrote:
> In Apache Aries, our resolver is able to take in any external repositories.
> It is also able to generate repository xml by using the following code
> snippet (lifted from the module of application itest,
> OBRResolverAdvancedTest.java). *By the way, the repository xml generated by
> apache aries includes the blueprint service/reference infomation, which
> cannot be achived by bindex (a repository generator).*
>
> private void generateOBRRepoXML(boolean nullURI, String ... bundleFiles)
> throws Exception
> {
> Set<ModelledResource> mrs = new HashSet<ModelledResource>();
> FileOutputStream fout = new FileOutputStream("repository.xml");
> RepositoryGenerator repositoryGenerator =
> getOsgiService(RepositoryGenerator.class);
> ModelledResourceManager modelledResourceManager =
> getOsgiService(ModelledResourceManager.class);
> for (String fileName : bundleFiles) {
> File bundleFile = new File(fileName);
> IDirectory jarDir = FileSystem.getFSRoot(bundleFile);
> String uri = "";
> if (!!!nullURI) {
> uri = bundleFile.toURI().toString();
> }
> mrs.add(modelledResourceManager.getModelledResource(uri, jarDir));
> }
> repositoryGenerator.generateRepository("Test repo description", mrs,
> fout);
> fout.close();
> }
>
> In order to get a repository xml, end users have to write the code snippet
> above, which is not ideal. I propose to provide a jar file containing all
> classes needed to generate the repository. The end user will just execute
> the jar file and pass in the location of bundles in order to generate a
> repository xml.
>
> At the moment, the classes required for generating repository files are in
> the modules of org.apache.aries.application.utils,
> org.apache.aries.application.api, org.apache.aries.application.modeller,
> org.apache.aries.obr.resolver, org.apache.aries.blueprint, felix bundle
> repository. However, I don't want to duplicate the classes due to future
> maintence concern.
>
> Any suggestions on how we can best achive this.
>
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com