> You can set a -buildrepo. Thx, very helpful > If you use local maven builds then I do not need to include the transient > repositories Correct
> If you use local maven builds… I use both maven and gradle builds. - Gradle builds everything, and my OSGi workspaces refer to each other’s cnf/release repository to resolve dependencies (in an acyclic manner, of course) - Maven only builds a small subset of cxf-based client bundles and pushes to .m2 (or other) repository for use within Liferay > Basically the question is how can I get rid of > 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. - It seems you want maven to substitute m2/Nexus with rawgithub - I don’t have any experience with rawgithub, but would suspect this would be challenging I suspect a better way is to omit rawgithub from the build process, just push your artifacts there post-build. Instead: - Specify ‘-buildrepo’ as suggested by Peter. This would ensure ensure bundles are built to both the project’s target and workspace cnf/release directories - Use the ‘-plugin…’ trick I had provided earlier so that your ‘cnf/release’ directories are treated as repositories - After the build completes, push the bundles from your various ‘cnf/release’ directories to rawgithub. I suspect this will work, but haven’t tried this exact setup… Randy > On Feb 20, 2017, at 2:06 AM, Peter Kriens <peter.kri...@aqute.biz> wrote: > > 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 > 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
