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] <[email protected]> on behalf
of Daghan ACAY <[email protected]>
Sent: Monday, February 20, 2017 1:09 AM
To: [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]>
Sent: Monday, February 20, 2017 08:46 AM
To: OSGi Developer Mail List <[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]
https://mail.osgi.org/mailman/listinfo/osgi-dev
