Just to closet this thread,
This is what I have done.
I created new repository and set the -buildrepo to this repository. I added the
following cnf/ext/enroute.bnd
-plugin.maven \
aQute.bnd.repository.maven.provider.MavenBndRepository; \
name=Local
-buildrepo: Local
This has replaced the
-plugin.6.Local: \
aQute.bnd.deployer.repository.LocalIndexedRepo; \
name = Local ; \
pretty = true ; \
local = ${build}/local
I can see "Local" in Eclipse Repositories view in BNDtools. In the repository
view "Local" is created and it shows all the projects in the currnet workspace.
however ~/.m2/repositories folder does not have any of the jar files. Other
workspaces cannot refer to the project artefacts through .m2
@Randy I have also tried
-plugin.maven \
aQute.bnd.repository.maven.provider.BndPomRepository; \
name=Local
-buildrepo: Local
Unfortunately it did not work for me. I will continue to search until I find a
solution.
Thanks for all the help
-Daghan
________________________________
From: [email protected] <[email protected]> on behalf
of Daghan ACAY <[email protected]>
Sent: Monday, February 20, 2017 11:03 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
Thanks Randy,
I will look into this tomorrow (it is bit late now in Australia:) and let you
know. If I can drop the pom.xml files in each project then you might be able to
use it as well.
Cheers
-Daghan
________________________________
From: [email protected] <[email protected]> on behalf
of Randy Leonard <[email protected]>
Sent: Monday, February 20, 2017 10:33 AM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Accessing LocalIndexedRepo from Liferay 7 project
> 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
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> on
behalf of Randy Leonard
<[email protected]<mailto:[email protected]>>
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
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
<[email protected]<mailto:[email protected]>> 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
<[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
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
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.
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.
FYI build will work even if I do not create
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
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
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
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
- 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>
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]<mailto:[email protected]>
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
_______________________________________________
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
