You are viewing a plain text version of this content. The canonical link for it is here.
Posted to m2-dev@maven.apache.org by Mauro Botelho <ma...@gmail.com> on 2005/01/17 05:20:36 UTC
Eclipse project dependencies and pom dependencies.
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.
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. I was wondering if there's a way to make the same thing
without creating a new properties file. In other words, allow the user
to "alter" the dependencies to set the eclipse project in his
~/build.properties for example.
I read this: http://maven.apache.org/m2/configuration-management.html,
but it didn't really help much. I tried to follow what the code is
doing, but I haven't been smart enough to figure it out by myself...
Mauro
Re: Eclipse project dependencies and pom dependencies.
Posted by Mauro Botelho <ma...@gmail.com>.
In a chat session a few days ago, we found out that Mark's suggestion
wouldn't cover all the use cases. Trygvis suggested a case where the
user actually has 2 copies of the source code locally, one being cvs
head and the other one being a working copy.
Another point that was brought up was that a lot of the functionality
available in the eclipse plug in will probably be available in tools
like mevenide.
What I'd like to know though is if I should go ahead and implement his solution.
I agree that mevenide will probably implement a better solution, but
I'd rather something that covers 50% of the use cases when m2 is
launched than nothing at all. Unless mevenide is already working on a
version for m2... Does anybody know anything about that?
Mauro
Re: Eclipse project dependencies and pom dependencies.
Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2005-01-17 at 10:23, Mark H. Wilkinson wrote:
> On Mon, 2005-01-17 at 06:05 -0800, Jason van Zyl wrote:
> >
> > Look at the last section of this:
> >
> > http://cvs.apache.org/viewcvs.cgi/maven-components/maven-core/src/site/apt/configuration-management.apt?rev=1.4&view=auto
>
> Hmm; I'm not sure I follow that. Is the suggestion that all the user's
> source directories are organised into a tree similar in shape to the
> local repository?
Right, with some modifications to account for versions and directory
layouts like the trunk/branches/tags used with SVN.
> -Mark.
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Eclipse project dependencies and pom dependencies.
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Mon, 2005-01-17 at 06:05 -0800, Jason van Zyl wrote:
>
> Look at the last section of this:
>
> http://cvs.apache.org/viewcvs.cgi/maven-components/maven-core/src/site/apt/configuration-management.apt?rev=1.4&view=auto
Hmm; I'm not sure I follow that. Is the suggestion that all the user's
source directories are organised into a tree similar in shape to the
local repository?
-Mark.
Re: Eclipse project dependencies and pom dependencies.
Posted by Jason van Zyl <jv...@maven.org>.
On Mon, 2005-01-17 at 01:58, Mark H. Wilkinson wrote:
> 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.
Look at the last section of this:
http://cvs.apache.org/viewcvs.cgi/maven-components/maven-core/src/site/apt/configuration-management.apt?rev=1.4&view=auto
--
jvz.
Jason van Zyl
jason@maven.org
http://maven.apache.org
happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...
-- Thoreau
Re: Eclipse project dependencies and pom dependencies.
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
On Mon, 2005-01-17 at 10:06 -0500, Mauro Botelho wrote:
> I think this is not what you are proposing, but I want to put here
> just to make sure we both agree on the point :). By having maven
> checkout src code automatically, I'd be able to clearly specify which
> projects I want the source code, right? In other words, when working
> with Continuum, I want src code for Plexus and perhaps m2, but not for
> hibernate, prevayler, etc...
I wasn't necessarily meaning that maven would check out all the
dependencies' source trees automatically, but that's certainly an
option. In that case, yes, you'd want the checkout process to be
controlled by the user so they can decide when to prune the dependency
graph. And I think we should only do that if the user ran a 'check out
the source code' goal. 'maven eclipse:eclipse' shouldn't check new
source code out.
To begin with it would suffice to have the user check out each of the
projects they are working on separately (e.g. they'd check out plexus
and maven-components). Having done this the source map could be used to
stitch together a complete view of how much source code is locally
available, and in what form.
> The idea of using the src map is a good idea, but here's the situation
> I'm trying to solve, and you might have a better way of solving the
> problem :). When working with m2 or Continuum code, the src tree is
> composed of multiple small projects. So the approach I'm taking right
> now is to create one eclipse project to each pom in the src tree, and
> if the dependency happens to be in the same "project" I'll then simply
> map it to an "eclipse project".
I'm with you so far. For clarity, the problem comes down to deciding
whether a dependency listed in the pom should become a jar file
dependency or a project dependency in the Eclipse .classpath file. The
possible solutions we have so far are:
1. Add <eclipse.dependency> properties to the pom. Used by maven 1,
but doesn't work well with shared projects.
2. Your current approach: decide whether the dependency is in the
same "project". I'm not exactly sure how you decide this though:
are you meaning that the groupIds of the artifacts are the same?
That the projects are in a child directory of the current
directory?
3. Test whether we have a copy of the source tree lying around
somewhere. This requires us to be able to map from a dependency
to a directory containing the source tree (the source map). We
might also finish up deciding some projects are Eclipse projects
when the user doesn't actually have them open in Eclipse.
4. Test for the existence of a .project in the dependent's source
directory. Builds on option 3, but uses a heuristic to decide
whether the user is planning to open the project in Eclipse. Not
a reliable test though: people sometimes check the .project file
into CVS for example.
5. Test for properties attached to the dependency in the source
map. Builds on option 3, but requires the user to explicitly
state which projects in the source map they actually have open
in Eclipse. Probably a bit too onerous to be practical.
6. My friend Kris Brown has an extension to the maven 1 Eclipse
plugin that checks for the existence of a directory called
${workspace}/.metadata/.plugins/org.eclipse.core.resources/.projects/${project} This is a reliable test to see whether the project exists in an Eclipse workspace. Doesn't work as well if the user has multiple workspaces. A similar solution might not be practical in other IDEs either.
I'm not sure which is the best approach. I'd tend towards options 3 or
4, although option 6 might work better for Eclipse. Would be good to
have an approach which could work for other IDEs.
> If we follow your approach, wouldn't
> we end up with two copies of the src code? One in the repository and
> another in the eclipse workspace? Or are you suggesting that we make
> them one and the same?
No, we'd just have one copy of the code, the one that the user checked
out originally. I was suggesting adding files to the repository that
record the location of source trees, but the source trees themselves
would be checked out where the user wanted them. For example, a
hypothetical user session might be:
$ cd ~/src
$ m2 -Dgroup=plexus -Dartifact=plexus-root scm:checkout
[maven downloads a copy of the plexus-root pom if necessary,
then checks out a source tree from the repository in the scm
connection element. It also creates source map entries for each
newly checked out project.]
$ cat ~/.m2/repository/plexus/src/plexus-root.local
/home/mhw/src/plexus
$ cat ~/.m2/repository/plexus/src/plexus-container-default.local
/home/mhw/src/plexus/plexus-containers/plexus-container-default
$ cd maven-components/maven-core
[assuming that maven-components was already checked out]
$ m2 eclipse:eclipse
[from plexus-container-artifact dependency the Eclipse plugin
looks for
~/.m2/repository/plexus/src/plexus-container-artifact.local
As this file exists we add plexus-container-artifact as a
project dependency in the .classpath file.]
I'm assuming we're just using option 3 here as it's simpler. Option 4
(checking for the .project file in the source tree) would have required
the user to do 'm2 eclipse:eclipse' in the plexus-container-artifact
project first.
Related to this final point, being able to map from a dependency to a
source directory would allow us to build goals across the transitive
closure of dependent projects that are available locally. So we could
imagine running 'm2 -d eclipse:eclipse' from the maven-core directory
and having the goal executed for the plexus artifacts as well. A depth-
first traversal of the dependency graph would get all the .project files
created in the right order for option 4 to work, too.
-Mark (who seems to be thinking in graphs lately!)
Re: Eclipse project dependencies and pom dependencies.
Posted by Mauro Botelho <ma...@gmail.com>.
I like the approach you gave, but I'm not sure if it would work 100%
of the times...
I think this is not what you are proposing, but I want to put here
just to make sure we both agree on the point :). By having maven
checkout src code automatically, I'd be able to clearly specify which
projects I want the source code, right? In other words, when working
with Continuum, I want src code for Plexus and perhaps m2, but not for
hibernate, prevayler, etc...
The idea of using the src map is a good idea, but here's the situation
I'm trying to solve, and you might have a better way of solving the
problem :). When working with m2 or Continuum code, the src tree is
composed of multiple small projects. So the approach I'm taking right
now is to create one eclipse project to each pom in the src tree, and
if the dependency happens to be in the same "project" I'll then simply
map it to an "eclipse project". If we follow your approach, wouldn't
we end up with two copies of the src code? One in the repository and
another in the eclipse workspace? Or are you suggesting that we make
them one and the same? Hm, actually that wouln't work since the moment
you need to do something with some other project, you might end up
losing your changes (by accident of course :-D).
Mauro
On Mon, 17 Jan 2005 09:58:16 +0000, Mark H. Wilkinson
<mh...@kremvax.net> wrote:
> 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.
>
>
Re: Eclipse project dependencies and pom dependencies.
Posted by "Mark H. Wilkinson" <mh...@kremvax.net>.
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.