Stefano Lenzi wrote:
Damien Lecan wrote:
You have to override compiler bootclasspath to use foundation ee jar
and add this jar as plugin dependency.
I'm really interested in that point, but the biggest problem to fix in
order to implement such solution is:
how-to allow everyone to have the needed bootclasspath artifact for
compiling the source.
I was not clear enough.
Here is an example to put your pom :
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.3</source> <!-- Whatever you want -->
<target>1.3</target> <!-- Whatever you want -->
<compilerArguments>
<bootclasspath>${settings.localRepository}/org/osgi/ee/1.0/foundation-1.0.jar</bootclasspath>
</compilerArguments>
</configuration>
<dependencies>
<dependency>
<groupId>org.osgi.ee</groupId>
<artifactId>foundation</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
</plugin>
...
The main tip is to use dependency inside the plugin definition and to
use ${settings.localRepository} variable.
That's a nice tip :)
Of course, ee jars must be available somewhere in a Maven repository :)
That's it could be a nightmare, because I don't know if there are some
IP issue to put such foundation-1.0.0.jar (or JRE jars) on a public
Maven2 repo :S
We have foundation stubs in our repo already. OSGi Alliance makes stubs
available under Apache license, so I don't see this as an issue.
-> richard
I am already using this to compile my OSGi applications against J2ME
classes profiles and it works perfectly.
If there is no IP issue I'll be glad to apply the same solution on
Felix :)
Damien Lecan
