Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 73010 invoked from network); 9 Feb 2006 07:34:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 9 Feb 2006 07:34:38 -0000 Received: (qmail 4461 invoked by uid 500); 9 Feb 2006 07:34:30 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 4400 invoked by uid 500); 9 Feb 2006 07:34:30 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 4389 invoked by uid 99); 9 Feb 2006 07:34:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 23:34:30 -0800 X-ASF-Spam-Status: No, hits=1.3 required=10.0 tests=HTML_MESSAGE,RCVD_IN_BL_SPAMCOP_NET,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of stepan.mishura@gmail.com designates 66.249.92.198 as permitted sender) Received: from [66.249.92.198] (HELO uproxy.gmail.com) (66.249.92.198) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2006 23:34:29 -0800 Received: by uproxy.gmail.com with SMTP id j40so90008ugd for ; Wed, 08 Feb 2006 23:34:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=X8LUrSgzPWA5QBu4oI4ci1mCiJ6OcZb7WnWNPdH0KvUwDQ1BBSMPk7L+WX5RZ6TomKzmwz2jzaQwVln9QcaAICr9dT3n/MKD5jlMGN66PlZgaT4466roPdSQOd8nMeoi6CZQRXdjRm9l1r938czeEGOHg3AI4AGjGIvmmRmfmX4= Received: by 10.48.47.14 with SMTP id u14mr2241866nfu; Wed, 08 Feb 2006 23:34:07 -0800 (PST) Received: by 10.49.30.2 with HTTP; Wed, 8 Feb 2006 23:34:06 -0800 (PST) Message-ID: <6e47b64f0602082334i672e9badj53604e47fc332db2@mail.gmail.com> Date: Thu, 9 Feb 2006 13:34:06 +0600 From: Stepan Mishura To: harmony-dev@incubator.apache.org, geir@pobox.com Subject: Re: [classlib:security2] bootclasspath for security tests [HARMONY-58] In-Reply-To: <43EA9F0F.1010600@pobox.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7137_5214224.1139470446967" References: <43EA8D08.7060405@pobox.com> <43EA9F0F.1010600@pobox.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_7137_5214224.1139470446967 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Geir, > >For the record, I put the jvmarg line back - I did some test class >renaming, and things broke! I put it back, and all is well. Dunno. >Leaving there so it doesn't break anyone else. Will continue to chase >down after dinner > crypto.jar and x_net.jar are not created by the 'main build file' (i.e. make/build.xml) and they are absent in Harmony boot (deploy/jre/lib/boot) directory. So the build script from 'security2' builds them and places explicitly to the bootclasspath. If you remove jvmarg line then you need to update additionally make/build.xml or the build script from 'security2' to put these jars to Harmony boot directory. I think that we should work out some kind of 'transition procedure' for substituting security with security2 to be sure that we don't miss anything and we are consistent. The first step may be extracting x-net component because it is quite independent. Thanks, Stepan Mishura Intel Middleware Products Division On 2/9/06, Geir Magnusson Jr wrote: > > For the record, I put the jvmarg line back - I did some test class > renaming, and things broke! I put it back, and all is well. Dunno. > Leaving there so it doesn't break anyone else. Will continue to chase > down after dinner > > > Geir Magnusson Jr wrote: > > I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the > > issue. > > > > However, there was a small thing that bugged me. We were setting the > > bootclasspath as follows : > > > > > value=3D"-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separato= r > }${build.jars.path}/x_net.jar"/> > > > > > > which has 2 of the 3 artifacts generated by security2 coming from the > > local modules/security2 tree, and the third, security.jar, coming from > > deploy/jre/lib/boot. This isn't healthy. > > > > So I just removed the above line, and now we depend on all three jars > > coming from the same place, namely the deploy boot classpath. > > > > I only feel strongly that we are consistent. We can change from deploy= / > > to modules/security2 if we need to. > > > > I suspect this will be fine, but it does mean that working in > > modules/security2 means that you need to go to top level to re-run the > > build to get the jars in the right place. > > > > I think I'll change the local make in modules/security2 to also copy th= e > > generated jars to ../../deploy/jre/lib/boot/.... > > > > > > That way, you can work locally and still do the proper testing w/o > > having to out of the module you are working in. I suspect that this > > will be a pattern we repeat in all modules. > > > > geir > > > > > ------=_Part_7137_5214224.1139470446967--