Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 66192 invoked from network); 7 Apr 2010 16:32:29 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 7 Apr 2010 16:32:29 -0000 Received: (qmail 98164 invoked by uid 500); 7 Apr 2010 16:32:29 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 98102 invoked by uid 500); 7 Apr 2010 16:32:29 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 98095 invoked by uid 99); 7 Apr 2010 16:32:29 -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 16:32:29 +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,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [98.136.44.58] (HELO smtp103.prem.mail.sp1.yahoo.com) (98.136.44.58) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 07 Apr 2010 16:32:21 +0000 Received: (qmail 14570 invoked from network); 7 Apr 2010 16:31:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=jhoJVVgKM3lUafKVACivWSaCJsdd+MuOwTi/kFtH8jmyIAPhbgCrh2MQO8UZ5oJ/psCBqlqJM0u2U6MGI+LgTsQYfT/3Ng+zfEjrNrN/XycslPiUWztzPasyw9PUxqRAutBVdwCS5dPzanbzJxzfVpfeDxJSp92Yz3W3Q2UbdUM= ; Received: from 076-076-148-215.pdx.net (david_jencks@76.76.148.215 with plain) by smtp103.prem.mail.sp1.yahoo.com with SMTP; 07 Apr 2010 09:31:59 -0700 PDT X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: wFGXKM4VM1lpMUZCZ9fD2fTw3WUHKBmJqZ_B2zw1p.sU5qTybsfTtAI.m_s9fhw0a7XHfE4ss7dblTpdzmDf3B0XYPsSi9srBTY3HHEeG1MS2YtgYZGQ2Cf6262zZ5wXDKnQfUW1HdoCJFhIxoc_GX5MtldnYf_KircEDpGL68Xuv7F8wzYO2EoyrQygfTuVd4nM7vkk7yXxYJJIA.iOwRqbrPlZdlTBqJILE6BF8KnbG0vRZoXrmJspWR4txkvwc5_1ST7JLoc9xdo5XDxpiYqaeb2593Rg2aj_ycN.QR2vNqRyUdjfTvbtO9aV5IqgIecGyw-- X-Yahoo-Newman-Property: ymail-3 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) Subject: Re: Maven compiler & endorsed libraries From: David Jencks In-Reply-To: Date: Wed, 7 Apr 2010 09:31:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1C895888-46B3-4376-A8DD-C60FABF67F17@yahoo.com> References: <4BBC54C0.80900@gmail.com> To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.1077) X-Virus-Checked: Checked by ClamAV on apache.org On Apr 7, 2010, at 6:24 AM, Jarek Gawor wrote: > On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire = wrote: >> On 4/6/2010 5:23 PM, Jarek Gawor wrote: >>=20 >> I came up with one solution (committed in revision 931319). >>=20 >> 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:... string where each >> 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. >>=20 >> 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). >>=20 >>=20 >> 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: >=20 > >=20 > 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 >=20 > Jarek