Return-Path: 
 <dev-return-81521-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 79716 invoked from network); 7 Apr 2010 17:21:23 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 7 Apr 2010 17:21:23 -0000
Received: (qmail 81108 invoked by uid 500); 7 Apr 2010 17:21:22 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 81054 invoked by uid 500); 7 Apr 2010 17:21:22 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Received: (qmail 81047 invoked by uid 99); 7 Apr 2010 17:21:22 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Apr 2010 17:21:22 +0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of jgawor@gmail.com designates
 209.85.212.54 as permitted sender)
Received: from [209.85.212.54] (HELO mail-vw0-f54.google.com) (209.85.212.54)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Apr 2010 17:21:15 +0000
Received: by vws17 with SMTP id 17so675759vws.13
        for <dev@geronimo.apache.org>; Wed, 07 Apr 2010 10:20:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:in-reply-to:references
         :date:received:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        bh=yNxZWqeA10pqdp6YIcnzJdF7lPFWhW9olqE4XyJoXXo=;
        b=mJJvRuUFR/Ec1ZQAovEk6j9KztpWi9xsY49yOrtPV4mGlfdFaT7BXoEc9LEB4uz201
         aA5HsB9tuZdareJ1MLX5/jEmecUKlw8qZ+L8RZJRmzNMm4Ejc4XL7btYqZ/V9MAeebaW
         WCQwESCEcSlvI3kZOl1gbUZYMVktPL6KneE/k=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=h99FCMiPnXL13AJ9Dlf8Ig31q413gax+2Kpjr0GhcVQSWV6yrD/NDtmBaYlNFrDFnp
         tY76+8W0tDG6RlhhiPFcv49Y9zXwFMmzBUPjnHV2Jkg/4egn6MtOe89p5ZbM3IpurLzB
         PNe+7riZoEJVtjReKr3QTMV+Qhv8O5axSI1CE=
MIME-Version: 1.0
Received: by 10.220.84.3 with HTTP; Wed, 7 Apr 2010 10:20:54 -0700 (PDT)
In-Reply-To: <1C895888-46B3-4376-A8DD-C60FABF67F17@yahoo.com>
References: <q2l5eb405c71004021108rc4471362u6182c8942738e86c@mail.gmail.com>
	 <v2t5eb405c71004061423lbaf6d9d9u71c312eea446b682@mail.gmail.com>
	 <4BBC54C0.80900@gmail.com>
	 <k2q5eb405c71004070624nf36ee2caz6f1ab9f5de6ad97b@mail.gmail.com>
	 <1C895888-46B3-4376-A8DD-C60FABF67F17@yahoo.com>
Date: Wed, 7 Apr 2010 13:20:54 -0400
Received: by 10.220.158.12 with SMTP id d12mr4543662vcx.204.1270660854078;
	Wed, 07 Apr 2010 10:20:54 -0700 (PDT)
Message-ID: <n2o5eb405c71004071020oa82fe044se85b1e2d4fb7f2c1@mail.gmail.com>
Subject: Re: Maven compiler & endorsed libraries
From: Jarek Gawor <jgawor@gmail.com>
To: dev@geronimo.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

On Wed, Apr 7, 2010 at 12:31 PM, David Jencks <david_jencks@yahoo.com> wrot=
e:
>
> On Apr 7, 2010, at 6:24 AM, Jarek Gawor wrote:
>
>> On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire <rickmcg@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? =A0Generally, prepending someth=
ing to
>>> the bootstrap classpath is considered very bad form. =A0The JVM support=
ed
>>> method for overriding bootstrap classes is the endorsed directory path.=
 =A0I
>>> 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 sup=
port
>>> you need. =A0Here are some snippets from the Yoko core subproject. =A0T=
o compile
>>> this code, it requires the yoko-corba-spec classes rather than the JVM
>>> provided ones. =A0 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=
? =A0I have no particular objection to -Xbootclasspath but wouldn't mind un=
derstanding 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..... =A0is it possible=
 that patching the plugins might be, long-term, the fastest way to solve th=
e problem?

Sure. The stuff that geronimo-property-plugin is doing is pretty much
what the compiler or surefire plugin would need to do.

Jarek