You can also use Github repo as a Maven index, see how the bnd project on 
github does both. (Though we host on cloudbees)

Kind regards,

        Peter Kriens

> On 6 sep. 2016, at 00:50, Daghan ACAY <daghana...@hotmail.com> wrote:
> 
> Hi Peter,
> 
> I was thinking about this, i actually love FixedIndexedRepo because i can use 
> githubusercontent as poor man's nexus :).
> 
> Do you think it is useful to add transient dependency information into  the 
> FixedIndexedRepo indexes. I believe this will be similar functionally that 
> you will offer with BndPomRepository. Should i put this to bndtool as feature 
> request?
> 
> Cheers
> 
> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your emails 
> as clean, short chats.
> 
> 
> 
> -------- Original Message --------
> From: Daghan ACAY <daghana...@hotmail.com>
> Sent: Monday, September 5, 2016 07:50 PM
> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] Bundle resolution in BND
> 
> Hi Peter,
> 
> 
> Thanks for the BndPomRepository news, any specific release day for 3.3? I 
> couldn't find anything on the BndTool page. I am looking forward to it. I 
> think this is one area that will speed up OSGi development drastically.
> 
> 
> Cheers
> 
> -Daghan 
> 
> 
> 
> From: osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> on 
> behalf of Peter Kriens <peter.kri...@aqute.biz>
> Sent: Monday, September 5, 2016 6:35 AM
> To: OSGi Developer Mail List
> Subject: Re: [osgi-dev] Bundle resolution in BND
>  
>> On 4 sep. 2016, at 06:47, Daghan ACAY <daghana...@hotmail.com 
>> <mailto:daghana...@hotmail.com>> wrote:
>> Hi Peter,
>> I sent a long reply before but I think it was lost in the cracks of 
>> internet. 
> Must have missed it … sorry.
> 
>> As for your first comment, even if I publish my artefacts to Nexus, I need 
>> to use local index file to aid the bundle resolution. I am happy to do that 
>> for the dependencies of my code but doing it for the transient dependencies 
>> are bit labour-some. Until now I had to create a local index file (via drag 
>> and drop) for artefacts in JPM4J or MVN central. Is it possibly to run 
>> resolution directly on local or global nexus (without manually preparing the 
>> local index)? BTW I found out index file is embedded into “FixedIndexedRepo" 
>> so you dont need to create the index manually.
> In bnd(tools) 3.3 we hqve the BndPomRepository, this will allow you to 
> maintain your index in a Maven pom, including its transitive dependencies.
> 
>> As for your second comment, my problem is what happens if the service API's 
>> are dependent on other service API's. This is especially true if your 
>> bundle/jar depends on external jars. Even though the service API that you 
>> rely on is very specific it might bring in a lot of third party in 
>> implementation and there is not much you can do about it when you are using 
>> third party API's. Shallow dependencies can only happen if the API 
>> implementation is self contained, e.g. includes all third part jars into its 
>> bundle, which I believe is not good for modularity and licencing issues. Can 
>> you give me a sufficiently large example that they manage footprint small 
>> and avoid external dependencies?
> This is the tension between the model the OSGi Alliance has been promoting 
> and the state of the industry. All OSGi APIs are available as API JARs and 
> multiple implementations. Unfortunately, trying to get the JARs from JCP JARs 
> can be quite tricky. Also, it turns out that the rigor that the OSGi Alliance 
> applies to the specification process is too rarely applied in other 
> specification groups. 
> 
> It is one of the reasons I sometimes create bundles where there do exist 
> popular open source implementations. There is transitive dependencies are so 
> horrid and a clean service based implementation is so small that it sometimes 
> makes the balance point to make instead of get for free. A lot of work in 
> OSGi enRoute was to show how simple a service implementation can be and how 
> powerful OSGi is when you can compose your software out of small components 
> that have well defined interfaces. 
> 
> 
>> I don't want to start a philosophical discussion, just a practical one. I 
>> guess my problem is the local index files for external repositories and how 
>> to manage/share them between multiple developers. I can think of some 
>> solutions: 
>> 1- May be we can put a cnf in git repo and make BntTool to fetch from the 
>> git repo as a workspace template? Will this work if the template is 
>> continuously changing?
>> 2- Create FixedRepo (they embed the index) to deploy releases and distribute 
>> the repo URLS? can more than one developer push to same FixedRepo? How we 
>> manage the history of the repo?
> 
>> do you have other solutions, particularly that will work in open source 
>> development? I mean other developers can use the artifacts that I create 
>> (from some repo) and do not worry about the transient depencies in their 
>> workspace during resolution?
> Again, I think the way forward for bnd(tools) is to leverage the pom format. 
> This will make it trivial to share between open source projects.
> 
> 
> Kind regards,
> 
> Peter Kriens
>> 
>> Help is highly appreciated.
>> 
>> Cheers
>> -Daghan
>> 
>> 
>> From: osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org> 
>> <osgi-dev-boun...@mail.osgi.org <mailto:osgi-dev-boun...@mail.osgi.org>> on 
>> behalf of Peter Kriens <peter.kri...@aqute.biz 
>> <mailto:peter.kri...@aqute.biz>>
>> Sent: Wednesday, August 31, 2016 4:42 PM
>> To: OSGi Developer Mail List
>> Subject: Re: [osgi-dev] Bundle resolution in BND
>>  
>> Your workspaces should publish to a repository (e.g. Nexus) and then consume 
>> from those repositories. The resolver takes a root bundle (in OSGi enRoute 
>> the application) and then finds a closure of all bundles from the enlisted 
>> repositories that have no remaining requirements. So in contrast to maven, 
>> all bundles are put in a melting pot and then selected from.
>> 
>> If you have systems that have deep transitive dependencies then you’re just 
>> not working very modular. The core idea of OSGi is to create bundles that 
>> implement a number of service APIs and use a number of service APIs. So 
>> their dependencies is solely those service APIs and maybe a few standalone 
>> implementation libraries. If you see other patterns you either adapt to 
>> minimize those dependencies or use Maven, a tool that is wonderful with 
>> deep, very deep, transitive dependencies.
>> 
>> The core idea of OSGi is that the bucket stops at the service boundary.
>> 
>> Kind regards,
>> 
>> Peter Kriens
>> 
>>> On 31 aug. 2016, at 13:31, Daghan ACAY <daghana...@hotmail.com 
>>> <mailto:daghana...@hotmail.com>> wrote:
>>> 
>>> Hi there,
>>> 
>>> I was working on understanding bundle resolution and workspaces in BND and 
>>> enRoute. Here is my simplified set up:
>>> 
>>> workspace 1 two projects
>>> ProjectA.api
>>> ProjectB.provider (this depends on Bundle1 and Bundle2)
>>> 
>>> I resolve Project B using central maven repository. And release Both 
>>> ProjectA and ProjectB to "Release"
>>> 
>>> Workspace 2 one project. This workspace has reference to "Release" 
>>> directory of the workspace 1 hence can see ProjectA and ProjectB. However, 
>>> this workspace does not have the Central repository pointing to Bundle1 and 
>>> Bundle2 above. Project in workspace 2 is called
>>> 
>>> ProjectC.provider (this depends on ProjectA.api)
>>> 
>>> Here is my question . When I try to resolve Project C, resolution fails 
>>> saying
>>> "Project C  cannot be resolved because ProjectB cannot be resolved because 
>>> it needs Bundle1."
>>> 
>>> Why should I have dependencies of my dependencies in my second workplace? 
>>> Isn't it against resolution process? I mean if you have multiple 
>>> dependencies then do you need to go and find every single one of the 
>>> transient dependencies in your current local repositories. This can be 
>>> exponentially big. Should not resolution find the dependencies even though 
>>> they are not on your local repositories? I know I am going in the territory 
>>> of MVN but I really thing there must be a simpler way. Similar to 
>>> "provided" in MVN may be? or a global, I mean literally global "cnf"?
>>> 
>>> I also tried to export the dependencies of ProjectB.provider from 
>>> ProjectB.provider to aid the resolution in Workspace2 but this does not 
>>> seem right either in terms of the size of ProjectB or conventions of OSGi. 
>>> So can you please tell me how can one use external bundle and resolve 
>>> without knowing the transient dependencies? IF this cannot be done than how 
>>> should one proceed to organise their workspaces while collaborating with 
>>> others?
>>> 
>>> Sorry for the long message but I wanted to be as clear as possible.
>>> 
>>> Regards
>>> -Daghan
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev 
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to