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> Sent: Monday, February 20, 2017 08:46 AM To: OSGi Developer Mail List <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 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 - 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> 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
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
