> I guess what I am trying to understand now is the use of -buildrepo.
- I haven’t used this yet, only going off what Peter had told us earlier
- But I would suspect it goes in the cnf/build.bnd file

Just to clarify my proposed solution… would likely work only if the following 
were true:
- You define your cnf/release repositories as 
‘aQute.bnd.repository.maven.pom.provider.BndPomRepository’
- The ‘-buildrepo’ command builds to ‘cnf/release’ as part of the build process
- You use the trick of defining cnf/release directories as repositories, as 
outlined in my original post

I’m not offering guarantees the solution would work, but seems likely if the 
above conditions are true

Randy



> On Feb 20, 2017, at 3:06 AM, Daghan ACAY <daghana...@hotmail.com> wrote:
> 
> Hi Randy,
> 
> I guess what I am trying to understand now is the use of -buildrepo.
> 
> Can you tell me in which file you have defined it? also where did you see the 
> output e.g. folder, file. If what I understand this correct than we do not 
> need a separate pom.xml files for each project in the workspace, which in 
> itself is a huge win. 
> 
> I believe for now I will give up hope on replacing nexus <OutlookEmoji-😊.png>
> 
> 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 Randy Leonard <randy.leonard....@gmail.com 
> <mailto:randy.leonard....@gmail.com>>
> Sent: Monday, February 20, 2017 9:52 AM
> To: OSGi Developer Mail List
> Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
>  
> > You can set a -buildrepo.
> Thx, very helpful
> 
> > If you use local maven builds then I do not need to include the transient 
> > repositories
> Correct
> 
> > If you use local maven builds…
> I use both maven and gradle builds.  
> - Gradle builds everything, and my OSGi workspaces refer to each other’s 
> cnf/release repository to resolve dependencies (in an acyclic manner, of 
> course)
> - Maven only builds a small subset of cxf-based client bundles and pushes to 
> .m2 (or other) repository for use within Liferay
> 
> 
> > Basically the question is how can I get rid of 
> > https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml
> >  
> > <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml>
> >  
> com.easyiot.application/central.xml at master · 
> daghanacay/com.easyiot.application · GitHub 
> <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml>
> github.com <http://github.com/>
> Contribute to com.easyiot.application development by creating an account on 
> GitHub.
> 
> > using a combination of rawgithub, bnd repositories and without an external 
> > nexus server.
> - It seems you want maven to substitute m2/Nexus with rawgithub
> - I don’t have any experience with rawgithub, but would suspect this would be 
> challenging
> 
> I suspect a better way is to omit rawgithub from the build process, just push 
> your artifacts there post-build.  Instead:
> - Specify ‘-buildrepo’ as suggested by Peter.  This would ensure ensure 
> bundles are built to both the project’s target and workspace cnf/release 
> directories
> - Use the ‘-plugin…’ trick I had provided earlier so that your ‘cnf/release’ 
> directories are treated as repositories
> - After the build completes, push the bundles from your various ‘cnf/release’ 
> directories to rawgithub.
> 
> I suspect this will work, but haven’t tried this exact setup…
> 
> Randy
> 
> 
> 
>> On Feb 20, 2017, at 2:06 AM, Peter Kriens <peter.kri...@aqute.biz 
>> <mailto:peter.kri...@aqute.biz>> wrote:
>> 
>> There is an undocumented feature in Bnd that might be useful here. You can 
>> set a -buildrepo. Any project that is build will automatically release to 
>> all the listed repositories in -buildrepo property.
>> 
>> Kind regards,
>> 
>> Peter Kriens
>> 
>>> On 20 Feb 2017, at 09:52, Daghan ACAY <daghana...@hotmail.com 
>>> <mailto:daghana...@hotmail.com>> wrote:
>>> 
>>> Hi Randy,
>>> 
>>> I think I am doing the same thing but through github
>>> 
>>> -plugin.3.easyiot.core = \
>>>         aQute.bnd.deployer.repository.FixedIndexedRepo; \
>>>         name =       EasyIot-Core; \
>>>         locations =       
>>> https://raw.githubusercontent.com/daghanacay/com.easyiot.core/master/cnf/release/index.xml
>>>  
>>> <https://raw.githubusercontent.com/daghanacay/com.easyiot.core/master/cnf/release/index.xml>
>>> One difference I see is that, after I do "./gradlew release" on the local 
>>> machine I push release folder (with released jar files) to github as well 
>>> as the code. This helps others to use the released jars with the above 
>>> FixedIndexRepository definition in their bnd workspace. 
>>> 
>>> What I am trying to solve is the transient dependencies. I have this file 
>>> in application workspace 
>>> https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/EasyCoreMaven.xml
>>>  
>>> <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/EasyCoreMaven.xml>
>>>  which defines the projects in core workspace. Projects in core workspace 
>>> have this dependencies 
>>> https://github.com/daghanacay/com.easyiot.core/blob/master/cnf/central.xml 
>>> <https://github.com/daghanacay/com.easyiot.core/blob/master/cnf/central.xml>.
>>>  problem is the first mvn (EasyCoreMaven.xml) file does not calculate the 
>>> transient dependencies defined in "central.mvn" and I have to include all 
>>> the transient dependencies in all the other workspaces (there are two more) 
>>> into application workspace central.xml file to make the runtime resolution 
>>> to work, e.g. 
>>> https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml
>>>  
>>> <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml>.
>>>  FYI build will work even if I do not create 
>>> https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml
>>>  
>>> <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml>
>>>  but the exported executable will not work due to missing transient 
>>> dependencies.
>>> 
>>> If you use local maven builds then I do not need to include the transient 
>>> repositories to 
>>> https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml
>>>  
>>> <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml>
>>>  since they resolve through local .m2. However .m2 is not available in 
>>> Travis and I do not want to push mvn artefacts to a nexus server.
>>> 
>>> Basically the question is how can I get rid of 
>>> https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml
>>>  
>>> <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml>
>>>  using a combination of rawgithub, bnd repositories and without an external 
>>> nexus server.
>>> 
>>> I hope this is a cleaner version of the original question.
>>> 
>>> Regards
>>> -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 Daghan ACAY 
>>> <daghana...@hotmail.com <mailto:daghana...@hotmail.com>>
>>> Sent: Monday, February 20, 2017 1:09 AM
>>> To: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
>>>  
>>> Thanks Randy,
>>> I will try this as soon as i go home and let you know the outcome. 
>>> Cheers
>>> Daghan
>>> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your 
>>> emails as clean, short chats.
>>> 
>>> 
>>> -------- Original Message --------
>>> From: Randy Leonard <randy.leonard....@gmail.com 
>>> <mailto:randy.leonard....@gmail.com>>
>>> Sent: Monday, February 20, 2017 08:46 AM
>>> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org 
>>> <mailto:osgi-dev@mail.osgi.org>>
>>> Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
>>> 
>>> Daghan:
>>> 
>>> I understand your problem as having OSGi enRoute workspaces share bundles 
>>> without having to commit to continuous integration.
>>> 
>>> For this, I add the following to cnf/build.bnd within each workspace:
>>> 
>>> -plugin.71.Foundation: \
>>>         aQute.bnd.deployer.repository.LocalIndexedRepo; \
>>>             name                =       Local-Foundation ; \
>>>             pretty              =       true ; \
>>>             local               =       
>>> /Users/randy/projects/MyProject/src/git/com.xyz.foundation/cnf/release
>>> 
>>> -plugin.72.MasterData: \
>>>         aQute.bnd.deployer.repository.LocalIndexedRepo; \
>>>             name                =       Local-MasterData ; \
>>>             pretty              =       true ; \
>>>             local               =       
>>> /Users/randy/projects/MyProject/src/git/com.xyz.masterdata/cnf/release
>>> 
>>> -plugin.73.Batch: \
>>>         aQute.bnd.deployer.repository.LocalIndexedRepo; \
>>>             name                =       Local-Batch ; \
>>>             pretty              =       true ; \
>>>             local               =       
>>> /Users/randy/projects/MyProject/src/git/com.xyz.batch/cnf/release
>>> 
>>> -plugin.74.Finance: \
>>>         aQute.bnd.deployer.repository.LocalIndexedRepo; \
>>>             name                =       Local-Finance ; \
>>>             pretty              =       true ; \
>>>             local               =       
>>> /Users/randy/projects/MyProject/src/git/com.xyz.finance/cnf/release
>>> 
>>> 
>>> 
>>> After doing so, my list of repositories within the workspace is extended to 
>>> include not just Central, Local, Release, and Distro… but each of the 
>>> workspaces as referenced above.
>>> 
>>> You can then make bundles available to other workspaces by updating the 
>>> contents of each project’s cnf/release folder… which is done by executing 
>>> './gradlew release’ within each workspace directory.
>>> 
>>> Note my plugins above are still using an absolute pathname to each 
>>> workspace’s cnf/release directory.  I will be updating soon to reference 
>>> environment variables.
>>> 
>>> 
>>> Let me know if I have understood your problem correctly, and if I haven’t 
>>> been clear on any of the above.
>>> 
>>> Thanks,
>>> Randy
>>> 
>>> 
>>> 
>>>> On Feb 19, 2017, at 2:24 PM, Daghan ACAY <daghana...@hotmail.com 
>>>> <mailto:daghana...@hotmail.com>> wrote:
>>>> 
>>>> Hi Andy,
>>>> I guess i followed your strategy please see 
>>>> https://mail.osgi.org/pipermail/osgi-dev/2017-February/006135.html 
>>>> <https://mail.osgi.org/pipermail/osgi-dev/2017-February/006135.html>
>>>> My problem is now sharing artefacts without using Nexus. Are you deploying 
>>>> your artefacts to nexus during maven build? If not how do you deal with 
>>>> transient dependencies needed for resolution process.
>>>> PS i solved it by putting it all transient dependencies to central.xml 
>>>> file in all workspaces but this is duplication and maintenance headache.
>>>> Regards
>>>> Daghan
>>>> Sent by MailWise <http://www.mail-wise.com/installation/2> – See your 
>>>> emails as clean, short chats.
>>>> 
>>>> 
>>>> -------- Original Message --------
>>>> From: Randy Leonard <randy.leonard....@gmail.com 
>>>> <mailto:randy.leonard....@gmail.com>>
>>>> Sent: Sunday, February 19, 2017 05:47 AM
>>>> To: osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>>> Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
>>>> 
>>>> To all:
>>>> 
>>>> This was actually quite easy to do.
>>>>  - Follow the instructions here: 
>>>> http://enroute.osgi.org/tutorial_eval/050-start.html 
>>>> <http://enroute.osgi.org/tutorial_eval/050-start.html>
>>>>  - But with one caveat… create bnd projects, *not maven projects*.  Then 
>>>> manually insert your pom.xml files into your bnd projects.
>>>> 
>>>> Once this is done, you get the hot-replacement provided by bnd during 
>>>> bundle development and can still use ‘mvn clean install’ to deploy to your 
>>>> m2 repository.
>>>> 
>>>> The only caveat is you will need to synchronize dependencies in both 
>>>> bnd.bnd and pom.xml files.  But for our situation, only using maven for 
>>>> apache cxf client stubs… so pretty straightforward stuff.
>>>> 
>>>> We now have a number of OSGi enRoute workspaces which provide services to 
>>>> each other and Liferay portal workspaces.  Modifications to one workspace 
>>>> are immediately available in all other enRoute workspaces, and almost 
>>>> immediately within Liferay workspaces.  We only submit to continuous 
>>>> integration after changes spanning all workspaces are proven to be correct 
>>>> in the development environment.
>>>> 
>>>> Let me know if there is interest in how we have done this, and I can set 
>>>> up a git repository showing how this all works.
>>>> 
>>>> Randy
>>>> 
>>>> ———
>>>> 
>>>> >> leveraged aQute.bnd.deployer.repository.LocalIndexedRepo within 
>>>> >> Liferay7 ..."
>>>> > Can you expand on what this means please? A use-case would be good.
>>>> Gradle works with several types of repositories, as listed here:
>>>>   - 
>>>> https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories
>>>>  
>>>> <https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories>
>>>>  
>>>> <https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories
>>>>  
>>>> <https://docs.gradle.org/current/userguide/dependency_management.html#sec:repositories>>
>>>> 
>>>> But the default repository type used by enRoute is not listed in the above 
>>>> link, and is instead defined by an enRoute/aQute plugin:
>>>>  - aQute.bnd.deployer.repository.LocalIndexedRepo
>>>> 
>>>> 
>>>> What this means:
>>>>   - Liferay does not natively support enRoute repositories unless it can 
>>>> be configured to import the aQute gradle plugin.
>>>> 
>>>> 
>>>> Ultimately, the issue is finding a repository scheme that both enRoute and 
>>>> Liferay can agree upon.  Seems there are three options:
>>>> 1. Use Maven to build enRoute projects… ugh (dual build systems to 
>>>> synchronize, or lose hot-replacement offered by gradle-build approach)
>>>> 2. Get Liferay to understand enRoute’s default repository type of 
>>>> LocalIndexedRepo
>>>> 3. Get enRoute to generate Ivy repositories, as I believe Liferay will 
>>>> work with those just fine
>>>> 
>>>> 
>>>> Option 2 approach:
>>>>   - enRoute obtains LocalIndexedRepo support by importing aQute libraries 
>>>> at the start of the build.gradle file, and I could presumably do the same 
>>>> with Liferay projects
>>>>   - But I would still need to define the LocalIndexedRepo repositories 
>>>> somewhere, and further define dependencies via BSN notation?
>>>> 
>>>> Option 3 approach:
>>>>   - Modify build enRoute scripts and build.bnd files to leverage Ivy 
>>>> repositories
>>>>   - Register Ivy repositories and dependencies in Liferay’s build.gradle 
>>>> file
>>>> 
>>>> 
>>>> Hope I have made things more clear?  Your thoughts?
>>>> 
>>>> Randy
>>>> 
>>>> _______________________________________________
>>>> 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 <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

Reply via email to