-----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 <[EMAIL PROTECTED]> 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: [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) iD8DBQFDKGr2K3h2CZwO/4URAkkIAJ48jtd/h76c+yxhoC4oMK6+5W+lTACdGjBn 0/5GTjHNGDgvycf6OXoDOkI= =ZjA6 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
