Home » Eclipse Projects » Virgo » Maven - compiling against Equinox in Virgo 3.6.2.RELEASE(Using Maven as standalone (e.g. automated build) to build bundles for a Virgo target.)
Maven - compiling against Equinox in Virgo 3.6.2.RELEASE [message #1142864] |
Thu, 17 October 2013 22:31 |
Douglas Beattie Messages: 6 Registered: October 2013 |
Junior Member |
|
|
I'm using a standalone Maven project, and trying to declare dependencies for
the specific versions of Eclipse components distributed as the 'release'
version of Eclipse Virgo. However, I was not able to locate the exact
versions of the bundles in any public Maven repository. By inspecting the
META-INF/MANIFEST.MF of the include components, I was able to verify
the exact versions, and also conclude there is a consistent naming convention
which seems to be always {bundle-symbolic-name}_{bundle-version}. So, to
produce a standalone Maven project which can be built by a continuous-integration
tool or validated from scratch on a newly-provisioned build machine (without
the presence or necessity to manually load/compile a project from within
the Eclipse IDE), I arrived at some definitions which would build the project,
assuming the presence and availability of the required versions of dependency
artifacts from Equinox.
For example, here are the relevant definitions from the top-level POM file:
<properties>
<equinox.framework.version>3.8.1.v20120830-144521</equinox.framework.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.tycho</groupId>
<artifactId>org.eclipse.osgi</artifactId>
<version>${equinox.framework.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.equinox</groupId>
<artifactId>org.eclipse.equinox.cm</artifactId>
<version>1.0.400.v20120319-2029</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.eclipse.osgi</groupId>
<artifactId>org.eclipse.osgi.services</artifactId>
<version>3.3.0.v20120307-2102</version>
<scope>provided</scope>
</dependency>
...
For example, looking at the 3rd dependency, installed as
virgo-tomcat-server-3.6.2.RELEASE/plugins/org.eclipse.osgi.services_3.3.0.v20120307-2102.jar
the dependency declaration is based on the contents of that POM file t the head of the source tree.
$ curl -s http://git.eclipse.org/c/equinox/rt.equinox.framework.git/plain/bundles/org.eclipse.osgi.services/pom.xml \
| tail -n5 | egrep "<groupId>|<artifactId>|<version>"
<groupId>org.eclipse.osgi</groupId>
<artifactId>org.eclipse.osgi.services</artifactId>
<version>3.4.0-SNAPSHOT</version>
Substituting the version number for our particular Bundle, which was provided in this release of Virgo:
<version>3.3.0.v20120307-2102</version>
So, given these politically correct dependency declarations, the build will fail
because these specific versions are not available in a public repository. So, my
solution was to include the unpacking of a copy of Eclipse Virgo 3.6.2.RELEASE
on the build machine, at location '/opt/virgo-tomcat-server-3.6.2.RELEASE/',
and then manually add these dependencies to the machine-local Maven repository:
$ EXTJAR=/opt/virgo-tomcat-server-3.6.2.RELEASE/plugins/org.eclipse.osgi.services_3.3.0.v20120307-2102.jar
$ mvn install:install-file -Dfile=${EXTJAR} \
-DgroupId=org.eclipse.osgi \
-DartifactId=org.eclipse.osgi.services \
-Dversion=3.3.0.v20120307-2102 \
-Dpackaging=jar
Doing this for all Virgo components I wish to compile against (during development
of Virgo-specific bundles) produces a working standalone Maven build environment,
and I'm off and running.
So, my question now: is there a simpler or "better" way to achieve this?
. . .
Douglas Beattie
www.linkedin.com/in/beattidp
[Updated on: Tue, 29 October 2013 04:21] Report message to a moderator
|
|
| | | |
Re: Maven - compiling against Equinox in Virgo 3.6.2.RELEASE [message #1151212 is a reply to message #1149073] |
Wed, 23 October 2013 07:37 |
GianMaria Romanato Messages: 72 Registered: July 2009 |
Member |
|
|
Douglas Beattie wrote on Mon, 21 October 2013 19:11
This question is more of a build-time problem, as there seems to be limited means to compile against certain Equinox dependencies during a Maven-based build, outside of a manually-tended Eclipse IDE.
I was in fact referring to build-time. I suppose there is a misunderstanding, maybe originated by the fact that Virgo contains a p2 directory.
The p2 directory included in Virgo is used for provisioning Virgo itself which, as you know, comes in different flavours (Virgo Nano, Virgo Server for Apache Tomcat, etc), each of them obtained by installing via p2 additional optional components on top of the most basic distribution.
Since you were talking about Equinox bundles, I assumed that you are developing an OSGi application and that you use Virgo Server for Apache Tomcat. Since you cited Maven, I also assumed that you are using Maven/Tycho for building your application. Now, if all of the above assumptions hold, I confirm you can create a p2 repository used by Maven/Tycho to look-up you OSGi bundles dependencies (i.e. the dependencies declared in the MANIFEST as Import-Package or Require-Bundle). The repository should contain at the third-party bundles your application depends upon and typically also some or all of the bundles that Virgo makes visible to your application, which means the content of the Virgo repository folder and possibly also the Virgo plugins folder.
In this way, whenever Tycho is about to compile a bundle of yours, it will be able to compose the correct classpath by picking appropriate binary bundles from the p2 repository.
GianMaria.
Developing for Virgo using PDE: http://bit.ly/1w0tTit
Global JNDI in Virgo: http://bit.ly/1to42mn
Hyperic to monitor Virgo: http://bit.ly/W1Fst9
Profile Virgo with JProfiler http://bit.ly/1FBLGCw
|
|
| |
Re: Maven - compiling against Equinox in Virgo 3.6.2.RELEASE [message #1160327 is a reply to message #1159603] |
Tue, 29 October 2013 04:17 |
Douglas Beattie Messages: 6 Registered: October 2013 |
Junior Member |
|
|
Just to confirm: my project utilizes only the 'maven-bundle-plugin'. I do not use Tycho plugins, nor have I evaluated them in depth, as they appeared to be less stable, with limited documentation, and still seem to be evolving; nor do I use the bundlor, since it seemed less-capable than the maven-bundle-plugin.
The basic declaration is in my top-level POM (which is of packaging type 'pom', and serves as the parent for 7 modules so far).
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>${maven.bundle.plugin.version}</version>
<extensions>true</extensions>
<configuration>
<obrRepository>obr/repository.xml</obrRepository>
<instructions>
<Bundle-SymbolicName>${project.groupId}.${project.artifactId}</Bundle-SymbolicName>
<Bundle-Name>${project.name}</Bundle-Name>
<Bundle-Version>${project.version}</Bundle-Version>
<Bundle-ClassPath>.</Bundle-ClassPath>
<Export-Package>
${project.groupId}.${project.artifactId}
</Export-Package>
</instructions>
</configuration>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
<configuration>
<manifestLocation>src/main/resources/META-INF/</manifestLocation>
</configuration>
</execution>
</executions>
</plugin>
All modules inherit the baseline plugin configuration, and can further tune or override the declarations given under 'pluginManagement' in the parent POM. A module can then simply declare something as simple as:
<build>
<plugins>
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<!-- version managed by parent POM -->
</plugin>
</plugins>
In practice, this is working pretty well for me, with the bundle manifests containing plenty of versioned imports which correspond to each module's declared dependency versions.
And yes, the target is Virgo Server for Apache Tomcat. It has been fun so far, and useful to follow the logs, check the status of bundles and resources, and even adjust log levels on the fly for troubleshooting and verification purposes. My manager was pretty impressed as well.
. . .
Douglas Beattie
www.linkedin.com/in/beattidp
[Updated on: Tue, 29 October 2013 04:22] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Thu Mar 28 08:58:03 GMT 2024
Powered by FUDForum. Page generated in 0.02869 seconds
|