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

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

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

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 ;-)

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

Yes you probably could write an Ant task in a <groovy> task, though I've never actually tried to do that.

So far I've not found this to be the case, with any build tool (make, ant, m1 or m2)... just a matter of learning how to make it work. And in many cases its more of a job of learning a new way which is more system friendly or simply living with it as it is, instead of just the way I want it.

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.

Depends a lot on how the original project is structured to start with. If you are hinting at the work I did as a POC for groovy-core, most of that restructuring was to show how a big codebase could be split up into smaller chunks. If you don't want smaller chunks, then most ant-ish structures will work, though as I have mentioned before not using the standard locations (like src/main/java, src/test/java, etc) for things means adding more overrides to the default pom.xml configuration. Not a big deal, but using the standard locations does simplify configuration.

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

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.

What structure are you referring too?

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

Sure, well any build tool can fall under this, if a programmer (good/ bad/whatever) mucks things up, well it will break. I was just pointing out that because most of the bits in pom.xml are not really code-like, but configuration-like, that its harder for folks to just put in random things, as usually when loading the pom.xml validation will barf. Like I can just litter my build with System.out.println() stuff, where in a pure code system I could certainly do that right? Sure you could define a ton of plugin executions to invoke groovy:execute and run a little System.out.println() script, but sounds insane to most programmers ;-)

So XML configuration is fine then as long as it works? Or say hessian configuration driven system or rot13? All might work, but not everyone is going to be happy with how its done.

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.

Build configuration IMO includes the build file, the structure, whatever is needed to take your source and produce your results.

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

Misuse or misunderstand will happen with any build tool if folks have not used it before or have not read the documentation. But since M2 is convention-driven (for the most part) if you know the convention, then you will have a much easier time figuring out what is actually going on in a build than you would otherwise. I could be wrong. Could be something mystical about M2 that just confuses the crap out of people. I can't tell, I know its internals far to well to be a judge of that.

For the record though, I was confused as hell by M1 way back when I was making complex Ant builds, and before that confused as hell by Ant when I was making Make builds. The transition from M1 to M2 was a little smoother but it still kinda confused me. So I can extrapolate and say that most/all build tools can be confusing at first, or that I'm just an idiot... or should drink less beer while trying out new build tools ;-)

Sure of course, I'm not suggesting that M2 gives folks grand clarity, only that I think there is a slight advantage due to its convention based muck.

As I mentioned earlier that is possible. But since groovy-core isn't quite conforming to the M2 standard, things like the location of main and test sources will need to be configured, location of resources needs to be configured, etc. You can do it sure, do I recommend it no. Its easier to just mv sources to src/main/java than it is to maintain the configuration of src/java, etc.

For splitting up the distributable artifacts into smaller chunks, that really should be implemented with a structure change, as the amount of custom configuration needed to manage poms, build jars, install jars, deploy jars, generate documentation, etc becomes quickly very very difficult to maintain. This is one of those learning things, that you can make the build configuration a whole lot simpler and easy to manage by simply following the conventions.

But by no means are you forced to do that... just the returns on the investment won't be very high, and will probably end up costing about the same as the current Ant build when you have to go and fix it in a few years.

--jason