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 <daghana...@hotmail.com> 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: osgi-dev-boun...@mail.osgi.org <osgi-dev-boun...@mail.osgi.org> on > behalf of Peter Kriens <peter.kri...@aqute.biz> > 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 <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 https://mail.osgi.org/mailman/listinfo/osgi-dev