Return-Path: Delivered-To: apmail-incubator-open-jpa-dev-archive@locus.apache.org Received: (qmail 43404 invoked from network); 15 Aug 2006 22:14:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Aug 2006 22:14:28 -0000 Received: (qmail 18965 invoked by uid 500); 15 Aug 2006 22:14:28 -0000 Delivered-To: apmail-incubator-open-jpa-dev-archive@incubator.apache.org Received: (qmail 18946 invoked by uid 500); 15 Aug 2006 22:14:28 -0000 Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: open-jpa-dev@incubator.apache.org Delivered-To: mailing list open-jpa-dev@incubator.apache.org Received: (qmail 18937 invoked by uid 99); 15 Aug 2006 22:14:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2006 15:14:28 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of david.blevins@visi.com designates 208.42.156.9 as permitted sender) Received: from [208.42.156.9] (HELO cenn.mc.mpls.visi.com) (208.42.156.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Aug 2006 15:14:26 -0700 Received: from [192.168.42.22] (68-171-58-68.vnnyca.adelphia.net [68.171.58.68]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by cenn.mc.mpls.visi.com (Postfix) with ESMTP id AAE8D82A2 for ; Tue, 15 Aug 2006 17:14:05 -0500 (CDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <5CDE8C73-9F34-47D9-90EB-4CB088196FD4@apache.org> References: <7D856CDFE035FF45A0420ACBD71BDD6301B91E87@repbex02.amer.bea.com> <4741B696-E782-4459-B2F1-BEFA2584E8CC@visi.com> <3AE6AF4B-3247-4D42-AB73-8FD8B0B8FA2E@visi.com> <5CDE8C73-9F34-47D9-90EB-4CB088196FD4@apache.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EBF64E7-5DCA-4D31-9528-2A00602319AF@visi.com> Content-Transfer-Encoding: 7bit From: David Blevins Subject: Re: Update version to SNAPSHOT Date: Tue, 15 Aug 2006 15:14:01 -0700 To: open-jpa-dev@incubator.apache.org X-Mailer: Apple Mail (2.752.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Aug 15, 2006, at 12:56 PM, Marc Prud'hommeaux wrote: > David- > >> are there any jars of our own that contain the same file in the >> same place in the jar and those contents are different and need to >> be merged together? > > The only cases I know of are some of the files in services/. E.g.: > > openjpa-jdbc/src/main/resources/META-INF/services/ > org.apache.openjpa.conf.ProductDerivation > openjpa-persistence-jdbc/src/main/resources/META-INF/services/ > org.apache.openjpa.conf.ProductDerivation > openjpa-persistence/src/main/resources/META-INF/services/ > org.apache.openjpa.conf.ProductDerivation > > It's probably not rocket science to fix these (we would would just > need to figure out a way to append them to each other), but it > would prevent OpenJPA from working if we were to just merge the > jars and overwrite same-named files. I've had this issue too. I wrote a small library (one class) in xbean to spin the /META-INF/services/ concept any way you like pretty much. This would cover the way you do things now: import org.apache.xbean.finder.ResourceFinder; ResourceFinder resourceFinder = new ResourceFinder("META-INF/ services/"); List classes = resourceFinder.findAllImplementations (org.apache.openjpa.conf.ProductDerivation.class); But you might consider making "org.apache.openjpa.conf.ProductDerivation" a directory that holds files that contain the implementation class names. Then you can have more than one in a jar. Here's an example directory: http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder/ src/test/resources/META-INF/java.net.URLStreamHandler/ Here's how you'd get your implementations: import org.apache.xbean.finder.ResourceFinder; ResourceFinder resourceFinder = new ResourceFinder("META-INF/"); Map streamHandersMap = resourceFinder.mapAllImplementations(java.net.URLStreamHandler.class); You could just grab all the values from the map and be done with it. But the keys will the file name under "META-INF/ java.net.URLStreamHandler/", which can be useful for all sorts of things. Here is the full test case: http://svn.apache.org/repos/asf/geronimo/ xbean/trunk/xbean-finder/src/test/java/org/apache/xbean/finder/ ResourceFinderTest.java -David > > > On Aug 15, 2006, at 12:46 PM, David Blevins wrote: > >> >> On Aug 15, 2006, at 11:40 AM, Craig L Russell wrote: >> >>> >>> On Aug 15, 2006, at 11:06 AM, David Blevins wrote: >>> >>>> >>>> On Aug 15, 2006, at 6:37 AM, Patrick Linskey wrote: >>>> >>>>>>> Note that that will not merge anything you need in the META-INF >>>>>>> directory. It does do it for plexus components.xml files >>>>>>> though, so >>>>>>> maybe it's a good time to make that pluggable. >>>>>>> >>>>>> >>>>>> It'll definitely add the files from all the META-INF >>>>>> directories into >>>>>> the resulting jar. I guess you are talking specifically about >>>>>> some >>>>>> pluggable strategy to merge two files of the same name such as >>>>>> two >>>>>> META-INF/persistence.xml files or two META-INF/ejb-jar.xml files? >>>>> >>>>> Actually, I was thinking about META-INF/MANIFEST.MF and >>>>> META-INF/services/*. But yes, merging of resources. >>>> >>>> Everything in META-INF/services/* will be copied into the new >>>> jar and you can redefine MANIFEST entries for the new jar using >>>> the same syntax as for the maven-jar-plugin. But it won't >>>> intelligently concatenate the contents of individual matching >>>> files from the source jars as I assume Brett was referring to >>>> with the plexus components.xml. >>> >>> So would it be easier to write a merge-manifest method or to >>> restrict manifest services with the same name to one of the build >>> modules? >> >> Sorry, I think I'm making things clear as mud :) I get the >> feeling we don't even have the issue Brett was mentioning. Aside >> from the MANIFEST.MF file itself, are there any jars of our own >> that contain the same file in the same place in the jar and those >> contents are different and need to be merged together? >> >> It's pretty easy to make a new MANIFEST.MF that better describes >> the new "uber" jar. >> >> -David >> >> >> >