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