You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Ashley Williams <ag...@mac.com> on 2005/09/14 13:28:34 UTC
[m2] whether to use ant
I'm currently trying to autodeploy my webapp to tomcat at the end of
my m2 install, and as far as I can tell there are two ways of doing
this:
1. Use the maven tomcat plugin beta. I tried this and had a devil of
a time trying to get it to work - not familiar with it, immature code
etc
2. Use the tomcat ant task. I believe there has been talk here about
the maven ant plugin which would enable me to just call the more
mature ant task that I already know.
So I suppose the question is more general: why would I ever use
custom maven plugins when I can just call the familiar ant equivalent
from within Maven? I'm believe I understand the benefits of the
transitive library dependencies and the built in build lifecycle but
I don't have a clear idea in my mind when it comes to how best to use
and write plugins.
Thanks
-AW
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Ashley Williams <ag...@mac.com>.
They should be waking up right about now ;)
On 14 Sep 2005, at 15:05, Mark Hobson wrote:
> Ant tasks do potentially come
> with fair amount of ant-related baggage though since they're not
> strictly pojos.. what do the developers think?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Hobson wrote:
| On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
| [snip]
|
|>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.
|
| [snip]
|
| Although ant tasks could theoretically be supported natively alongside
| mojos they will still need to be configured. Mojo's can deduce a lot
| about their project environment from the POM and other plugin config,
| and hence their configuration is minimal, whereas ant tasks typically
| allow every parameter to be tweaked.
|
| So even if you were to use, say, the tomcat ant task natively within
| maven, you'd still need to manually configure the location of the war
| file (depending on the war plugin config), context xml, etc. since ant
| tasks know nothing about the maven project layout. Simple
| configuration could be done via the plugin xml, but more complex ones
| would probably require a maven plugin wrapper.
In the current setup, a small convenience API could help with using Ant
tasks programmatically, which means simply setting up a mojo with
parameters that you feed into the programmatic construction and
configuration of the task...then you feed that task into the convenience
API to execute it. I've developed that convenience API for a client, but
have to make sure it's okay before I release it for public consumption.
But this works well for simple Ant API calls.
For more complex Ant-based processes, it would be nicer to have an
adaptor that would essentially wrap an Ant script fragment as a mojo,
complete with parameters and all...then the mojo would setup the Project
property substitutions for those parameters, and delegate execution to
the scriptlet, possibly either calling a target within a plugin-wide
script resource, or else calling a mojo-specific script resource. This
is what I'm currently planning, but it's going to be awhile before I can
get it done.
John
|
| Mark
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKDz4K3h2CZwO/4URAgWIAJoDWsXO8ol7n00N0Jude0mwXXZp2ACgiXeZ
1qiBj6sZkgv0DnnRJx8oI8g=
=hN2V
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Mark Hobson <ma...@gmail.com>.
On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
[snip]
> 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.
[snip]
Although ant tasks could theoretically be supported natively alongside
mojos they will still need to be configured. Mojo's can deduce a lot
about their project environment from the POM and other plugin config,
and hence their configuration is minimal, whereas ant tasks typically
allow every parameter to be tweaked.
So even if you were to use, say, the tomcat ant task natively within
maven, you'd still need to manually configure the location of the war
file (depending on the war plugin config), context xml, etc. since ant
tasks know nothing about the maven project layout. Simple
configuration could be done via the plugin xml, but more complex ones
would probably require a maven plugin wrapper.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Actually, that's the same basic way I use it. I have always planned to
dig into the eclipse plugin and add this functionality, as it's
essentially useless for me too. :)
However, as yet I haven't even looked at the eclipse plugin, personally.
I'll try to set aside some time to at least assess this type of change.
- -j
Ashley Williams wrote:
| John, don't know if you read my earlier post today on a suggestion for
| eclipse. Wasn't a great post, but it probably got lost in the
| discussion on Ant. To summarize, I'm having a lot of success with one
| project, consisting of one source folder per artifact project. So Maven
| itself would consist of a top level project called maven- components
| with lots of child source folders:
|
| maven-components
| maven-eclipse-plugin-src
| maven-core-src
| maven-site-src
|
| So even though there is a nested hierarchy going on in the source (eg
| plugins folder contains a pom and then a bunch of other plugin
| subfolders) I don't see any need for the eclipse project to be anything
| other than flat.
|
| If you needed to work on just the plugins on their own for example then
| you could create another eclipse project with just those children as
| source folders, checked straight out of svn so that you have a
| different branch - hence no overlapping source.
|
| So basically you can use eclipse project as a view on the source, one
| eclipse project per svn branch.
|
| On 14 Sep 2005, at 19:24, John Casey wrote:
|
| Some of the problems with the eclipse plugin are from an impedance
| mismatch. Eclipse doesn't allow nesting of projects, while that's the
| bread and butter for Maven. Therefore, for Eclipse users (like me), you
| have to sort of graft multiproject support onto the Eclipse approach by
| mapping all subproject srcdirs into a single monolithic Eclipse project,
| or by breaking out the subproject dirs into a flat layout, and
| creating/interlinking the corresponding Eclipse projects.
|
| Personally, I don't understand what the issue is with Eclipse and nested
| projects. But I agree, it needs some sort of resolution (or maybe two
| operational modes, as outlined above).
|
| -j
|
| Ashley Williams wrote:
| | I _totally_ agree and in my ever so humble opinion this should be
| made
| | the top priority for new features as I can't think of a bigger payoff
| | for what I guess is just writing a new flavor of Mojo. You would
| start
| | to see a serious number of users flock to Maven - familiarity is a
| | powerful tool, which is why Ivy is doing so well. Lets learn the
| | Microsoft lesson of embrace and extend!
| |
| | 1. Embrace Ant - loads of people use Ant
| | 2. Think through the eclipse plugin a lot more - loads of people use
| | Eclipse
| |
| | What a great story that would be to take onto your random new project.
| |
| | On 14 Sep 2005, at 17:08, John Casey wrote:
| |
| | Actually, what I'd really like to see in the future is the convergence
| | of Ant APIs and Maven build process to form one ultra-rich
| platform for
| | running builds and developing build plugins. If you still want to run
| | Ant scripts, you have an optional ant-build jar or somesuch that
| you can
| | include in your classpath...otherwise, Ant would become a utility
| | project in many ways.
| |
| | My 2-cents.
| |
| | -john
| |
| | Mark Hobson wrote:
| | | On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
| | |
| | |>Mark, I see what you mean about autodeducing the war file with a
| pure
| | |>maven plugin. However wouldn't it be easier to write a mapping layer
| | |>that passes the maven war location to the ant task and any other
| | |>properties too?
| | |>
| | |>So instead of writing the tomcat plugin from scratch, you would
| | |>simply wrap the ant tomcat bean with a maven ant adapter together
| | |>with a property/xml file describing the map from maven to ant bean
| | |>properties.
| | |
| | | [snip]
| | |
| | | This is what John was describing above with regard to an ant
| adapter.
| | | I could have done this with the tomcat plugin, but after looking at
| | | the tomcat ant tasks I decided they were too tied in with ant. The
| | | core of the maven tomcat plugin is maven-independent
| | | (TomcatManager.java) and would ideally be shared between the maven
| | | plugin and the ant tasks.
| | |
| | | Mark
| | |
| | |
| ---------------------------------------------------------------------
| | | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| | | For additional commands, e-mail: users-help@maven.apache.org
| | |
| | |
| | |
| |>
| - ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
| |>
| |>
|
| | ---------------------------------------------------------------------
| | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| | For additional commands, e-mail: users-help@maven.apache.org
|
|
|
|>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
|>
|>
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKHjjK3h2CZwO/4URAuWiAJ4uCF5aaukXpiT5dOHyOIq+H0+GXQCdHgw+
+if/9sgpSR71KyJixAYEFMs=
=XRuN
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Ashley Williams <ag...@mac.com>.
John, don't know if you read my earlier post today on a suggestion
for eclipse. Wasn't a great post, but it probably got lost in the
discussion on Ant. To summarize, I'm having a lot of success with one
project, consisting of one source folder per artifact project. So
Maven itself would consist of a top level project called maven-
components with lots of child source folders:
maven-components
maven-eclipse-plugin-src
maven-core-src
maven-site-src
So even though there is a nested hierarchy going on in the source (eg
plugins folder contains a pom and then a bunch of other plugin
subfolders) I don't see any need for the eclipse project to be
anything other than flat.
If you needed to work on just the plugins on their own for example
then you could create another eclipse project with just those
children as source folders, checked straight out of svn so that you
have a different branch - hence no overlapping source.
So basically you can use eclipse project as a view on the source, one
eclipse project per svn branch.
On 14 Sep 2005, at 19:24, John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Some of the problems with the eclipse plugin are from an impedance
> mismatch. Eclipse doesn't allow nesting of projects, while that's the
> bread and butter for Maven. Therefore, for Eclipse users (like me),
> you
> have to sort of graft multiproject support onto the Eclipse
> approach by
> mapping all subproject srcdirs into a single monolithic Eclipse
> project,
> or by breaking out the subproject dirs into a flat layout, and
> creating/interlinking the corresponding Eclipse projects.
>
> Personally, I don't understand what the issue is with Eclipse and
> nested
> projects. But I agree, it needs some sort of resolution (or maybe two
> operational modes, as outlined above).
>
> - -j
>
> Ashley Williams wrote:
> | I _totally_ agree and in my ever so humble opinion this should
> be made
> | the top priority for new features as I can't think of a bigger
> payoff
> | for what I guess is just writing a new flavor of Mojo. You would
> start
> | to see a serious number of users flock to Maven - familiarity is a
> | powerful tool, which is why Ivy is doing so well. Lets learn the
> | Microsoft lesson of embrace and extend!
> |
> | 1. Embrace Ant - loads of people use Ant
> | 2. Think through the eclipse plugin a lot more - loads of people use
> | Eclipse
> |
> | What a great story that would be to take onto your random new
> project.
> |
> | On 14 Sep 2005, at 17:08, John Casey wrote:
> |
> | Actually, what I'd really like to see in the future is the
> convergence
> | of Ant APIs and Maven build process to form one ultra-rich
> platform for
> | running builds and developing build plugins. If you still want to
> run
> | Ant scripts, you have an optional ant-build jar or somesuch that
> you can
> | include in your classpath...otherwise, Ant would become a utility
> | project in many ways.
> |
> | My 2-cents.
> |
> | -john
> |
> | Mark Hobson wrote:
> | | On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
> | |
> | |>Mark, I see what you mean about autodeducing the war file with
> a pure
> | |>maven plugin. However wouldn't it be easier to write a mapping
> layer
> | |>that passes the maven war location to the ant task and any other
> | |>properties too?
> | |>
> | |>So instead of writing the tomcat plugin from scratch, you would
> | |>simply wrap the ant tomcat bean with a maven ant adapter together
> | |>with a property/xml file describing the map from maven to ant bean
> | |>properties.
> | |
> | | [snip]
> | |
> | | This is what John was describing above with regard to an ant
> adapter.
> | | I could have done this with the tomcat plugin, but after
> looking at
> | | the tomcat ant tasks I decided they were too tied in with ant.
> The
> | | core of the maven tomcat plugin is maven-independent
> | | (TomcatManager.java) and would ideally be shared between the maven
> | | plugin and the ant tasks.
> | |
> | | Mark
> | |
> | |
> ---------------------------------------------------------------------
> | | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | | For additional commands, e-mail: users-help@maven.apache.org
> | |
> | |
> | |
> |>
> -
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> |>
> |>
>
> |
> ---------------------------------------------------------------------
> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDKGr2K3h2CZwO/4URAkkIAJ48jtd/h76c+yxhoC4oMK6+5W+lTACdGjBn
> 0/5GTjHNGDgvycf6OXoDOkI=
> =ZjA6
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some of the problems with the eclipse plugin are from an impedance
mismatch. Eclipse doesn't allow nesting of projects, while that's the
bread and butter for Maven. Therefore, for Eclipse users (like me), you
have to sort of graft multiproject support onto the Eclipse approach by
mapping all subproject srcdirs into a single monolithic Eclipse project,
or by breaking out the subproject dirs into a flat layout, and
creating/interlinking the corresponding Eclipse projects.
Personally, I don't understand what the issue is with Eclipse and nested
projects. But I agree, it needs some sort of resolution (or maybe two
operational modes, as outlined above).
- -j
Ashley Williams wrote:
| I _totally_ agree and in my ever so humble opinion this should be made
| the top priority for new features as I can't think of a bigger payoff
| for what I guess is just writing a new flavor of Mojo. You would start
| to see a serious number of users flock to Maven - familiarity is a
| powerful tool, which is why Ivy is doing so well. Lets learn the
| Microsoft lesson of embrace and extend!
|
| 1. Embrace Ant - loads of people use Ant
| 2. Think through the eclipse plugin a lot more - loads of people use
| Eclipse
|
| What a great story that would be to take onto your random new project.
|
| On 14 Sep 2005, at 17:08, John Casey wrote:
|
| Actually, what I'd really like to see in the future is the convergence
| of Ant APIs and Maven build process to form one ultra-rich platform for
| running builds and developing build plugins. If you still want to run
| Ant scripts, you have an optional ant-build jar or somesuch that you can
| include in your classpath...otherwise, Ant would become a utility
| project in many ways.
|
| My 2-cents.
|
| -john
|
| Mark Hobson wrote:
| | On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
| |
| |>Mark, I see what you mean about autodeducing the war file with a pure
| |>maven plugin. However wouldn't it be easier to write a mapping layer
| |>that passes the maven war location to the ant task and any other
| |>properties too?
| |>
| |>So instead of writing the tomcat plugin from scratch, you would
| |>simply wrap the ant tomcat bean with a maven ant adapter together
| |>with a property/xml file describing the map from maven to ant bean
| |>properties.
| |
| | [snip]
| |
| | This is what John was describing above with regard to an ant adapter.
| | I could have done this with the tomcat plugin, but after looking at
| | the tomcat ant tasks I decided they were too tied in with ant. The
| | core of the maven tomcat plugin is maven-independent
| | (TomcatManager.java) and would ideally be shared between the maven
| | plugin and the ant tasks.
| |
| | Mark
| |
| | ---------------------------------------------------------------------
| | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| | For additional commands, e-mail: users-help@maven.apache.org
| |
| |
| |
|>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
|>
|>
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKGr2K3h2CZwO/4URAkkIAJ48jtd/h76c+yxhoC4oMK6+5W+lTACdGjBn
0/5GTjHNGDgvycf6OXoDOkI=
=ZjA6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Ashley Williams <ag...@mac.com>.
I _totally_ agree and in my ever so humble opinion this should be
made the top priority for new features as I can't think of a bigger
payoff for what I guess is just writing a new flavor of Mojo. You
would start to see a serious number of users flock to Maven -
familiarity is a powerful tool, which is why Ivy is doing so well.
Lets learn the Microsoft lesson of embrace and extend!
1. Embrace Ant - loads of people use Ant
2. Think through the eclipse plugin a lot more - loads of people use
Eclipse
What a great story that would be to take onto your random new project.
On 14 Sep 2005, at 17:08, John Casey wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Actually, what I'd really like to see in the future is the convergence
> of Ant APIs and Maven build process to form one ultra-rich platform
> for
> running builds and developing build plugins. If you still want to run
> Ant scripts, you have an optional ant-build jar or somesuch that
> you can
> include in your classpath...otherwise, Ant would become a utility
> project in many ways.
>
> My 2-cents.
>
> - -john
>
> Mark Hobson wrote:
> | On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
> |
> |>Mark, I see what you mean about autodeducing the war file with a
> pure
> |>maven plugin. However wouldn't it be easier to write a mapping layer
> |>that passes the maven war location to the ant task and any other
> |>properties too?
> |>
> |>So instead of writing the tomcat plugin from scratch, you would
> |>simply wrap the ant tomcat bean with a maven ant adapter together
> |>with a property/xml file describing the map from maven to ant bean
> |>properties.
> |
> | [snip]
> |
> | This is what John was describing above with regard to an ant
> adapter.
> | I could have done this with the tomcat plugin, but after looking at
> | the tomcat ant tasks I decided they were too tied in with ant. The
> | core of the maven tomcat plugin is maven-independent
> | (TomcatManager.java) and would ideally be shared between the maven
> | plugin and the ant tasks.
> |
> | Mark
> |
> |
> ---------------------------------------------------------------------
> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDKErwK3h2CZwO/4URAnN4AJ9ZP5CnhC7o7lxgo7YPe+fnx3HRXQCeLdsk
> 44/Nrx+DvOaOjOS9HKxT1gk=
> =fRSk
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Actually, what I'd really like to see in the future is the convergence
of Ant APIs and Maven build process to form one ultra-rich platform for
running builds and developing build plugins. If you still want to run
Ant scripts, you have an optional ant-build jar or somesuch that you can
include in your classpath...otherwise, Ant would become a utility
project in many ways.
My 2-cents.
- -john
Mark Hobson wrote:
| On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
|
|>Mark, I see what you mean about autodeducing the war file with a pure
|>maven plugin. However wouldn't it be easier to write a mapping layer
|>that passes the maven war location to the ant task and any other
|>properties too?
|>
|>So instead of writing the tomcat plugin from scratch, you would
|>simply wrap the ant tomcat bean with a maven ant adapter together
|>with a property/xml file describing the map from maven to ant bean
|>properties.
|
| [snip]
|
| This is what John was describing above with regard to an ant adapter.
| I could have done this with the tomcat plugin, but after looking at
| the tomcat ant tasks I decided they were too tied in with ant. The
| core of the maven tomcat plugin is maven-independent
| (TomcatManager.java) and would ideally be shared between the maven
| plugin and the ant tasks.
|
| Mark
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKErwK3h2CZwO/4URAnN4AJ9ZP5CnhC7o7lxgo7YPe+fnx3HRXQCeLdsk
44/Nrx+DvOaOjOS9HKxT1gk=
=fRSk
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Mark Hobson <ma...@gmail.com>.
On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
> Mark, I see what you mean about autodeducing the war file with a pure
> maven plugin. However wouldn't it be easier to write a mapping layer
> that passes the maven war location to the ant task and any other
> properties too?
>
> So instead of writing the tomcat plugin from scratch, you would
> simply wrap the ant tomcat bean with a maven ant adapter together
> with a property/xml file describing the map from maven to ant bean
> properties.
[snip]
This is what John was describing above with regard to an ant adapter.
I could have done this with the tomcat plugin, but after looking at
the tomcat ant tasks I decided they were too tied in with ant. The
core of the maven tomcat plugin is maven-independent
(TomcatManager.java) and would ideally be shared between the maven
plugin and the ant tasks.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Ashley Williams <ag...@mac.com>.
Mark, I see what you mean about autodeducing the war file with a pure
maven plugin. However wouldn't it be easier to write a mapping layer
that passes the maven war location to the ant task and any other
properties too?
So instead of writing the tomcat plugin from scratch, you would
simply wrap the ant tomcat bean with a maven ant adapter together
with a property/xml file describing the map from maven to ant bean
properties. That way if you didn't specify the war file in the
configuration section, maven would pass in the repository war file
instead. So in practice the maven team would only have to drop in a
resource file in the maven source code for each ant task that it
wanted to support:
<ant-adapter>
<task>org.apache.optional.TomcatTask</task>
<property-maps>
<map>
<maven>project.artifact.location</maven>
<ant>tomcat.file</ant>
</map>
.....
</property-maps>
</ant-adapter>
(Yes totally made up names, but hopefully you get the picture)
The adapter framework would then create the appropriate adapter bean
on the fly.
On 14 Sep 2005, at 15:53, John Casey wrote:
> -----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 <ag...@mac.com> 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: users-unsubscribe@maven.apache.org
> | | For additional commands, e-mail: users-help@maven.apache.org
> | |
> | |
> | |
> |>
> -
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> |>
> |>
>
> |
> ---------------------------------------------------------------------
> | To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDKDmHK3h2CZwO/4URAva7AJ4ssPFkZ6QJy1nrestc/MCoN5b6mACeLt3R
> VNj6RkgJ+RUUTv63hcL85XM=
> =5bYz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by John Casey <jd...@commonjava.org>.
-----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 <ag...@mac.com> 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: users-unsubscribe@maven.apache.org
| | For additional commands, e-mail: users-help@maven.apache.org
| |
| |
| |
|>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
|>
|>
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKDmHK3h2CZwO/4URAva7AJ4ssPFkZ6QJy1nrestc/MCoN5b6mACeLt3R
VNj6RkgJ+RUUTv63hcL85XM=
=5bYz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Ashley Williams <ag...@mac.com>.
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 <ag...@mac.com> 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: users-unsubscribe@maven.apache.org
> | For additional commands, e-mail: users-help@maven.apache.org
> |
> |
> |
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFDKC63K3h2CZwO/4URAnOcAJ40dn+ISI8/L1xWbf846Ga0hI4ZGwCghq9P
> 5kVz+FFgulfRSmi22O3aIaA=
> =TIMv
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by John Casey <jd...@commonjava.org>.
-----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. 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.
If someone wants a project, I can give help on this, since I did a
similar adaptor for marmalade. :)
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 <ag...@mac.com> 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: users-unsubscribe@maven.apache.org
| For additional commands, e-mail: users-help@maven.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDKC63K3h2CZwO/4URAnOcAJ40dn+ISI8/L1xWbf846Ga0hI4ZGwCghq9P
5kVz+FFgulfRSmi22O3aIaA=
=TIMv
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Mark Hobson <ma...@gmail.com>.
On 14/09/05, Ashley Williams <ag...@mac.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Ashley Williams <ag...@mac.com>.
I'll write a separate post for tomcat
It's probably that I haven't spent enough time writing maven plugins.
However from this list I've been considering Maven plugins as follows
A) they are things that should be separate from Maven, therefore
should be self contained and shouldn't ask about the environment
B) related to this, environment should be strings and numbers etc,
and only passed in via @parameter annotations
C) Which makes ant tasks ideal. You can pass parameters to them and
they are certainly independent from Maven
D) How long will it take to replace all the ant tasks that everyone
uses? Will they all get replaced? If there is just one that isn't and
I need it, the docs for antrun suggest I'm doing something that is
against the spirit of Maven and that I should rewrite it asap (might
not even be my own source code).
Just to fabricate a 'real-world' example, imagine that I need to send
a mail message when my build has been successful. Well I already know
the ant mail task, so here's what I would normally call:
<mail mailhost="smtp.myisp.com" mailport="1025" subject="Test build">
<from address="config@myisp.com"/>
<replyto address="me@myisp.com"/>
<to address="all@xyz.com"/>
<message>${project.name} has installed</message>
</mail>
However with Maven why can't I write something like this:
(as you can see I'm not proposing we inline ant tasks like the antrun
plugin)
<plugin>
<groupId>ant</groupId> ///////MADE UP
<artifactId>core</artifactId>
<version>1.0</version>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>mail</goal> /////////// NAME OF
ANT TASK
</goals>
</execution>
</executions>
<configuration> ///////////// TAGS COPIED FROM ANT TASK
<from><address>config@myisp.com</address></from>
<replyto><address>me@myisp.com</address></replyto>
<to><address>all@xyz.com</address></to>
<message>${project.name} has installed</
message> /////////USING A MAVEN PROP!!
</configuration>
</plugin>
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.
A couple of inline comments below...
Thanks
-AW
On 14 Sep 2005, at 13:16, Mark Hobson wrote:
> Hi Ashley,
>
> I would see the advantages of using a Maven-specific plugin rather
> than an ant-based one as being:
>
> * Reuse of ant targets - not having to specify repeated ant tasks over
> many POMs (one of the main reasons for the existence of Maven itself)
>
> * Tighter integration with the Maven build process - Maven plugins can
> reuse POM and other plugin configuration themselves, whereas an
> antrun-based alternative would have to repeatedly configure it's tasks
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.
> * Minimal configuration required (as a result of the above)
>
> * 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)
> What problems were you having with the tomcat plugin? I'm using it on
> a daily basis and have no issues. Admittedly some online
> documentation would help, but I think the mojo.codehaus.org guys will
> be setting up deployed sites and binaries soon.
>
> Cheers,
>
> Mark
>
> On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
>
>> I'm currently trying to autodeploy my webapp to tomcat at the end of
>> my m2 install, and as far as I can tell there are two ways of doing
>> this:
>>
>> 1. Use the maven tomcat plugin beta. I tried this and had a devil of
>> a time trying to get it to work - not familiar with it, immature code
>> etc
>> 2. Use the tomcat ant task. I believe there has been talk here about
>> the maven ant plugin which would enable me to just call the more
>> mature ant task that I already know.
>>
>> So I suppose the question is more general: why would I ever use
>> custom maven plugins when I can just call the familiar ant equivalent
>> from within Maven? I'm believe I understand the benefits of the
>> transitive library dependencies and the built in build lifecycle but
>> I don't have a clear idea in my mind when it comes to how best to use
>> and write plugins.
>>
>> Thanks
>> -AW
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] tomcat plugin problems
Posted by Ashley Williams <ag...@mac.com>.
Should get my environment back from Ivy (another cool product!) today
so I will be in a position to recreate the problem.
On 14 Sep 2005, at 14:37, Mark Hobson wrote:
> The tomcat goals don't currently bind themselves to the lifecycle, so
> you have to invoke them explicity for them to run. Only the deploy
> and redeploy goals use the @execute phase="package" to ensure that the
> lifecycle has been completed up to the package phase before execution.
> The other goals are standalone and don't require the project in any
> state.
>
> This means that a tomcat:deploy will perform an implicit "m2 package"
> before deploying the war, thus ensuring the latest codebase is
> deployed. I'd be interested in what problems you had in order for you
> to modify the annotations? Were you running the plugin with alpha-3
> or beta-1?
>
> Mark
>
> On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
>
>> Don't recall the tomcat exception (went away when I rebuild "@execute
>> phase" to "@phase") and don't mind waiting for binary + better docs.
>>
>> However I do try to shoehorn a few things after the install task such
>> as deploying a webapp to tomcat. So is this a summary of the build
>> lifecycle?
>>
>> compile......package......install....[ANYTHING GOES]
>>
>> That's fine if it is but I just want to make sure I'm making full use
>> of the lifecycle.
>>
>> Thanks
>> -AW
>>
>> On 14 Sep 2005, at 13:16, Mark Hobson wrote:
>>
>>
>>> Hi Ashley,
>>>
>>> I would see the advantages of using a Maven-specific plugin rather
>>> than an ant-based one as being:
>>>
>>> * Reuse of ant targets - not having to specify repeated ant tasks
>>> over
>>> many POMs (one of the main reasons for the existence of Maven
>>> itself)
>>>
>>> * Tighter integration with the Maven build process - Maven
>>> plugins can
>>> reuse POM and other plugin configuration themselves, whereas an
>>> antrun-based alternative would have to repeatedly configure it's
>>> tasks
>>>
>>> * Minimal configuration required (as a result of the above)
>>>
>>> * No ant dependencies or ant-based exceptions
>>>
>>> What problems were you having with the tomcat plugin? I'm using
>>> it on
>>> a daily basis and have no issues. Admittedly some online
>>> documentation would help, but I think the mojo.codehaus.org guys
>>> will
>>> be setting up deployed sites and binaries soon.
>>>
>>> Cheers,
>>>
>>> Mark
>>>
>>> On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
>>>
>>>
>>>> I'm currently trying to autodeploy my webapp to tomcat at the
>>>> end of
>>>> my m2 install, and as far as I can tell there are two ways of doing
>>>> this:
>>>>
>>>> 1. Use the maven tomcat plugin beta. I tried this and had a
>>>> devil of
>>>> a time trying to get it to work - not familiar with it, immature
>>>> code
>>>> etc
>>>> 2. Use the tomcat ant task. I believe there has been talk here
>>>> about
>>>> the maven ant plugin which would enable me to just call the more
>>>> mature ant task that I already know.
>>>>
>>>> So I suppose the question is more general: why would I ever use
>>>> custom maven plugins when I can just call the familiar ant
>>>> equivalent
>>>> from within Maven? I'm believe I understand the benefits of the
>>>> transitive library dependencies and the built in build lifecycle
>>>> but
>>>> I don't have a clear idea in my mind when it comes to how best
>>>> to use
>>>> and write plugins.
>>>>
>>>> Thanks
>>>> -AW
>>>>
>>>> -------------------------------------------------------------------
>>>> --
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] tomcat plugin problems
Posted by Mark Hobson <ma...@gmail.com>.
The tomcat goals don't currently bind themselves to the lifecycle, so
you have to invoke them explicity for them to run. Only the deploy
and redeploy goals use the @execute phase="package" to ensure that the
lifecycle has been completed up to the package phase before execution.
The other goals are standalone and don't require the project in any
state.
This means that a tomcat:deploy will perform an implicit "m2 package"
before deploying the war, thus ensuring the latest codebase is
deployed. I'd be interested in what problems you had in order for you
to modify the annotations? Were you running the plugin with alpha-3
or beta-1?
Mark
On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
> Don't recall the tomcat exception (went away when I rebuild "@execute
> phase" to "@phase") and don't mind waiting for binary + better docs.
>
> However I do try to shoehorn a few things after the install task such
> as deploying a webapp to tomcat. So is this a summary of the build
> lifecycle?
>
> compile......package......install....[ANYTHING GOES]
>
> That's fine if it is but I just want to make sure I'm making full use
> of the lifecycle.
>
> Thanks
> -AW
>
> On 14 Sep 2005, at 13:16, Mark Hobson wrote:
>
> > Hi Ashley,
> >
> > I would see the advantages of using a Maven-specific plugin rather
> > than an ant-based one as being:
> >
> > * Reuse of ant targets - not having to specify repeated ant tasks over
> > many POMs (one of the main reasons for the existence of Maven itself)
> >
> > * Tighter integration with the Maven build process - Maven plugins can
> > reuse POM and other plugin configuration themselves, whereas an
> > antrun-based alternative would have to repeatedly configure it's tasks
> >
> > * Minimal configuration required (as a result of the above)
> >
> > * No ant dependencies or ant-based exceptions
> >
> > What problems were you having with the tomcat plugin? I'm using it on
> > a daily basis and have no issues. Admittedly some online
> > documentation would help, but I think the mojo.codehaus.org guys will
> > be setting up deployed sites and binaries soon.
> >
> > Cheers,
> >
> > Mark
> >
> > On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
> >
> >> I'm currently trying to autodeploy my webapp to tomcat at the end of
> >> my m2 install, and as far as I can tell there are two ways of doing
> >> this:
> >>
> >> 1. Use the maven tomcat plugin beta. I tried this and had a devil of
> >> a time trying to get it to work - not familiar with it, immature code
> >> etc
> >> 2. Use the tomcat ant task. I believe there has been talk here about
> >> the maven ant plugin which would enable me to just call the more
> >> mature ant task that I already know.
> >>
> >> So I suppose the question is more general: why would I ever use
> >> custom maven plugins when I can just call the familiar ant equivalent
> >> from within Maven? I'm believe I understand the benefits of the
> >> transitive library dependencies and the built in build lifecycle but
> >> I don't have a clear idea in my mind when it comes to how best to use
> >> and write plugins.
> >>
> >> Thanks
> >> -AW
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] tomcat plugin problems
Posted by Ashley Williams <ag...@mac.com>.
Don't recall the tomcat exception (went away when I rebuild "@execute
phase" to "@phase") and don't mind waiting for binary + better docs.
However I do try to shoehorn a few things after the install task such
as deploying a webapp to tomcat. So is this a summary of the build
lifecycle?
compile......package......install....[ANYTHING GOES]
That's fine if it is but I just want to make sure I'm making full use
of the lifecycle.
Thanks
-AW
On 14 Sep 2005, at 13:16, Mark Hobson wrote:
> Hi Ashley,
>
> I would see the advantages of using a Maven-specific plugin rather
> than an ant-based one as being:
>
> * Reuse of ant targets - not having to specify repeated ant tasks over
> many POMs (one of the main reasons for the existence of Maven itself)
>
> * Tighter integration with the Maven build process - Maven plugins can
> reuse POM and other plugin configuration themselves, whereas an
> antrun-based alternative would have to repeatedly configure it's tasks
>
> * Minimal configuration required (as a result of the above)
>
> * No ant dependencies or ant-based exceptions
>
> What problems were you having with the tomcat plugin? I'm using it on
> a daily basis and have no issues. Admittedly some online
> documentation would help, but I think the mojo.codehaus.org guys will
> be setting up deployed sites and binaries soon.
>
> Cheers,
>
> Mark
>
> On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
>
>> I'm currently trying to autodeploy my webapp to tomcat at the end of
>> my m2 install, and as far as I can tell there are two ways of doing
>> this:
>>
>> 1. Use the maven tomcat plugin beta. I tried this and had a devil of
>> a time trying to get it to work - not familiar with it, immature code
>> etc
>> 2. Use the tomcat ant task. I believe there has been talk here about
>> the maven ant plugin which would enable me to just call the more
>> mature ant task that I already know.
>>
>> So I suppose the question is more general: why would I ever use
>> custom maven plugins when I can just call the familiar ant equivalent
>> from within Maven? I'm believe I understand the benefits of the
>> transitive library dependencies and the built in build lifecycle but
>> I don't have a clear idea in my mind when it comes to how best to use
>> and write plugins.
>>
>> Thanks
>> -AW
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] whether to use ant
Posted by Mark Hobson <ma...@gmail.com>.
Hi Ashley,
I would see the advantages of using a Maven-specific plugin rather
than an ant-based one as being:
* Reuse of ant targets - not having to specify repeated ant tasks over
many POMs (one of the main reasons for the existence of Maven itself)
* Tighter integration with the Maven build process - Maven plugins can
reuse POM and other plugin configuration themselves, whereas an
antrun-based alternative would have to repeatedly configure it's tasks
* Minimal configuration required (as a result of the above)
* No ant dependencies or ant-based exceptions
What problems were you having with the tomcat plugin? I'm using it on
a daily basis and have no issues. Admittedly some online
documentation would help, but I think the mojo.codehaus.org guys will
be setting up deployed sites and binaries soon.
Cheers,
Mark
On 14/09/05, Ashley Williams <ag...@mac.com> wrote:
> I'm currently trying to autodeploy my webapp to tomcat at the end of
> my m2 install, and as far as I can tell there are two ways of doing
> this:
>
> 1. Use the maven tomcat plugin beta. I tried this and had a devil of
> a time trying to get it to work - not familiar with it, immature code
> etc
> 2. Use the tomcat ant task. I believe there has been talk here about
> the maven ant plugin which would enable me to just call the more
> mature ant task that I already know.
>
> So I suppose the question is more general: why would I ever use
> custom maven plugins when I can just call the familiar ant equivalent
> from within Maven? I'm believe I understand the benefits of the
> transitive library dependencies and the built in build lifecycle but
> I don't have a clear idea in my mind when it comes to how best to use
> and write plugins.
>
> Thanks
> -AW
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org