[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [pde-build-dev] Update on Mavenizing Eclipse Builds
|
Thanks for the reply. I will look into how this works. As my lovely but cruel taskmaster had me painting the bathroom this weekend I thought about what would work and I have come up with the following. Comments embedded in the pom file detail how things should flow and work.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="
http://maven.apache.org/POM/4.0.0"
xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
">
<modelVersion>4.0.0</modelVersion>
<!--
A plugin, feature, fragment, etc could include the groupId in the manifest as an
extra entry. This would allow the code to derive most information like the
groupId, artifactId (Bundle-SymbolicName), and version (Bundle-Version) from
the Manifest.mf file. Also the plugin could be provided with a list of
groupIds to artifactId regular expresions.
Ex:
# GroupID : ArtifactId Regular Expresion
com.mycompany.foo: com.com.mycompany.bar
org.eclipse.wtp.plugins: org.eclipse.wtp.*
org.eclipse.plugins: org.eclipse.*
-->
<groupId>com.mycompany.foo
</groupId>
<artifactId>com.mycompany.foo.helloworld</artifactId>
<!--
Might need to create a maven plugin specific packaging. The current jar
packaging works fine for now but for issues down the road or for increased
flexibility this might be required. Luckily not as big a deal as other issues.
-->
<packaging>jar</packaging>
<version>1.8.1-SNAPSHOT</version>
<name>Hello World Example</name>
<build>
<plugins>
<!--
This plugin, which doesn't exist yet, would find all jars in the
repository under the respective groupIds that matched the version range,
if present or the lastest jar if not present. These jars would then be
passed to the eclipse classpath analyzer code to determine which jars are
really needed for compilation. The resulting jars would then be converted
to maven Dependencies and added to the project for later using during
compilation. The access rules would also be written out to a location
that the eclipse compiler could later read them in from.
-->
<plugin>
<groupId>org.eclipse.pde.maven.plugins
</groupId>
<artifactId>maven-pde-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>generate-dependencies</id>
<phase>validate</phase>
<configuration>
<entry>
<!--
GroupIds here represent locations in the maven repo under which
jars will be searched to form the target platform to compile
against.
-->
<groupId>org.eclipse.plugins</groupId>
</entry>
<entry>
<groupId>org.eclipse.wtp.plugins</groupId>
</entry>
<entry>
<groupId>org.eclipse.gef.plugins
</groupId>
</entry>
<entry>
<groupId>com.mycompany.foo</groupId>
<!--
Version elements can be added to help control the jars selected
into the target platform.
-->
<version>[1.8,1.9)</version>
</entry>
</configuration>
<goals>
<goal>generateDependencies</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>
org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
<!--
Use the eclipse compiler and pass the location of the access rules.
The access rules should have been written out when the dependencies
were generated.
-->
<compilerId>eclipse</compilerId>
<compilerArgument>@${basedir}/target/pde/accessRules</compilerArgument>
</configuration>
<!--
Must add this depedency so that the eclipse compiler is on the classpath
for the maven-compiler-plugin.
-->
<dependencies>
<dependency>
<groupId>org.codehaus.plexus</groupId>
<artifactId>plexus-compiler-eclipse</artifactId>
<version>1.5.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
<resources>
<!--
Reources that should be added to the jar file. Code will automatically be
added so no need to list it here again.
-->
<resource>
<directory>.</directory>
<includes>
<include>.options</include>
<include>plugin.xml</include>
<include>plugin.properties</include>
<include>META-INF/**</include>
<include>icons/**</include>
</includes>
</resource>
</resources>
</build>
</project>
Multiple <execution> elements can be include for compiling against different target platforms and/or jdks. Does anyone see any glaring holes?
Wb
On 8/21/06, Andrew Niefer <aniefer@xxxxxxxxxx> wrote:
Wendell,
The batch compiler itself takes the
access rules embedded in the classpath. Something like the following:
-cp A.jar[rule1;rule2;...];B.jar[rule]
A rule is an Ant pattern to specify
a type, prefixed with one of: + (allowed), - (forbidden), ~ (discouraged),
? (forbidden, keep looking)
PDE.Build uses the compiler through
Ant by setting the build.compiler property to org.eclipse.jdt.core.JDTCompilerAdapter
and calling javac. PDE.Build creates an argument file containing
the access rules and the JDTCompilerAdapter reads this file and inserts
the access rules into the classpath before invoking the compiler.
The org.eclipse.pde.maven bundle that
I previously posted to this list contains a MavenGenerator.writeJDTCompilerAdapterArgFile
method to create this file. Its unclear to me whether or not the
maven compiler plugin will use the adapter in the same way, if it does,
then all you have to do is pass the argument file on the command line using
@<file>. Otherwise you'll need to insert the rules into the
classpath yourself.
-Andrew
pde-build-dev-bounces@xxxxxxxxxxx wrote on 08/18/2006
05:46:25 PM:
