You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2010/04/02 20:08:44 UTC
Maven compiler & endorsed libraries
Hi,
We need to find a way to make the compiler in Maven to load certain
libraries as endorsed libraries. I know this has been discussed before
but do we have some specific solutions for this problem? We will need
to deal with this fairly soon now - for example to implement the
@Resource.lookup support.
Jarek
Re: Maven compiler & endorsed libraries
Posted by Daniel Kulp <dk...@apache.org>.
On Friday 02 April 2010 2:08:44 pm Jarek Gawor wrote:
> Hi,
>
> We need to find a way to make the compiler in Maven to load certain
> libraries as endorsed libraries. I know this has been discussed before
> but do we have some specific solutions for this problem? We will need
> to deal with this fairly soon now - for example to implement the
> @Resource.lookup support.
Not that I know of. I never got around to actually working on it.
:-(
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: Maven compiler & endorsed libraries
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Apr 7, 2010 at 1:20 PM, Jarek Gawor <jg...@gmail.com> wrote:
>
> I considered that too. If you're dealing with released artifacts that
> should work ok. But if you are dealing with snapshot dependencies, you
> might have multiple jars in the same directory with a different
> snapshot version. The -Djava.endorsed.dirs would pick up all these
> jars and so we wouldn't know exactly which jar is actually used.
> That's why a temporary directory would be needed to copy the specific
> artifact.
>
> Once the annotation, jaxws, etc. specs are released it should be
> trivial to update the geronimo-property-plugin to return
> -Djava.endorsed.dirs property instead of -Xbootclasspath property.
>
Btw, I just updated the geronimo-property-plugin to return files or
directories in the property it sets. So if we wanted the pass the
-Djava.endorsed.dirs property to the compiler or surefire plugin we
just need to configure the geronimo-property-plugin with:
<propertyValuePrefix>-Djava.endorsed.dirs=</propertyValuePrefix>
<listFiles>false</listFiles>
instead of:
<propertyValuePrefix>-Xbootclasspath/p:</propertyValuePrefix>
<listFiles>true</listFiles>
Jarek
Re: Maven compiler & endorsed libraries
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Apr 7, 2010 at 12:31 PM, David Jencks <da...@yahoo.com> wrote:
>
> On Apr 7, 2010, at 6:24 AM, Jarek Gawor wrote:
>
>> On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire <ri...@gmail.com> wrote:
>>> On 4/6/2010 5:23 PM, Jarek Gawor wrote:
>>>
>>> I came up with one solution (committed in revision 931319).
>>>
>>> In this solution I created a maven-property-plugin which executes in
>>> the "validate" phase and sets "bootClassPath" system property. The
>>> value of "bootClassPath" property is set to
>>> -Xbootclasspath/p:<path><pathSeparator><path>... string where each
>>> <path> is the jar file to prepend to boot classpath. The
>>> "bootClassPath" property is then used in maven-compiler-plugin and
>>> maven-surefire-plugin and passed as a java/javac argument.
>>>
>>> This seems to work for me but I'm wondering if it works for other
>>> people on different OSes and JVMs (especially on Windows and on
>>> non-Sun JVMs).
>>>
>>>
>>> What's driving the need for doing this? Generally, prepending something to
>>> the bootstrap classpath is considered very bad form. The JVM supported
>>> method for overriding bootstrap classes is the endorsed directory path. I
>>> took another look at what Yoko does to get around this problem, and it
>>> appears the mavan-compiler-plugin and surefire plugins have all the support
>>> you need. Here are some snippets from the Yoko core subproject. To compile
>>> this code, it requires the yoko-corba-spec classes rather than the JVM
>>> provided ones. The build contains the following build steps:
>>
>> <snip>
>>
>> I am aware of that solution as well and it works great for simple or
>> just a few modules. But as soon as you have to scale this to a large
>> number of modules it sucks because maven-dependency-plugin will keep
>> creating and copying the same files around for each module. We could
>> create some plugin that creates a single shared endorsed directory but
>> then we would have to worry about deleting that directory on maven
>> shutdown, etc.
>> I chose to go with -Xbootclasspath/p since it takes a list of jar
>> files and we don't have worry about copying any files or deleting any
>> directories. The -Xbootclasspath/p is a non-standard option and that
>> is a bit of a concern. However, the most popular JVMs do support this
>> option. If we run into a JVM that we need to support and it does not
>> have this option then I'll guess we will need to re-evaluate.
>
> Why can't we skip the use of the dependency plugin to copy jars and just set the endorsed dirs to a list of the desired jars in the local maven repo? I have no particular objection to -Xbootclasspath but wouldn't mind understanding whether this would work...
I considered that too. If you're dealing with released artifacts that
should work ok. But if you are dealing with snapshot dependencies, you
might have multiple jars in the same directory with a different
snapshot version. The -Djava.endorsed.dirs would pick up all these
jars and so we wouldn't know exactly which jar is actually used.
That's why a temporary directory would be needed to copy the specific
artifact.
Once the annotation, jaxws, etc. specs are released it should be
trivial to update the geronimo-property-plugin to return
-Djava.endorsed.dirs property instead of -Xbootclasspath property.
> It does seem like all the maven plugins that start a new jvm need support for endorsed and ext dirs based from the maven repo..... is it possible that patching the plugins might be, long-term, the fastest way to solve the problem?
Sure. The stuff that geronimo-property-plugin is doing is pretty much
what the compiler or surefire plugin would need to do.
Jarek
Re: Maven compiler & endorsed libraries
Posted by David Jencks <da...@yahoo.com>.
On Apr 7, 2010, at 6:24 AM, Jarek Gawor wrote:
> On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire <ri...@gmail.com> wrote:
>> On 4/6/2010 5:23 PM, Jarek Gawor wrote:
>>
>> I came up with one solution (committed in revision 931319).
>>
>> In this solution I created a maven-property-plugin which executes in
>> the "validate" phase and sets "bootClassPath" system property. The
>> value of "bootClassPath" property is set to
>> -Xbootclasspath/p:<path><pathSeparator><path>... string where each
>> <path> is the jar file to prepend to boot classpath. The
>> "bootClassPath" property is then used in maven-compiler-plugin and
>> maven-surefire-plugin and passed as a java/javac argument.
>>
>> This seems to work for me but I'm wondering if it works for other
>> people on different OSes and JVMs (especially on Windows and on
>> non-Sun JVMs).
>>
>>
>> What's driving the need for doing this? Generally, prepending something to
>> the bootstrap classpath is considered very bad form. The JVM supported
>> method for overriding bootstrap classes is the endorsed directory path. I
>> took another look at what Yoko does to get around this problem, and it
>> appears the mavan-compiler-plugin and surefire plugins have all the support
>> you need. Here are some snippets from the Yoko core subproject. To compile
>> this code, it requires the yoko-corba-spec classes rather than the JVM
>> provided ones. The build contains the following build steps:
>
> <snip>
>
> I am aware of that solution as well and it works great for simple or
> just a few modules. But as soon as you have to scale this to a large
> number of modules it sucks because maven-dependency-plugin will keep
> creating and copying the same files around for each module. We could
> create some plugin that creates a single shared endorsed directory but
> then we would have to worry about deleting that directory on maven
> shutdown, etc.
> I chose to go with -Xbootclasspath/p since it takes a list of jar
> files and we don't have worry about copying any files or deleting any
> directories. The -Xbootclasspath/p is a non-standard option and that
> is a bit of a concern. However, the most popular JVMs do support this
> option. If we run into a JVM that we need to support and it does not
> have this option then I'll guess we will need to re-evaluate.
Why can't we skip the use of the dependency plugin to copy jars and just set the endorsed dirs to a list of the desired jars in the local maven repo? I have no particular objection to -Xbootclasspath but wouldn't mind understanding whether this would work...
It does seem like all the maven plugins that start a new jvm need support for endorsed and ext dirs based from the maven repo..... is it possible that patching the plugins might be, long-term, the fastest way to solve the problem?
thanks
david jencks
>
> Jarek
Re: Maven compiler & endorsed libraries
Posted by Jarek Gawor <jg...@gmail.com>.
On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire <ri...@gmail.com> wrote:
> On 4/6/2010 5:23 PM, Jarek Gawor wrote:
>
> I came up with one solution (committed in revision 931319).
>
> In this solution I created a maven-property-plugin which executes in
> the "validate" phase and sets "bootClassPath" system property. The
> value of "bootClassPath" property is set to
> -Xbootclasspath/p:<path><pathSeparator><path>... string where each
> <path> is the jar file to prepend to boot classpath. The
> "bootClassPath" property is then used in maven-compiler-plugin and
> maven-surefire-plugin and passed as a java/javac argument.
>
> This seems to work for me but I'm wondering if it works for other
> people on different OSes and JVMs (especially on Windows and on
> non-Sun JVMs).
>
>
> What's driving the need for doing this? Generally, prepending something to
> the bootstrap classpath is considered very bad form. The JVM supported
> method for overriding bootstrap classes is the endorsed directory path. I
> took another look at what Yoko does to get around this problem, and it
> appears the mavan-compiler-plugin and surefire plugins have all the support
> you need. Here are some snippets from the Yoko core subproject. To compile
> this code, it requires the yoko-corba-spec classes rather than the JVM
> provided ones. The build contains the following build steps:
<snip>
I am aware of that solution as well and it works great for simple or
just a few modules. But as soon as you have to scale this to a large
number of modules it sucks because maven-dependency-plugin will keep
creating and copying the same files around for each module. We could
create some plugin that creates a single shared endorsed directory but
then we would have to worry about deleting that directory on maven
shutdown, etc.
I chose to go with -Xbootclasspath/p since it takes a list of jar
files and we don't have worry about copying any files or deleting any
directories. The -Xbootclasspath/p is a non-standard option and that
is a bit of a concern. However, the most popular JVMs do support this
option. If we run into a JVM that we need to support and it does not
have this option then I'll guess we will need to re-evaluate.
Jarek
Re: Maven compiler & endorsed libraries
Posted by Rick McGuire <ri...@gmail.com>.
On 4/6/2010 5:23 PM, Jarek Gawor wrote:
> I came up with one solution (committed in revision 931319).
>
> In this solution I created a maven-property-plugin which executes in
> the "validate" phase and sets "bootClassPath" system property. The
> value of "bootClassPath" property is set to
> -Xbootclasspath/p:<path><pathSeparator><path>... string where each
> <path> is the jar file to prepend to boot classpath. The
> "bootClassPath" property is then used in maven-compiler-plugin and
> maven-surefire-plugin and passed as a java/javac argument.
>
> This seems to work for me but I'm wondering if it works for other
> people on different OSes and JVMs (especially on Windows and on
> non-Sun JVMs).
>
What's driving the need for doing this? Generally, prepending something
to the bootstrap classpath is considered very bad form. The JVM
supported method for overriding bootstrap classes is the endorsed
directory path. I took another look at what Yoko does to get around
this problem, and it appears the mavan-compiler-plugin and surefire
plugins have all the support you need. Here are some snippets from the
Yoko core subproject. To compile this code, it requires the
yoko-corba-spec classes rather than the JVM provided ones. The build
contains the following build steps:
1) Get the required jars into an endorsed directory: This is done
using the dependency plugin.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.yoko</groupId>
<artifactId>yoko-spec-corba</artifactId>
<type>jar</type>
<overWrite>true</overWrite>
<outputDirectory>${project.build.directory}/endorsed</outputDirectory>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
2) Compile the code with a specified endorsed dir. This is handled
using the maven-comiler-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.4</source>
<target>1.4</target>
<compilerArguments>
<endorseddirs>${project.build.directory}/endorsed</endorseddirs>
</compilerArguments>
</configuration>
</plugin>
3) Run the unit tests with the same endorsed dir:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<includes>
<include>**/org/apache/yoko/*Test.java</include>
</includes>
<systemProperties>
<property>
<name>java.endorsed.dirs</name>
<value>${basedir}/target/endorsed</value>
</property>
</systemProperties>
</configuration>
</plugin>
I knew about steps 1&3, but I just discovered step 2 when I double
checked after seeing your solution. This solution really should be used
rather than overriding the bootClasspath.
Rick
> Jarek
>
> On Fri, Apr 2, 2010 at 2:08 PM, Jarek Gawor<jg...@gmail.com> wrote:
>
>> Hi,
>>
>> We need to find a way to make the compiler in Maven to load certain
>> libraries as endorsed libraries. I know this has been discussed before
>> but do we have some specific solutions for this problem? We will need
>> to deal with this fairly soon now - for example to implement the
>> @Resource.lookup support.
>>
>> Jarek
>>
>>
>
Re: Maven compiler & endorsed libraries
Posted by Jarek Gawor <jg...@gmail.com>.
I came up with one solution (committed in revision 931319).
In this solution I created a maven-property-plugin which executes in
the "validate" phase and sets "bootClassPath" system property. The
value of "bootClassPath" property is set to
-Xbootclasspath/p:<path><pathSeparator><path>... string where each
<path> is the jar file to prepend to boot classpath. The
"bootClassPath" property is then used in maven-compiler-plugin and
maven-surefire-plugin and passed as a java/javac argument.
This seems to work for me but I'm wondering if it works for other
people on different OSes and JVMs (especially on Windows and on
non-Sun JVMs).
Jarek
On Fri, Apr 2, 2010 at 2:08 PM, Jarek Gawor <jg...@gmail.com> wrote:
> Hi,
>
> We need to find a way to make the compiler in Maven to load certain
> libraries as endorsed libraries. I know this has been discussed before
> but do we have some specific solutions for this problem? We will need
> to deal with this fairly soon now - for example to implement the
> @Resource.lookup support.
>
> Jarek
>