openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Update version to SNAPSHOT
Date Tue, 15 Aug 2006 22:14:01 GMT

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<Class> 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<String, Class> 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
>>
>>
>>
>


Mime
View raw message