geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <sppat...@gmail.com>
Subject Re: RFC - Fix to the XMLBeans2/Eclipse issue
Date Fri, 12 Aug 2005 22:23:08 GMT
Jeff, thx for the patches.... Works great! Could you check these in?

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 correct...so 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 machine...so i could try it 
> out. IIRC, this should not affect it, but I will let the heavy 
> IntelliJ users speak up.
>
>
>>
>> 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 
>>> directory...say...target/xmlbeans-classes.  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 project.properties 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 line...it 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.
>>>
>

Mime
View raw message