maven-eclipse-plugin 2.6 project references

[Stephen Duncan Jr <st...@gmail.com>]

Amongst several other surprising changes in the 2.6 release of the
maven-eclipse-plugin, I'd like to explain on one change caused some
confusion for myself and other members of my development team.  I'm not sure
it's really a bug, or exactly what feature enhancement to file, so I'm
hoping this thread can help determine a better future outcome.

Background: We have many different components as individual maven projects,
no multi-project/reactor projects, and Hudson continuously building and
deploying SNAPSHOTs to Nexus.  The typical workflow for a developer would be
to check out any particular component they needed to work on, and they could
run 'mvn eclipse:eclipse' to get the classpath right, and to download the
latest versions of any dependent components (settings.xml defined the
repository with a updatePolicy of always).  If they wanted to make changes
to a dependent component locally, they'd make the changes, run mvn install,
and then refresh the project to get those changes.  This all worked without
any extra configuration of the eclipse plugin.  Also, the name of the
project in eclipse didn't necessarily match the artifactId in anyway;
typically it matched the folder in Subversion (which is sometimes, though
rarely, different from the artifactId), or the the name of the branch in
Subversion (artifactId-version, where version might be a SNAPSHOT, or be
something like 1.2.x).

With the eclipse plugin 2.6, it seems new work has been done to try to
identify other projects in the eclipse workspace, and use those as project
dependencies, instead of jar dependencies in the local repository.  To get
the workflow described above, I've gone ahead and configured (in our
corporate parent pom) the eclipse plugin to not do project references at
all.  However, I didn't have to specify that before (I think it only used to
affect reactor-builds), and therefore our team did get confused by the new
behavior.

When all SNAPSHOT dependencies were being downloaded from the repository,
the version was the timestamp version of the SNAPSHOT, and never matched a
project in the workspace, and so it behaved as before, so no problem.
However, once somebody installed a dependency locally, the version was just
-SNAPSHOT, so the eclipse plugin believed it found a match in the
workspace.  However, the name it tried to use for the project reference was
the artifactId, not the actual name of the project in eclipse, and therefore
the project showed up as broken in eclipse, due to the unsatisfied
dependency.

I think it would be better if the default went back to only doing project
references for reactor builds.  I also don't know if there's some better way
to figure out the right project name to use for the reference.  Even if our
dependency had been named to match the project reference, somebody working
on the branch may have gotten the WRONG project reference (the trunk would
have the artifactId, but the wrong version, the branch project name would be
the right version, but not match the expected name).

-- 
Stephen Duncan Jr
www.stephenduncanjr.com

Re: maven-eclipse-plugin 2.6 project references

[Arnaud HERITIER <ah...@gmail.com>]

Hi Stephen,
  Thx a lot for this feedback. I don't remember when and why  we did these
changes but I understand your problem. It seems that the autodiscovery of
projects dependencies in the workspace is activated by default. I think that
this feature should be deativated by default (First issue to open).
  The problem about projects naming is that maven identifies a project from
groupId/artifactId/version. In Eclipse a link betwwen project is done using
project's name which is by default the artifactId. Having groupID/artifactId
and version in eclipse project's name is the better solution to not have
problem of identification but after that projects are unreadable (except if
you are working on a 54" display). I don't know what to do to have something
logical to identify a maven project in eclipse. I didn't have a look to see
how m2eclise and Q4E are doing to mange these case (several branches of a
project in the same workspace)


On Mon, Apr 13, 2009 at 7:09 PM, Stephen Duncan Jr <stephen.duncan@gmail.com
> wrote:

> Amongst several other surprising changes in the 2.6 release of the
> maven-eclipse-plugin, I'd like to explain on one change caused some
> confusion for myself and other members of my development team.  I'm not
> sure
> it's really a bug, or exactly what feature enhancement to file, so I'm
> hoping this thread can help determine a better future outcome.
>
> Background: We have many different components as individual maven projects,
> no multi-project/reactor projects, and Hudson continuously building and
> deploying SNAPSHOTs to Nexus.  The typical workflow for a developer would
> be
> to check out any particular component they needed to work on, and they
> could
> run 'mvn eclipse:eclipse' to get the classpath right, and to download the
> latest versions of any dependent components (settings.xml defined the
> repository with a updatePolicy of always).  If they wanted to make changes
> to a dependent component locally, they'd make the changes, run mvn install,
> and then refresh the project to get those changes.  This all worked without
> any extra configuration of the eclipse plugin.  Also, the name of the
> project in eclipse didn't necessarily match the artifactId in anyway;
> typically it matched the folder in Subversion (which is sometimes, though
> rarely, different from the artifactId), or the the name of the branch in
> Subversion (artifactId-version, where version might be a SNAPSHOT, or be
> something like 1.2.x).
>
> With the eclipse plugin 2.6, it seems new work has been done to try to
> identify other projects in the eclipse workspace, and use those as project
> dependencies, instead of jar dependencies in the local repository.  To get
> the workflow described above, I've gone ahead and configured (in our
> corporate parent pom) the eclipse plugin to not do project references at
> all.  However, I didn't have to specify that before (I think it only used
> to
> affect reactor-builds), and therefore our team did get confused by the new
> behavior.
>
> When all SNAPSHOT dependencies were being downloaded from the repository,
> the version was the timestamp version of the SNAPSHOT, and never matched a
> project in the workspace, and so it behaved as before, so no problem.
> However, once somebody installed a dependency locally, the version was just
> -SNAPSHOT, so the eclipse plugin believed it found a match in the
> workspace.  However, the name it tried to use for the project reference was
> the artifactId, not the actual name of the project in eclipse, and
> therefore
> the project showed up as broken in eclipse, due to the unsatisfied
> dependency.
>
> I think it would be better if the default went back to only doing project
> references for reactor builds.  I also don't know if there's some better
> way
> to figure out the right project name to use for the reference.  Even if our
> dependency had been named to match the project reference, somebody working
> on the branch may have gotten the WRONG project reference (the trunk would
> have the artifactId, but the wrong version, the branch project name would
> be
> the right version, but not match the expected name).
>
> --
> Stephen Duncan Jr
> www.stephenduncanjr.com
>



-- 
Arnaud