> I guess what I am trying to understand now is the use of -buildrepo. - I haven’t used this yet, only going off what Peter had told us earlier - But I would suspect it goes in the cnf/build.bnd file
Just to clarify my proposed solution… would likely work only if the following were true: - You define your cnf/release repositories as ‘aQute.bnd.repository.maven.pom.provider.BndPomRepository’ - The ‘-buildrepo’ command builds to ‘cnf/release’ as part of the build process - You use the trick of defining cnf/release directories as repositories, as outlined in my original post I’m not offering guarantees the solution would work, but seems likely if the above conditions are true Randy > On Feb 20, 2017, at 3:06 AM, Daghan ACAY <daghana...@hotmail.com> wrote: > > Hi Randy, > > I guess what I am trying to understand now is the use of -buildrepo. > > Can you tell me in which file you have defined it? also where did you see the > output e.g. folder, file. If what I understand this correct than we do not > need a separate pom.xml files for each project in the workspace, which in > itself is a huge win. > > I believe for now I will give up hope on replacing nexus <OutlookEmoji-😊.png> > > Cheers > -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 Randy Leonard <randy.leonard....@gmail.com > <mailto:randy.leonard....@gmail.com>> > Sent: Monday, February 20, 2017 9:52 AM > To: OSGi Developer Mail List > Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project > > > 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 > > > > <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml> > > > com.easyiot.application/central.xml at master · > daghanacay/com.easyiot.application · GitHub > <https://github.com/daghanacay/com.easyiot.application/blob/master/cnf/central.xml> > github.com <http://github.com/> > Contribute to com.easyiot.application development by creating an account on > GitHub. > > > 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 >> <mailto: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 <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