You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jeff Genender <jg...@apache.org> on 2005/08/01 09:30:55 UTC
RFC - Fix to the XMLBeans2/Eclipse issue
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.
--
Jeff Genender
http://geronimo.apache.org
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by David Jencks <dj...@gluecode.com>.
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.
>>>>
>>
>
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by David Jencks <dj...@gluecode.com>.
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.
>>>
>
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by Jeff Genender <jg...@savoirtech.com>.
Sachin Patel wrote:
> Jeff, thx for the patches.... Works great! Could you check these in?
I would be happy to...I wanted to get concensus that its fine before I
check them in.
So since this has been out there for several days...
If anyone objects let me know...if I hear from nobody, I will check
these in in the next 24 hours.
Thanks,
Jeff
>
> 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.
>>>>
>>
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by Jeff Genender <jg...@savoirtech.com>.
Sachin Patel wrote:
> Jeff, thx for the patches.... Works great! Could you check these in?
Thay are all in...including openejb.
Jeff
>
> 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.
>>>>
>>
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by Sachin Patel <sp...@gmail.com>.
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.
>>>
>
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by Jeff Genender <jg...@savoirtech.com>.
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.
>>
Re: RFC - Fix to the XMLBeans2/Eclipse issue
Posted by Sachin Patel <sp...@gmail.com>.
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?
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?
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.
>