openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: RuntimeEnhancement
Date Sat, 29 Jul 2006 08:11:48 GMT

> Hmm. Does anyone have any idea how to convince mvn to do this as  
> part of
> the build process?

             <plugin>
                 <groupId>org.apache.maven.plugins</groupId>
                 <artifactId>maven-jar-plugin</artifactId>
                 <configuration>
                     <archive>
                         <manifestEntries>
                             <Premain-Class>
                                  
org.apache.openjpa.enhance.PCEnhancerAgent</Premain-Class>
                         </manifestEntries>
                     </archive>
                 </configuration>
             </plugin>

Looking at the META-INF/MANIFEST.MF file in the openjpa- 
kernel-0.9.0.jar file, I do see:

Premain-Class: org.apache.openjpa.enhance.PCEnhancerAgent

... so I think it is being generated and put in the jar as expected.  
However, it should probably be in the openjpa-kernel-5-0.9.0.jar  
file, rather than the openjpa-kernel-0.9.0.jar file (since Premain- 
Class is a Java 5 manifest attribute). So I've gone ahead and changed  
the generation to be in openjpa-kernel-5/pom.xml.

However, I haven't yet tested whether this makes the runtime  
enhancement work as expected.




On Jul 28, 2006, at 10:07 PM, Patrick Linskey wrote:

>> I did some experimentation with runtime enhancement (the doc
>> Marc posted was helpful here).  All the code required is
>> checked in to SVN, but you I did have to add Premain-Class:
>> org.apache.openjpa.enhance.PCEnhancerAgent to the manifest
>> for openjpa-kernel-5-0.9.0.jar.
>
> Hmm. Does anyone have any idea how to convince mvn to do this as  
> part of
> the build process?
>
>> Is this right way to resolve the problem? The documentation
>> refers to org.apache.openjpa.jar which presumably would
>> contain the manifest.
>
> A bunch of the docs were converted via sed scripts; some things  
> (such as
> org.apache.openjpa.jar) are a sad victim of the conversion process.  
> That
> used to be kodo.jar.
>
> In the long run, we need to work out our deployment story. We might  
> want
> to move towards a build system that assembles a monolithic jar out of
> all the modules.
>
>> Admittedly this is a minor issue and I have a workaround, but
>> if I can I'd like to help get the change back into svn.
>
> Probably the most useful things would be to fix the docs to point  
> to the
> right jar, and to divine how to make mvn spit out the right manifest
> info. Theoretically, this might be as easy as some directive or  
> putting
> a MANIFEST.MF file somewhere to get merged during the build  
> process. But
> I'm a mvn newbie, so have no real clue sadly.
>
> -Patrick
> ______________________________________________________________________ 
> _
> Notice:  This email message, together with any attachments, may  
> contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
> affiliated
> entities,  that may be confidential,  proprietary,  copyrighted   
> and/or
> legally privileged, and is intended solely for the use of the  
> individual
> or entity named in this message. If you are not the intended  
> recipient,
> and have received this message in error, please immediately return  
> this
> by email and then delete it.


Mime
View raw message