geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: RFC - Fix to the XMLBeans2/Eclipse issue
Date Mon, 01 Aug 2005 14:33:45 GMT

On Aug 1, 2005, at 6:51 AM, Jeff Genender wrote:

> Sachin Patel wrote:
>> Great Jeff.  Thanks for looking into this. Converting the classpath 
>> entry to a "lib" is exactly what I meant by saying by adding classes 
>> folder to preserve binary content.  So I definatley think this is the 
>> correct fix. So with your mid-term solution you're basically doing 
>> the inverse of what adding a resource would do.  Rather then 
>> generating into target/xmlbeans-classes then copying into 
>> target/classes you are leaving the xmlbeans build alone and simply 
>> copying the output back into target/xmlbeans-classes.  Correct?
> Yes...this is it becomes harmless.
>> Going back to using a resource however... can some who's more 
>> familliar state why this would mess up Intellij?  The target/classes 
>> folder would still contain the binary content, the original location 
>> target/xmlbeans-classes would simply be ignored... No?
> This is correct as well.  I would be interested in the IntelliJ issue 
> as well.  I have Intelij installed on my i could try it 
> out. IIRC, this should not affect it, but I will let the heavy 
> IntelliJ users speak up.

I think we should look into generating the binary goo into 
xmlbeans-classes and copying into classes.  Theoretically this would 
allow stunts like bytecode munging on the generated classes.  I think 
we need to consult with the maven guys on how this best fits into the 
maven build steps, especially for maven 2.

I'm left curious how eclipse deals with things like aspect weaving done 
as a static build step.  I would think this would have similar 

david jencks

>> Jeff Genender wrote:
>>> I was tinkering around with the Eclipse project build and I have 
>>> come up with a kludge solution for the xmlbeans2 type class problem.
>>> First, there was an earlier discussion of having the xmlbeans 
>>> compile classes go to another 
>>>  Then we could edit the 
>>> POM, and add a resource...and the jar would ultimately contain 
>>> everything needed.  I like this solution the best, but unfortunately 
>>> the maven xmlbeans2 plugin will need a new property to override the 
>>> default target/classes.  Also, I think I remember someone saying 
>>> this would mess up Idea Intellij (DJ?).
>>> However, I have come up with the following mid-term solution:
>>> All maven.xml files that do an xmlbeans schema run, a 
>>> target/xmlbeans-classes directory will be created and the entire 
>>> target/classes/schemaorg_apache_xmlbeans structure will be copied to 
>>> this directory.  Also, each that has an xmlbeans 
>>> infrasturcture will have the xmlbeans-classes dir added to the 
>>> eclipse included classpath (which really adds it to the src in 
>>> eclipse).  Then in the top level maven.xml, in the m:eclipse, I 
>>> wrote a jelly script that after running the eclipse multiproject, it 
>>> does a search and replace on all .classpath files that has the 
>>> xmlbeans-classes in src converted to a lib - which means it just 
>>> becomes an additional true classpath in eclipse.
>>> This makes it so when eclipse's build occurs and wipes the target 
>>> dir, it still has access to the needed type class files and xsb 
>>> files.
>>> The bottom works...and it doesn't affect intellij or need 
>>> to change the xmlbeans2 maven plugin (which I would much prefer we 
>>> do). This allows a full *working* eclipse project infrastructure for 
>>> Geronimo w/o the need to hack the xmlbean project files in eclipse.
>>> I would appreciate some feedback on this and some concensus before I 
>>> check this in.

View raw message