maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnaud HERITIER <>
Subject Re: maven-eclipse-plugin 2.6 project references
Date Tue, 14 Apr 2009 09:09:33 GMT
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 <
> 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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message