Maven 2.x Eclipse Plugin

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

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 2.4
  • Fix Version/s: 2.5
  • Component/s: None
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

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

Issue Links

This issue is related to:
MECLIPSE-344 connecting existing workspace artifact-projects Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Richard van Nieuwenhoven added a comment -

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

Show
Richard van Nieuwenhoven added a comment - MECLIPSE-344 checks the workspace and connects the projects / artefacts available in the correct version. Does MECLIPSE-344 meet your requirements?
Hide
Permalink
Martin Zeltner added a comment -

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

Show
Martin Zeltner added a comment - 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
Hide
Permalink
Arnaud Heritier added a comment -

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

Show
Arnaud Heritier added a comment - Can't it be dangerous to create project dependencies to projects that don't (yet) exist ?
Hide
Permalink
Richard van Nieuwenhoven added a comment -

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?

Show
Richard van Nieuwenhoven added a comment - 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?
Hide
Permalink
Martin Zeltner added a comment -

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?

Show
Martin Zeltner added a comment - 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?
Hide
Permalink
Richard van Nieuwenhoven added a comment -

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.

Show
Richard van Nieuwenhoven added a comment - 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.
Hide
Permalink
Martin Zeltner added a comment -

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
Show
Martin Zeltner added a comment - 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
Hide
Permalink
Joerg Schaible added a comment -

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.

Show
Joerg Schaible added a comment - 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.
Hide
Permalink
Arnaud Heritier added a comment -

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 ?

Show
Arnaud Heritier added a comment - 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 ?
Hide
Permalink
Richard van Nieuwenhoven added a comment -

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.

Show
Richard van Nieuwenhoven added a comment - 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.
Hide
Permalink
Martin Zeltner added a comment -

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.

Show
Martin Zeltner added a comment - 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.
Hide
Permalink
Arnaud Heritier added a comment -

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.

Show
Arnaud Heritier added a comment - 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.

People

Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
10m
Original Estimate - 10 minutes
Remaining:
10m
Remaining Estimate - 10 minutes
Logged:
Not Specified
Time Spent - Not Specified
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.