-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comments inline...
Cheers, john Ashley Williams wrote: | I'm glad this is on the cards! | | On 14 Sep 2005, at 15:07, John Casey wrote: | | We've been considering writing a mojo language adaptor for Ant | scripts/scriptlets for awhile now...it's more a matter of available time | than anything else that this hasn't happened yet. | | |> Well if an ant adapter was worked upon, wouldn't this mean some of the |> existing plugin work is redundant, thus freeing up time? I mean fast |> forward to a time where we have an ant adapter - I can't see anyone |> choosing to use [maven-tomcat-plugin] over [maven-ant-adapter + |> ant-tomcat-task], which is well understood and tested to death. Correct |> me if there are any functional advantages in the pure maven plugins. | |> Please excuse me for being overly simplistic ;) It may make some of the plugin work a little redundant in the short term, but the real need here is to liberate the Ant tasks from the Ant build mechanisms, IMO. There are tons of really great APIs in the form of tasks...these do really generic things, and if the maven plugin effort produces an Ant-like API that doesn't have the tight coupling to a build system (I know, there are dangers of coupling to Maven too tightly), then it would be worthwhile. What might be equally worthwhile is to code in a separation between Ant and its APIs, where for example the Tomcat tasks would simply configure and execute a tomcat bean, which could be reused without incurring the extra weight of the Ant build system. | | I know there are quite | a few people out there who would love to see Maven able to take | advantage of the rich APIs that Ant provides, but we need to channel | this reuse into the development of Ant-based mojos, so we can escape the | single-use, copy-and-paste hell of the maven.xml days. | | |> Mark alluded to this copy and pasting / reconfiguring problem. Do you |> mean an Ant adapter would suffer from this? Never used M1 so maybe |> haven't met this problem The Ant adaptor I'm talking about will allow you to code reusable m2 plugins using Ant scripts or script fragments. The reusability problem occurs when you have an Ant script embedded within one POM, where it can't really be reached by other (non-inheriting) POMs. This is where the maven.xml phenomenon of cut-and-paste coding will start to recur. IMO it's also why we should be *very* careful when using the antrun plugin for m2...it encourages maven.xml style practices. The idea is that once you have a solution to a problem, you should always try to generalize that solution into a reusable component or suite of components - in our case, plugins - where it can be tested and reused without continually incurring the same maturity curve of testing/debugging over and over. | | If someone wants a project, I can give help on this, since I did a | similar adaptor for marmalade. :) | | |> The lack of javadocs + architecture docs is a serious blocker for |> getting folk to help with the code - at the moment I only see time- rich |> developers being able to help We know that documentation is currently inhibiting adoption of Maven 2, to say nothing of attracting developers to do work on the core (where the Ant language adaptor will have to be coded)...however, we don't currently have the spare cycles needed to write the doco! It's unfortunate, but we're only human... | |> Thanks |> - AW | | Otherwise, it's going to have to wait until things settle down a bit | more...sorry. | | -john | | Mark Hobson wrote: | | On 14/09/05, Ashley Williams <[EMAIL PROTECTED]> wrote: | | [snip] | | | |>Excuse the ill thought through syntax, especially when it comes to | |>the group/artifact/version values, but hopefully this would be | |>similar syntax as you'd use to configure any other plugin. And from | |>the point of view of a maven user, ie not plugin writer, it seems a | |>compelling use case. I'm not suggesting that custom plugins should be | |>written as ant targets but I am suggesting that maybe the existing | |>ant library tasks should be embraced as first class citizens in Maven | |>also. | |> | |>Maybe there is some aspect that I'm missing with the power of Maven | |>plugins, but it seems with with a little effort on a plugin decorator | |>for ant tasks, you could make maven instantly more powerful. | | | | | | I agree that given the vast number of ant tasks out there it does make | | sense to reuse them, although I would see this done as a proper maven | | plugin as opposed to using antrun. | | | | | |>A couple of inline comments below... | | | | [snip] | | | |>Not sure what the repeated configuration means - I express my | |>configuration section just once don't I? Hopefully Maven would make | |>things efficient under the hood. | | | | | | Sure, but only once in a POM. If multiple projects start requiring | | the antrun-supplied functionality then you'll end up cutting & pasting | | ant scripts between POMs, which kinda defeats the whole purpose of | | maven. | | | | | |>>* No ant dependencies or ant-based exceptions | |> | |>The point of my post is that this is not a good thing - I would like | |>Maven to know about ant (wrap exceptions if it pleases) | | | | | | So using ant tasks directly in place of mojos? I would have thought | | this could be achieveable in maven via plexus and custom plugin xml, | | but not sure about the politics of it. Ant tasks do potentially come | | with fair amount of ant-related baggage though since they're not | | strictly pojos.. what do the developers think? | | | | Mark | | | | --------------------------------------------------------------------- | | To unsubscribe, e-mail: [EMAIL PROTECTED] | | For additional commands, e-mail: [EMAIL PROTECTED] | | | | | | |> - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] |> |> | --------------------------------------------------------------------- | To unsubscribe, e-mail: [EMAIL PROTECTED] | For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDKDmHK3h2CZwO/4URAva7AJ4ssPFkZ6QJy1nrestc/MCoN5b6mACeLt3R VNj6RkgJ+RUUTv63hcL85XM= =5bYz -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
