Issue Details (XML | Word | Printable)

Key: MECLIPSE-334
Type: New Feature New Feature
Status: Closed Closed
Resolution: Duplicate
Priority: Major Major
Assignee: Arnaud Heritier
Reporter: Martin Zeltner
Votes: 0
Watchers: 3
Operations

If you were logged in you would be able to see more operations.
Maven 2.x Eclipse Plugin

Add a rule that determined artifacts will be always recognized as reactor projects

Created: 23/Oct/07 02:51 AM   Updated: 31/Jan/08 08:06 AM   Resolved: 31/Jan/08 08:06 AM
Component/s: None
Affects Version/s: 2.4
Fix Version/s: 2.5

Time Tracking:
Original Estimate: 10 minutes
Original Estimate - 10 minutes
Remaining Estimate: 10 minutes
Remaining Estimate - 10 minutes
Time Spent: Not Specified
Time Spent - Not Specified

File Attachments: 1. Text File patch_maven-eclipse-plugin-r587020.patch (4 kB)

Issue Links:
Related
 

Patch Submitted: Yes


 Description  « Hide

I've implemented a feature that determined artifacts will be always recognized as reactor projects, doesn't matter where the "mvn eclipse:eclipse" is executed. The idea is to set a list of groupId prefixes. Example:

[code]
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<reactorProjectGroupIdPrefixes>
ch.elca.,
org.sp,
net.sf
</reactorProjectGroupIdPrefixes>
</configuration>
</plugin>
[/code]

All artifacts where the groupId starts with "ch.elca.", "org.sp" or "net.sf" will be handled as reactor projects.

Cheers,
Martin



Richard van Nieuwenhoven added a comment - 19/Nov/07 03:51 AM

MECLIPSE-344 checks the workspace and connects the projects / artefacts available in the correct version.
Does MECLIPSE-344 meet your requirements?


Martin Zeltner added a comment - 27/Nov/07 08:44 AM

As I understand MECLIPSE-344 uses already existing Eclipse projects (of a workspace) as reactor projects if they match. If you have A -> B -> C then C must be in workspace that B can handle C as reactor project. The same for A and B. So it does not cover my needs.

Thanks & cheers,
Martin


Arnaud Heritier added a comment - 27/Nov/07 03:59 PM

Can't it be dangerous to create project dependencies to projects that don't (yet) exist ?


Richard van Nieuwenhoven added a comment - 28/Nov/07 02:00 AM

yes, i think it is too dangerous and would create a lot "why doesn't it work" questions.

The wish to include whole bunches of projects with same groupId's sounds like the need for modularization.

Can you elaborate a little more why you need this?


Martin Zeltner added a comment - 28/Nov/07 02:46 AM

I don't understand what's dangerous. First this feature is switched off by default (property not set). Second if you miss to import an eclipse project into the workspace you will have the same "danger" as currently. Could you please explain me what "danger" do you see with my extension that we don't have already?


Richard van Nieuwenhoven added a comment - 28/Nov/07 03:13 AM

dangerous means for me things you can configure that can lead to "bad" style.

But lets concentrate on your usecase. Can you explain the situation for which you need this!

Because you are willing to write the configuration in your pom, and a pom should not (in my opinion) expect other artefact's to be available in source (exception are all submodules).

So please explain what are you trying to accomplish, and how this configuration helps.


Martin Zeltner added a comment - 28/Nov/07 04:21 AM

Example:

Directory structure:

mymodules/
a/
b/
c/

  • a, b and c are subdirs of dir mymodules
  • mymodules contains a pom.xml that has a, b and c as modules
  • a, b and c contain also a pom.xml
  • c depends on b depends on a

I'd like to have a, b and c in one workspace:

  • cd mymodules
  • mvn eclipse:eclipse

a, b and c are now in the workspace. I change a dependency in pom.xml c so I have to execute the following:

  • cd mymodules/c
  • mvn eclipse:clean eclipse:eclipse

I go back to my workspace and refresh project c (F5). Without my new feature the project c in Eclipse has now NO MORE dependent on a and b (direct link to local repo). To solve this issue with the current eclipse plugin I have to recreate the Eclipse project for a, b and c like at the beginning.

  • cd mymodules
  • mvn eclipse:clean eclipse:eclipse

Joerg Schaible added a comment - 28/Nov/07 04:35 AM

Well, best might be to look at MECLIPSE-344 and all the linked issues there. There are a lot of proposals and patches for this and similar problems. I'd like to see a more general solution. IMHO your use case applies only for SNAPSHOT deps anyway.


Arnaud Heritier added a comment - 29/Nov/07 09:21 PM

Martin, in fact you can always execute the plugin in the root directory? The problem for you is about speed, that's why you generate only the project where you changed the pom ?


Richard van Nieuwenhoven added a comment - 30/Nov/07 01:55 AM

This is exactly the one of the usecases that MECLIPSE-344 covers, I have discussed this with Martin and now he is also convinced that 344 covers his needs. But he is at a conference so he can't respond till Monday.


Martin Zeltner added a comment - 10/Dec/07 02:11 AM

After the discussion with Richie I'm convinced now that the MECLIPSE-344 covers my needs too. But dealing with files in the workspace folder looks to me a bit dangerous because they seem to be not so stable in their format as the .project and .classpath.


Arnaud Heritier added a comment - 31/Jan/08 08:06 AM

This issue is considered as fixed with MECLIPSE-344.
To try the latest SNAPSHOT (2.5-20080131.135640-18) of the incoming version you have to define and activate this profile :

<profile>
      <id>apache.snapshots</id>
      <repositories>
        <repository>
          <releases>
            <enabled>false</enabled>
          </releases>
          <snapshots/>
          <id>apache.snapshots</id>
          <name>Maven Snapshots</name>
          <url>http://people.apache.org/maven-snapshot-repository</url>
        </repository>
      </repositories>
      <pluginRepositories>
        <pluginRepository>
          <releases>
            <enabled>false</enabled>
          </releases>
          <snapshots/>
          <id>apache.plugin.snapshots</id>
          <name>Maven Plugin Snapshots</name>
          <url>http://people.apache.org/maven-snapshot-repository</url>
        </pluginRepository>
      </pluginRepositories>
    </profile>

Then you have to call this command :

mvn org.apache.maven.plugins:maven-eclipse-plugin:2.5-SNAPSHOT:eclipse

If you think that your problem isn't resolved, please give us your feedback and we'll reopen the issue.