Look in ~/.m2/repository … The name of the MavenBndRepository does not reflect
the folder, without release and snapshot urls it just reverts to the maven
local repo.
However, the intention of -buildrepo is not to use it from Gradle. The
intention was that if you build in Eclipse you automatically get a release in
the local maven repo so you can use it from other workspaces without a release
step.
Kind regards,
Peter Kriens
> On 20 Feb 2017, at 10:22, Daghan ACAY <[email protected]> wrote:
>
> Hi Peter,
>
> I found http://bnd.bndtools.org/instructions/buildrepo.html
> <http://bnd.bndtools.org/instructions/buildrepo.html>
>
> I added to the following cnf/build.bnd file
>
> -plugin.maven \
> aQute.bnd.repository.maven.provider.MavenBndRepository; \
> name=LocalMvnTest
> -buildrepo: LocalMvnTest
>
> I ran "./gradlew release" and I cannot see folder LocalMvnTest folder
> anywhere. am I doing something wrong?
>
> Cheers
> -Daghan
> From: [email protected] <[email protected]> on
> behalf of Peter Kriens <[email protected]>
> Sent: Monday, February 20, 2017 9:06 AM
> To: OSGi Developer Mail List
> Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
>
> 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]
>> <mailto:[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] <mailto:[email protected]>
>> <[email protected] <mailto:[email protected]>> on
>> behalf of Daghan ACAY <[email protected]
>> <mailto:[email protected]>>
>> Sent: Monday, February 20, 2017 1:09 AM
>> To: [email protected] <mailto:[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]
>> <mailto:[email protected]>>
>> Sent: Monday, February 20, 2017 08:46 AM
>> To: OSGi Developer Mail List <[email protected]
>> <mailto:[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
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>> _______________________________________________
>> OSGi Developer Mail List
>> [email protected] <mailto:[email protected]>
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
> _______________________________________________
> OSGi Developer Mail List
> [email protected] <mailto:[email protected]>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
