maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark H. Wilkinson" <mhw-m2-...@kremvax.net>
Subject Re: Eclipse project dependencies and pom dependencies.
Date Mon, 17 Jan 2005 09:58:16 GMT
On Sun, 2005-01-16 at 23:20 -0500, Mauro Botelho wrote:
> I'm trying to get the eclipse plugin to link to projects in the
> workspace. Currently in 1.0.2 the user is forced to edit the pom to
> set a property. What bothers me with this approach is that someone
> else might not have the dependent project in his/her workspace, and
> now his build is broken.

I'd agree - the eclipse.dependency approach was a bit of a hack in the
first place. One of the main problems, as you say, is that the
eclipse.dependency property represents information about a user's
workspace, but it's stored in a file that is shared through the scm
system.

> What I'd like to do is allow the user to set it outside of the pom. I
> have it working now using an external properties file with a mapping
> between the artifact (group:artifact:type:version) to a project in the
> workspace.

That's the kind of approach I'd been thinking about too. However I was
thinking that it would be reasonable to have maven manage a project
source map itself because there are a number of plugins that should hook
into it. For example, I think we're aiming to allow maven to checkout
the source tree given the information in the POM - it'd be logical for
this event to add information to the project source map. That said, it's
important that the source map is something that the user can understand
and modify - we can't guarantee that maven will cover every single 

The fact that a particular source tree is also open in eclipse could be
a property stored in the project source map. Or we could just check for
the presence of a <srcdir>/.project file.

As for representing the project source map, we currently have a kind-of
convention that ${local-repo}/${group-id}/src/${artifact-id}.zip can
contain a source tree archive. How about extending this so that
${local-repo}/${group-id}/src/${artifact-id}.local
and
${local-repo}/${group-id}/src/${artifact-id}-${version}.local
could be files that contain the path to the local copy of the source
tree? The first version would be used for source trees that were
tracking HEAD while the second would be used for source trees containing
specific artifact versions.

-Mark.


Mime
View raw message