Jason Dillon schrieb:

[...]

well... can you make an example project? Something very simple showing that? I am sure that would be intersting not only to me.

[...]

"then why"? not sure what you mean with that. Ah, ok, now I see... I did not read the text as I should have.... I did read a build system writen in Java, not a build system driven by java.If I see m2 a build system driven by Java, thenI still do not have a bild file, that contains my Java. Instead I define plugins in Java, need to compile them, probably have that as physical files or jar and need to copy that somewhere, to then use it from my pom. The controling part here is the pom then, meaning it is still a XML driven build system. And I can not define plugins in XML. If I did read right and you need to deploy a plguin by either using an maven itself or copying a file then I am not sure if the plugin will become visible at runtime. Also it seeems as if you really need to generate a file... or write a plugin that allows a plugin to be defined programaticaly... unless m2 tries to protect itselfor the user from doing things like that. This is something that goes much too deep inside to be found in the docs for m2 it seems... Only that it shouldn't... Anyway, even if you use a script in the XML, you still have the breach, since you change from using XML to a genral purpose language.

[...]

like what? Adding a fork mode to the groovyc ant task? Like defining a task at runtime?

well.. I doubt you would find that for example in make ;) Even with autotools you usually do not extend the tool itself, like you do with ant or maven. the only tools where you actually extend the tool itself are probably Rake and Scons... at lastI think you could do that there... The important part is that you need to do that in ant and maven to get something done, that is not covered by plugins yet. In make you write a helper program for that. Ruseel surely can tell how you would do that for Scons and probably Rake too.

[...]

well, you have to tell me exactly what you need, then I can think of a way. For example it seems that if the stubs are not deleted after groovyc has run and leave that to some tool outside, then it would fit Gmaven much better already. I guess the stubs would also need to contain the javadoc and... other things? I am sure I can add some flags to the compiler to get this done... Theoretically I could even hold the compilerin a certain phase and let it run from that point later... of course only given, that the reference to the compiler can be kept... because I would prefer to not to persist the compiler state atm. there must be bigger use before I go down that route

[...]

but that does not mean it is more easy now. Instead of the maven.xml I have now pluginsI would write, or not?

bye blackdrag