I'm glad this is on the cards!
On 14 Sep 2005, at 15:07, John Casey wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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 ;)
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
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
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]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKC63K3h2CZwO/4URAnOcAJ40dn+ISI8/L1xWbf846Ga0hI4ZGwCghq9P
5kVz+FFgulfRSmi22O3aIaA=
=TIMv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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]
