geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <djen...@gluecode.com>
Subject Re: RFC - Fix to the XMLBeans2/Eclipse issue
Date Mon, 01 Aug 2005 14:46:17 GMT
There are some people working on eclipse xmlbeans plugins.  I have no 
idea what these do, but maybe we should try to coordinate with them 
somehow:

axis2:

https://svn.apache.org/repos/asf/webservices/axis/trunk/java

standalone sourceforge project:
xmlbeans 1
http://sourceforge.net/projects/xmlbeansplug/
xmlbeans 2 (incomplete)
http://sourceforge.net/cvs/?group_id=116518

There's some discussion on the xmlbeans dev list 
(dev@xmlbeans.apache.org)

david jencks

On Aug 1, 2005, at 7:33 AM, David Jencks wrote:

>
> 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 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.
>
> 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 
> problems.
>
> thanks
> 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 
>>>> 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