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 <[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
