Maven 2.x Eclipse Plugin

Allow eclipse plugin .project name to be customised

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: 2.0
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Currently the EclipseWriter uses the POM artifactId as the eclipse project name in .project. This should be configurable for use-cases where different versions of the same project are used within the same eclipse workspace (since eclipse project names must be unique within workspaces).

Issue Links

is duplicated by

New Feature - A new feature of the product, which has yet to be developed. MECLIPSE-119 Allow custom project name for eclipse projects

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

New Feature - A new feature of the product, which has yet to be developed. MECLIPSE-189 addVersionToProjectName property

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Trygve Laugstøl added a comment -

Would a flag "append version" suffice? The things is that I'm imagining the possibility for the Eclipse plugin to go look in the current workspace and find all existing projects that's in the workspace and try to find the ones it can make links to. I'm not sure but I think making the project name not deviate too much from the artifact id might be good for that reason.

Show
Trygve Laugstøl added a comment - Would a flag "append version" suffice? The things is that I'm imagining the possibility for the Eclipse plugin to go look in the current workspace and find all existing projects that's in the workspace and try to find the ones it can make links to. I'm not sure but I think making the project name not deviate too much from the artifact id might be good for that reason.
Hide
Permalink
Mark Hobson added a comment -

Not too sure about that since we'd end up with rather verbose project names, e.g. myproject-1.5.3-SNAPSHOT. If any SNAPSHOT suffix was dropped then perhaps it could be managable.

Linking to projects within the workspace is a nice idea, although I'm not too sure about how maven's strict dependency versioning could still be maintained. For example, if a:1.0 depended on b:1.0 and b:1.1 was in the workspace would a be linked to b? If so then eclipse could happily compile a with b:1.1 during coding, but then maven might break at buildtime since it expects b:1.0.

A solution might be to use the full artifactId:version for the project name, but still things could get out of sync when SNAPSHOTs are involved - eclipse would be working with the latest source code whereas maven would be working with the last installed SNAPSHOTs. We then have the complexity of groupIds to add into the mix - how would we deal with like-named artifactIds that belong to different groupIds within the same workspace?

I personally like the non-linking behaviour of .classpath files since you know for sure that eclipse and maven are seeing eye-to-eye.

Show
Mark Hobson added a comment - Not too sure about that since we'd end up with rather verbose project names, e.g. myproject-1.5.3-SNAPSHOT. If any SNAPSHOT suffix was dropped then perhaps it could be managable. Linking to projects within the workspace is a nice idea, although I'm not too sure about how maven's strict dependency versioning could still be maintained. For example, if a:1.0 depended on b:1.0 and b:1.1 was in the workspace would a be linked to b? If so then eclipse could happily compile a with b:1.1 during coding, but then maven might break at buildtime since it expects b:1.0. A solution might be to use the full artifactId:version for the project name, but still things could get out of sync when SNAPSHOTs are involved - eclipse would be working with the latest source code whereas maven would be working with the last installed SNAPSHOTs. We then have the complexity of groupIds to add into the mix - how would we deal with like-named artifactIds that belong to different groupIds within the same workspace? I personally like the non-linking behaviour of .classpath files since you know for sure that eclipse and maven are seeing eye-to-eye.
Hide
Permalink
Mark Hobson added a comment -

Ah, I hadn't realised this had been applied already.. wondered why my workspace was broken after a m2 eclipse:eclipse

Show
Mark Hobson added a comment - Ah, I hadn't realised this had been applied already.. wondered why my workspace was broken after a m2 eclipse:eclipse
Hide
Permalink
Brett Porter added a comment -

so this should be closed as fixed? any ideas when it was fixed?

Show
Brett Porter added a comment - so this should be closed as fixed? any ideas when it was fixed?
Hide
Permalink
Mark Hobson added a comment -

Nope this hasn't been resolved yet.

I was proposing an eclipse plugin config property to customise the project name within the eclipse workspace. This is to allow different versions of the same project to co-exist in eclipse (since project names must be unique in eclipse).

The problem is that a recent eclipse plugin patch dynamically links projects together within the workspace based on their dependencies and whether they also exist in the workspace. This is done by assuming that the project name is always equal to the artifactId - which would obviously break down if it were customisable as I proposed.

Although handy, I'm not entirely convinced that dynamic project linking is the correct approach. Especially as it can lead to differences between eclipse & maven compliation and currently does not support multiple versions of a project within the workspace (as detailed in the above comments).

Has anyone got any opinions on this?

Show
Mark Hobson added a comment - Nope this hasn't been resolved yet. I was proposing an eclipse plugin config property to customise the project name within the eclipse workspace. This is to allow different versions of the same project to co-exist in eclipse (since project names must be unique in eclipse). The problem is that a recent eclipse plugin patch dynamically links projects together within the workspace based on their dependencies and whether they also exist in the workspace. This is done by assuming that the project name is always equal to the artifactId - which would obviously break down if it were customisable as I proposed. Although handy, I'm not entirely convinced that dynamic project linking is the correct approach. Especially as it can lead to differences between eclipse & maven compliation and currently does not support multiple versions of a project within the workspace (as detailed in the above comments). Has anyone got any opinions on this?
Hide
Permalink
Brett Porter added a comment -

not required for the first full release of the eclipse plugin IMO

Show
Brett Porter added a comment - not required for the first full release of the eclipse plugin IMO
Hide
Permalink
David Rice added a comment -

I created a patch that adds this property and submitted it as MNG-1920. Not sure how to move it into MECLIPSE, so I am linking it.

Show
David Rice added a comment - I created a patch that adds this property and submitted it as MNG-1920. Not sure how to move it into MECLIPSE, so I am linking it.
Hide
Permalink
Carlos Sanchez added a comment -

I've applied the patch in MECLIPSE-189 to add version to project names, as that's the main use case for this jira i'll close
Open new detailed jiras for other requests

Show
Carlos Sanchez added a comment - I've applied the patch in MECLIPSE-189 to add version to project names, as that's the main use case for this jira i'll close Open new detailed jiras for other requests

People

  • Assignee:
    Carlos Sanchez
    Reporter:
    Mark Hobson
Vote (5)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: