Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of chris.redekop@gmail.com
 designates 209.85.161.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADVp3v_901hCM=JUeWUdMTBfO_XzDsuZ19B+hz8NaZ_KRaVyHg@mail.gmail.com>
References: 
 <CAMgJZ9LhXRw29qb6vSBXM11+SCSD9RXXw-2-+U-c5mgDcFVVrA@mail.gmail.com>
	<CADVp3v_901hCM=JUeWUdMTBfO_XzDsuZ19B+hz8NaZ_KRaVyHg@mail.gmail.com>
Date: Tue, 5 Jun 2012 12:00:01 -0400
Message-ID: 
 <CAMgJZ9LyfQA_cgaXaT-acq-YkE+h5xA+o9HgmLiRF1TTb21e3A@mail.gmail.com>
Subject: Re: Eclipse Plugin and Project Links to Independent Projects
From: Chris Redekop <chris.redekop@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 4, 2012 at 8:08 PM, Barrie Treloar <baerrach@gmail.com> wrote:
> On Tue, Jun 5, 2012 at 3:19 AM, Chris Redekop <chris.redekop@gmail.com> w=
rote:
>> (How) can I use the Eclipse plugin to create Eclipse project files
>> that refer to an dependency A) with an Eclipse project link instead of
>> B) as a JAR in the repo? =A0The dependency in this case is A) NOT a
>> module of the parent project (where 'mvn eclipse:eclipse' is executed)
>> and B) NOT built with Maven.
>>
>> Project links work well between modules in a multi-module project, and
>> the -Declipse.workspace property provides some related functionality;
>> but its workspace scan only seems to recognize other Maven projects.
>
> You can't.
Thanks for the confirmation, Barrie.  I figured that this is currently
not supported, but part of me wondered if I just hadn't found the
right (combination of) options.

>
> mvn eclipse:eclipse will automatically configure the .classpath to
> reference any dependency that is already configured in Eclipse and is
> a Maven project.
>
> If you think about it, how do you expect eclipse:eclipse to work out
> that your non-Maven project just happens to be the same as one of your
> Maven dependencies?

The most straight-forward way that I can think of is a new plugin
configuration: a map of dependency -> project.  When the Eclipse
plugin handles a dependency, in can first check the map.  If there is
an entry, then the specified project is used; otherwise, the JAR is
used.

The old Maven 1 plugin had something like this, in the form of a "project" =
flag:

http://maven.apache.org/maven-1.x/plugins/eclipse/faq.html#project_dependen=
cies

>
>> I am looking for something like -Declipse.workspace but more direct
>> and fully contained within the plugin configuration: a map between
>> dependencies and Eclipse projects that says, "when you are generating
>> Eclipse project files and hit this dependency, refer to this Eclipse
>> project instead of the artifact's JAR in the repo."
>>
>> The use case here is migrating one of an organization's existing
>> builds to Maven while NOT migrating ALL an organization's builds. =A0We
>> currently have a mix of Maven/non-Maven builds cohabitating in the
>> same Eclipse workspace. =A0In this environment, dependencies from
>> Maven-built projects to non-Maven-built projects appear twice:
>> 1) as a JAR dependency and
>> 2) as an Eclipse project where active development takes place.
>>
>> The duplicate project/class definition is causing confusion.
>
> You have some of options:
> 1) Dont use mvn eclipse:eclipse
> 2) Use mvn eclipse:eclipse to "kick-start" the .classpath creation and
> then manually tweak this to work with the non-Maven project. =A0You then
> check-in the eclipse files: .project, .classpath into your source
> control.
Both of these run counter to DRY: maintaining dependencies in POMs and
Eclipse project files.  Do not want.

> 3) Migrate your non-Maven builds to Maven. =A0If these are Ant builds it
> should be a simple process to create a dumb Maven wrapper that just
> calls out to Ant to do the build. =A0This will give you a pom.xml that
> specifies the correct dependency coordinates for mvn eclipse:eclipse
> to then use. =A0Then when you are ready to migrate these projects, you
> take out the Ant stuff and replace it with the equivalent Maven
> plugins.
>
> I would recommend 3).
The use case of a mixed-build environment will be valid into the
foreseeable future.  3) is not an option.

A fourth option would enhance the plugin to support a map
configuration as described here.  It *seems* straightforward to me at
this point, but the history of a similar feature disappearing from the
Maven 1 plugin makes me wonder: maybe this is a Bad Idea?

Comments?


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org