Hey guys, looks like I'm late to the party =)
yeah - partycrasher! ;)
I'm saying that eclipses built in support for running a ant build.xml file when certain files are updated works fine EXCEPT that it seem to crash if your build.xml generates stuff (e.g. .class or .jar files) which eclipse is already using. It crashed no matter i used 3.0 or 3.1.
So, either we have to live with that bug (it occurs 3 out of 5 times) or the user should just have their build.xml generate their result a completely separate place (which probably will be needed anyway to avoid other weird problems with having two separate compilers generating .class files).....this can/will probably make it somewhat cumbersome to support smoothless debugging of ejb3 - but that is probably something marshall is more in to than i.
I think our "temporary" JDK5 compilation soution will end up being a little more complex then just providing a build.xml file. Are you integrating into the internal Eclipse Building API with this solution, or just right clicking on build.xml, and running the Ant task manually? If we integrate this into the build API I think we'll get rid of the crashes that you're seeing.
I was using the automated builder stuff which is in eclipse.
Just added a "builder" on my project and told which ant file and target to run when certain resources are changed (like all files in model/src).
Can it be more integrated than that ?
Sorry for not making it to the conf call, was "trapped" in transit between cities.
It's fine, but next time I expect you to be an hour early =P
Is that an hour in GMT, CET or CST time ? :)
The upcoming persistence tools will most likely need both org.hibernate.eclipse.core and some org.jboss.ide* plugins. Do we have a name for that/those plugins yet ?
I'm thinking if there is a dependency on the core JBossIDE code, it will be somewhere in one of these plugins:
We should take note that, today.. there are no extensions being coded that have absolutely *required* code from JBossIDE to function correctly. Extensions at this point, are effectively standalone plugins that are packaged _as_ extensions.
which actually is a good thing - but we probably could place some common stuff (like class loader and resource manipulation/dialogs)