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 <[email protected]> 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: [email protected] <[email protected]> on
> behalf of Daghan ACAY <[email protected]>
> Sent: Monday, February 20, 2017 1:09 AM
> To: [email protected]
> 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 <[email protected]>
> Sent: Monday, February 20, 2017 08:46 AM
> To: OSGi Developer Mail List <[email protected]>
> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>>
>> Sent: Sunday, February 19, 2017 05:47 AM
>> To: [email protected] <mailto:[email protected]>
>> 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
>> [email protected] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
