69 messages in org.codehaus.groovy.devRe: [groovy-dev] Building Groovy
FromSent OnAttachments
Russel WinderOct 6, 2008 4:36 am 
MingfaiOct 6, 2008 4:47 am 
Hans DockterOct 6, 2008 4:50 am 
Hans DockterOct 6, 2008 4:55 am 
Jochen TheodorouOct 6, 2008 4:56 am 
Guillaume LaforgeOct 6, 2008 7:17 am 
Hans DockterOct 6, 2008 7:51 am 
Russel WinderOct 6, 2008 7:59 am 
Guillaume LaforgeOct 6, 2008 8:19 am 
Guillaume LaforgeOct 6, 2008 8:25 am 
MingfaiOct 6, 2008 8:28 am 
Guillaume LaforgeOct 6, 2008 8:36 am 
Hans DockterOct 6, 2008 1:46 pm 
Guillaume LaforgeOct 6, 2008 1:54 pm 
Hans DockterOct 6, 2008 1:54 pm 
Jochen TheodorouOct 6, 2008 2:03 pm 
Guillaume LaforgeOct 6, 2008 2:09 pm 
Paul DuffyOct 6, 2008 7:06 pm 
Luke DaleyOct 6, 2008 8:47 pm 
Guillaume LaforgeOct 6, 2008 9:44 pm 
Russel WinderOct 6, 2008 11:25 pm 
Russel WinderOct 6, 2008 11:54 pm 
Russel WinderOct 7, 2008 12:03 am 
Jason DillonOct 7, 2008 12:23 am 
Russel WinderOct 7, 2008 12:24 am 
Guillaume LaforgeOct 7, 2008 12:30 am 
Hans DockterOct 7, 2008 12:35 am 
Jason DillonOct 7, 2008 12:35 am 
Hans DockterOct 7, 2008 12:36 am 
Jason DillonOct 7, 2008 12:41 am 
Guillaume LaforgeOct 7, 2008 12:54 am 
Jason DillonOct 7, 2008 1:40 am 
Guillaume LaforgeOct 7, 2008 1:50 am 
Jason DillonOct 7, 2008 1:55 am 
Guillaume LaforgeOct 7, 2008 2:25 am 
Guillaume LaforgeOct 7, 2008 2:35 am 
Jason DillonOct 7, 2008 3:09 am 
Guillaume LaforgeOct 7, 2008 3:12 am 
Russel WinderOct 7, 2008 3:17 am 
Jason DillonOct 7, 2008 3:24 am 
Paul KingOct 7, 2008 4:04 am 
ma...@dockter.bizOct 7, 2008 4:19 am 
ma...@dockter.bizOct 7, 2008 4:25 am 
Jason DillonOct 7, 2008 4:36 am 
Jason DillonOct 7, 2008 4:39 am 
Jochen TheodorouOct 7, 2008 5:20 am 
Jason DillonOct 7, 2008 8:19 am 
Jochen TheodorouOct 7, 2008 9:51 am 
Jason DillonOct 7, 2008 10:49 am 
Jochen TheodorouOct 7, 2008 12:03 pm 
Hans DockterOct 7, 2008 2:34 pm 
Luke DaleyOct 7, 2008 3:52 pm 
Jason DillonOct 8, 2008 1:28 am 
Jason DillonOct 8, 2008 1:35 am 
Hans DockterOct 8, 2008 3:11 am 
Hans DockterOct 8, 2008 3:49 am 
Hans DockterOct 8, 2008 4:30 am 
Hans DockterOct 8, 2008 4:40 am 
Jason DillonOct 8, 2008 4:52 am 
Jason DillonOct 8, 2008 5:21 am 
Jochen TheodorouOct 8, 2008 6:23 am 
Jochen TheodorouOct 8, 2008 6:47 am 
Jochen TheodorouOct 8, 2008 6:59 am 
Hans DockterOct 8, 2008 8:33 am 
Hans DockterOct 8, 2008 8:43 am 
Paul DuffyOct 9, 2008 8:58 am 
Paul KingOct 9, 2008 1:15 pm 
Danno FerrinOct 9, 2008 1:27 pm 
Paul KingOct 10, 2008 2:31 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [groovy-dev] Building GroovyActions...
From:Jochen Theodorou (blac@gmx.org)
Date:Oct 7, 2008 12:03:54 pm
List:org.codehaus.groovy.dev

Jason Dillon schrieb:

On Oct 7, 2008, at 11:52 PM, Jochen Theodorou wrote:

First you don't need to deploy anything to use a plugin, you can include the plugin in your reactor build and you are fine.

can you point me to some documentation about that?

I'm not sure anyone has a specific guide on this, but a M2 plugin is just a jar file with some metadata encoded which lives in a repository.

this sounds very much as if some sort of deployment is needed. I never thought about a central repository on a far away server here of course.

So if in your build you have a plugin module and a module which uses the plugin, M2 will build the plugin first, install it into the local repo, then when the dependent module runs it uses that plugin. Nothing more fancy than that.

This reads a little as if there is no documentation/guide of how to write a plugin, deploy it to the local repository and then use it from your build.

Well, that is not good enough for me anyway. It sounds like a two phase operation, where I have to do both phases. That is something lacking automatisation if it is like that.

Second, using scripting tools like GMaven (or the JRuby plugin or whatever) you can *easily* add extra functionality to your build it basically the exact same fashion as all of these Groovy DSL-based build tools can. In fact as far as getting the build to "properly express what I need remains" goes, there is no difference, simply configure the plugin and write up your groovy to do the remaining bits.

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

You can embed or use external files, urls, resources, whichever you feel like.

this answers the first question, but not the second.. thinking about the deployment to a local repository and the jar that is required for it I guess it is not possible, or at last not easy.

Sure if you need something outside the set of existing tasks you need to program a new task, or use one of the scripting tasks that are available, which brings us right back to the same point I'm making above.

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?

Interesting, so what type of thing you are building should determine the type of system used to build? Based on that, groovy-core should use a Java-based system, since its got more .java files than .groovy or .xml files ;-)

You are making a small mistake here. Groovy is not intended to replace Java, it is part of the toolbox. Groovy is especially designed to work well together with Java. Now using anything to script m2 is quite different, because m2 is not especially designed to be scripted. I even think that doing so would be against the maven philosophy of not having build logic in the build configuration file.Of course you can write plugins in Groovy and use them like you use java plugins, but that misses the point, because this talk is more or less about having a build configuration or a build program.

<snip> Sanity:groovy-core jason$ find src/main/ -name \*.java | wc -l 681 Sanity:groovy-core jason$ find src/main/ -name \*.groovy | wc -l 121 Sanity:groovy-core jason$ find src/test/ -name \*.java | wc -l 182 Sanity:groovy-core jason$ find src/test/ -name \*.groovy | wc -l 582 </snip>

Thats 863 (.java main+test) vs. 703 (.groovy main+test)

IMO the format of the build tool input has nothing to do with the build tool outputs.

build tool format? I think the question to use a programming language as base for a build system or XML is more than just a question of formating

[...]

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 the 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.

Hrm... well I know that some of the M2 plugin docs are poor, though it does provide some automated tools to generate basic configuration details. Though, there are books about Maven just like there are about Ant. The user's list is quite active, so is the IRC channel on freenode. So support seems to be on par with Ant there too. Even have companies which provide professional support where its needed.

But the books won't answer the tricky questions. Professional support is not always for open source developers.Generating basic configuration is nice and good, but that won't help with the tricky parts either. Ant is more easy, because it is less complex. m2 has an additional layer, an additional machine running inside, hidden from the normal eye, that you have to understand as well when it comes to the bad parts. Of course there is always someone able to answer the tricky question. But for example in case of ant there is so much documentation on the net, even about unusual problems, that it is easy to find solutions in most cases. Ant has been there for many years and m2 will need a long time before it can be on par with that.

[...]

Surely it does add some extra xml muck, but IMO its easier to configure a simple M2 pom to compile a project than it is to configure Ant.

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

Sure ;-) But I'm just warning that a code-based system is eventually going to atrophy just like the Ant system has, and will become more and more complicated for new folks to comprehend and maintain. Again, my opinion... I've been wrong before though :-P

I am curious about the cases Hans wants to show...

You don't have to know anything about plugins (or tasks) just the basic pom elements to set the groupId, artifactId, version... and where to put your source files. Fairly easy IMO... and really not all that different from Ant, where you have to know which tasks to configure and how to configure them, as well as pick some place to put your files. M2 removes the need for folks to know about plugins or configuration for simple projects, simply make a pom.xml and put your goodies into src/main/java or src/test/java and you are done. IMO that is much easier. When things get more complicated I believe its about the same for Ant or M2 (or even M2) have to *know* more about the tool, how to configure, what to configure, etc.

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?

Just curious, what are the enforcement bits in M2 which have caused you problems in the past?

You really can make M2 do most anything you want... its just a matter of how much extra work you want to put in to make it behave exactly how you want... vs. using the standards and letting M2 do the work for you.

I am sure that for someone who knows the internals of m2 all things are easy to do. I mean just take for example me and some strange language extension to Groovy. I can in most cases easily add that somehow. If it is a clean way or if it even should be done at all is a different question. But I can do. Now for the normal user this is more or less impossible, since he does not know the internals of Groovy and the can be complex. in ant I have internals too... sometimes many layers of indirection making me crazy if I need to find something. But after all it is not a so complicated thing and you get somehow through it. I never wrote any plugins for m2 or tried to fix bugs... or get around them somehow. But from the look at the codebase of m2 I cannot say I like it very much. Again, my personal opinion, that thing that does not have to be based on facts ;) More or less my problem in m2 was always that I not even have an idea of where to start

[...]

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,

No, configuration was in project.xml and build logic was in maven.xml, I don't really consider that mixed at all.

hehe, yes, I remember..the project.xml contained nearly nothing and the maven.xml was a monster. In the end the project.xml did not do much and the file you always change is the maven.xml. Also if ant is configuration too and most of the action you would do in ant happens in the maven.xml, then why is the maven.xml no configuration?

[...]

and certainly its not possible to have one build configuration which fits everyones personal taste.

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.

So XML configuration is fine then as long as it works?

depends. if you don't need to touch the xml, then the xml is fine with me. I just ignore it and be done with it. If I need to change the XML, then I hope that is not too big, does not use name spaces and that I don't have to introduce new ones.In the end XML is ok, if the file is small. Ever seen the XML of a complex svg graphic... Of course you can understand that somehow... you just waste so much time and you are better of with a GUI based tool instead of reading the plain text.

Or say hessian configuration driven system or rot13? All might work, but not everyone is going to be happy with how its done.

even a configuration available as only java bytecode will be fine as long as nobody needs to change it.

For me its more like code-style. Any style generally will work, so will any build tool, but not every developer is going to like your code-style and there certainly is no code-style that everyone likes. Its all personal preference na.

sure, but personal taste is higly influenced by things other people say and by perception as well as the things the management forces you to do. If your idol uses ant, then you may not consider a change to m2 even if you recognize it as better tool. I dislike XML very much, so I dislike tools where I have to write xml as well.

[...]

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.

I would say that what is important is the longevity of the build configuration over the lifetime of the project, in terms of functionality, maintainability and developer comprehension. In open-source, the needs of the many outweigh the needs of the one (yes, live long and prosper and all that too).

yes, but what are the needs of many... sometimes one is more important than many. Sometimes needs are not seen or ignored by "the many". Look at Groovy for example. There are many java programers having Java nearly as religion. Groovy gives them a nearly satanic look. And sometimes one of these simply tries Groovy and then sees that it is not bad at all and that he won't die from looking a bit more at it. Once you looked at other languages people start to learn principles Java does not have, they get a feeling of what could be and then they see that Java lacks things here and there. And depending on how much they like these lacking thins, they might even change their programming language and using Java might look as torture to them all of a sudden.

I can not tell if a build based on a programming language is better in the long term or if such a thing will end up in despair, but neither can you I think. The only other programming language based tools I heard of out there are Rake and Scons. But they are coming form the make/autoconf world - a dark place ;)

bye blackdrag