Thank you guys. They are all useful suggestions. I will follow your suggestions and see if they could help me.
At a high level this is what we are trying to do: Our deployment environment is a self contained environment and shouldn't depend on external resources (maven repos etc) to run the application. This deployment environment is OSGi based Geronimo G3. In order to do that, we have a packaging step (this is non OSGi, standard java application), in which we resolve dependencies, get all the needed bundles and package them together for the deployment environment. As of now, we use Geronimo G3 even in this step to resolve all the dependencies of the eba file. So, we wanted to get away from using G3 in this stage and resolve the dependencies in a programmatic way, either using OBR Resolver or Aries application API. Regards Sankar ________________________________ From: Jeremy Hughes <hugh...@apache.org> To: user@aries.apache.org Sent: Thursday, October 20, 2011 10:28 AM Subject: Re: Resolving eba dependencies from a Stand alone Java App On 20 October 2011 18:00, Graham Charters <gchart...@gmail.com> wrote: > Hi Sankar, > > You probably want to get the set of bundles working in an OSGi > environment first. Some of the tests in Apache Aries should be able > to give you a head start on determining which these are (Mark may be > able to give more specific pointers than me). Once you've done that, > you could try using pojosr to run that set in a non-OSGi runtime Sankara, Graham has described how you get this running in a non-OSGi runtime. Is this what you want? I didn't read that into your initial email. The 'twitter' sample ... see trunk/samples/twitter may help. It configures the Felix OBR repository with a repository.xml, then uses the AriesApplicationManager to create an AriesApplication which it then resolves, after which the DeploymentMetadata object is retrieved from the Aries Application. It's about the simplest deployment manifest creation example that includes a repository configuration step. Of course that may not be quite what you want!! > (http://code.google.com/p/pojosr/). PojoSR would be necessary if the > bundles you are using make use of the OSGi service registry. It will > allow the service registry interactions to continue to work in a > non-modular, flat classpath, environment. > > I hope this helps. > > Regards, Graham. > > On 20 October 2011 17:40, Sankara Rao Bhogi <bsankara...@yahoo.com> wrote: >> Hi Mark, >> Thanks for the reply. Generating deployment.mf is my first problem to solve. >> What I need to do, given an eba file as an input, my application has to read >> the application.mf, read the top level modules and resolve (download) the >> dependencies. >> Regards >> Sankar >> >> ________________________________ >> From: Mark Nuttall <mnutt...@apache.org> >> To: user@aries.apache.org >> Sent: Thursday, October 20, 2011 9:26 AM >> Subject: Re: Resolving eba dependencies from a Stand alone Java App >> >> Hi Sankar, >> Can you please give us some more information about what you're trying to >> achieve? Are you looking to generate a deployment.mf file? Please help us >> understand the goal that you are trying to achieve so that we can give you >> appropriate advice. Thank you! >> Regards, >> Mark >> >> On 20 October 2011 17:05, Sankara Rao Bhogi <bsankara...@yahoo.com> wrote: >> >> Sorry, my earlier mail went with out subject. >> >> ________________________________ >> From: Sankara Rao Bhogi <bsankara...@yahoo.com> >> To: "user@aries.apache.org" <user@aries.apache.org> >> Sent: Thursday, October 20, 2011 9:02 AM >> Subject: >> >> >> Given an eba file (with out the deployment manifest), I would like to >> resolve dependencies from a stand alone Java Application. I had a look at >> various Aries Application APIs and they seems to be able to do the job that >> I want, but I am finding it hard to put them together. Sounds like >> AriesApplicationManager is a good start, but it is not clear how to get that >> one. Could anyone let me know, if this possible and if it is possible, >> where to start? >> Regards >> Sankar >> >> >> >> >> >> >> >> >
