Jason Dillon schrieb:

^^

[...]

can you point me to some documentation about that?

that is groovy embedded in XML, yes? If it is external files it won't be better. Also the question would be if I can create a plugin for the currently running m2 build while the build is running using groovy embedded in XML... I mean that would still be a media breach, but at last I don't have to scatter my build parts all of the place if I don't want to

[...]

Well, it was not my intention to say they intended something else... but what is a configuration with loops and branch logic? Even if they intended not to program something, you end up doing so indirectly at last.. for example by writing a new ant task

again, that is groovy embedded in XML. That is still a media breach. Also, if most of your build consists of groovy, then why is it xml based at all?

no, using a java based tool is not a breach. I don't see a breach when you use existing tasks in ant for example. I see a breach when you have to embed groovy in XML in order to define a task... is it even possible to write a task in a groovy task? The gant people might be able to say if that is so. I think it is possible to register a task... what I want to say is that there is a difference between writing a small script, because something is not as it should be and producing reusable code by for example writing methods that can be used from different parts of the build. Even in a bash script I can use tasks and source other scripts. Having multiple embedded groovy scripting entities that can not really communicate with each other is not good. If they want to communicate, then they have to do so using the ant or maybe maven infrastructure. hat's a level of indirection that is uncomfortable.. well in my opinion ;)

[...]

and I think that is the basic difference between our views. I think flexibility is not bad. A build system should support the user, not force him to do something. Of course I know that forcing somebody to do something can be more easy for the developers of the build system, as well as for the one that gets forced. But a system build on force gets so much inflexibility, that as soon as you have a case not covered by the current rules, nobody actually knows what to do... if it can be done even.

Important is how much cost is involved with this flexibility to see if it is worth it. Now for ant I can say, that even then not really complicated groovy build is already too much. The cost function is quite bad for ant... meaning you start low and climb very soon very high. I am sure m2 is better here... but I think also it is not cheap enough. Of course it is just a personal feeling and often this comes from a lack of knowledge, which often comes from a lack of support and documentation.

for a really simple project anything will do

if easy usage includes that you do not have to restructure your project, then it takes away ;)

you may have seen already, that I am not so keen about the configuration approach at all.

sure, yes... but we already agreed that in simple cases anything will do, and I also said that for the intended use case, these tools all shine. It gets interesting when you leave the road they built. And since m2 wants to enforce something you have to climb a wall to even leave the road... or not?

[...]

because I don't want a build tool to force me to use a given structure. If it does not support my structure, that is ok. But if the tool makes it even more complicated in that case, then the tools is simply nothing for me.

well, at last they hide that a little ;)

yes, but the conclusions are very different. While m2 seems to follow the idea that build logic should not be in the build file and that a build should be only a configuration, I intend go the other way and say a build is almost nether only a configuration and you want to have build logic in your build file. So I think m1 didn't suck because configuration and build logic was mixed, I think it sucked because it was partially bad programmed (did hide exceptions for example) and because jelly really sucks as a programming language... and because it is all XML of course... in fact that alone would be enough for me already ;) If we say that ant is also a configuration, then ant, m1 and m2 share a common way, one that I think is not right for me. I am a programmer and I want to be able to express myself in programs, not configurations. And I can use a bit descriptive programming in Groovy too. Meaning I can write programs, that look like configurations, but can also easily extend to do "real" programming

and did they wrote normal programs too? Didn't you have the same problem there too? I mean why is a bad programmer more of a catastrophe when he writes a build script, then when he write any normal program? I think you have bad luck in both cases. And even in m2 he can really mess things up if m2 is as flexible as you state

[...]

true

ehm... I think that is the wrong way to see it. What you need is a build that works for as many people as possible. If you don't need to change the build, then you don't care about the build internals as long as it works. If you had said that there is not one project layout that will fit everyone's taste, then yes, I agree with you. If you had said there is not one build file everyone will like, then again I agree with you. But is this really important? Important is what the one that changes the build file likes. And I think even if gradle would become very famous, there will still be people using m2 or ant.

[...]

and why do you think that will not happen for m2? We already found that many people do wrong things because they don't know the documentation.

which can be said for any program!

[...]

oh I didn't think it would not happen, but the speed was really amazing.

[...]

a non standard thing... how about keeping the current project structure ;)

bye blackdrag