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> 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>
> Sent: Sunday, February 19, 2017 05:47 AM
> To: 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
> 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
