-----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 <[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] | | | |> - --------------------------------------------------------------------- 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) iD8DBQFDKHjjK3h2CZwO/4URAuWiAJ4uCF5aaukXpiT5dOHyOIq+H0+GXQCdHgw+ +if/9sgpSR71KyJixAYEFMs= =XRuN -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
