Maven 2.x Eclipse Plugin

more jee support for wtp

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.3
  • Fix Version/s: 2.5
  • Component/s: WTP support
  • Labels:
    None
  • Environment:
    linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8
  • Patch Submitted:
    Yes
  • Number of attachments :
    4

Description

I tried the new release 2.3 of the eclipse plugin and noteted that not alle of my paches where included.
I re-pached the 2.3 version again this time i made my changes configurable so they can be turned on and off.

my changes:

  • prohibit dupicate entries in the classpath
    provided system paths in combination with log4j/commons-logging/xerces can easely create such problems
  • system paths are only included in ears and war when they are inside the project
    bether behavior would be to exclude all system paths because the war and ear plugin also ignore these
  • an application.xml specialy for eclipse-wtp
    this makes wtp ears function correctly it includes the eclipse project modules instead of the maven generated jars
  • manifest generation for wtp
    wtp needs manifest files, but not the ones maven creates because they have version names for all modules etc
    this generates a wtp manifest that will be in a ons eclipse source directory that is ignored my maven itself

use the parameters -Declipse.wtpmanifest=true -Declipse.wtpapplicationxml=true to acivate the patch.

The manifest generator could be combined with the RadManifestWriter in the future, they are almost the same.

regards,
Ritchie

Attachments

  1. Text File
    maven-eclipse-plugin.patch
    17/Jul/07 7:31 AM
    87 kB
    Richard van Nieuwenhoven
  2. Text File
    maven-eclipse-plugin-2.3-CFC-2007-03-08.patch
    16/Mar/07 3:31 AM
    59 kB
    Richard van Nieuwenhoven
  3. File
    maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz
    16/Mar/07 3:41 AM
    226 kB
    Richard van Nieuwenhoven
  4. Text File
    maven-eclipse-plugin-R494407.patch
    10/Jan/07 2:38 AM
    45 kB
    Richard van Nieuwenhoven

Issue Links

This issue is related to:
MECLIPSE-389 After running "clean" phase, eclipse detects some errors due to missing folder. Major Open

Activity

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

the idea to rename the project to the name with version name attached to it is realy very good. this solves a lot of troubles i have with the combination of maven with eclipse.

when somebody needs it, i can sent an other patch to this pach that includes that setting! This makes project references a lot more simple to handle.

  • the manifest for eclipse could be done by the plexus-archiver now (open)
    this makes the generated artifacts of wtp more equal to the maven generated artifacts
  • the application.xml for eclipse could also be generated by the ear plugin (open)
    only the eclipse spesific ids must be added
  • it is now easy to have textual references to jar names in code, no more need for differences between eclipse-wtp and maven generated jar names.

i must say that i vote for including the version into the name by default!

Show
Richard van Nieuwenhoven added a comment - the idea to rename the project to the name with version name attached to it is realy very good. this solves a lot of troubles i have with the combination of maven with eclipse. when somebody needs it, i can sent an other patch to this pach that includes that setting! This makes project references a lot more simple to handle.
  • the manifest for eclipse could be done by the plexus-archiver now (open) this makes the generated artifacts of wtp more equal to the maven generated artifacts
  • the application.xml for eclipse could also be generated by the ear plugin (open) only the eclipse spesific ids must be added
  • it is now easy to have textual references to jar names in code, no more need for differences between eclipse-wtp and maven generated jar names.
i must say that i vote for including the version into the name by default!
Hide
Permalink
Carlos Sanchez added a comment -

for manifest generation please look into felix bundle plugin
http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html
and
https://issues.apache.org/jira/browse/FELIX-199

Show
Carlos Sanchez added a comment - for manifest generation please look into felix bundle plugin http://cwiki.apache.org/FELIX/bundle-plugin-for-maven-bnd.html and https://issues.apache.org/jira/browse/FELIX-199
Hide
Permalink
Richard van Nieuwenhoven added a comment -

Currently i use the mavenarchiver to generate a manifest. The problem is that wtp needs a manifest (with classpath) for multiy module projects. (And we do not want it to intrefere with the one generated by the jar plugin). The mavenarchiver can only be used if the jar names include the version, that is not the normal behavior of the maven-eclipse-plugin, i now made a extra option to change the project name to the "maven compatible" name with version.

i can post this patch but it is based on the realeased 2.3 version. At the moment i do not have the time to diliver a patch based on the current SNAPSHOT.

when you want it please report it here, because than i will make some checks first.

Show
Richard van Nieuwenhoven added a comment - Currently i use the mavenarchiver to generate a manifest. The problem is that wtp needs a manifest (with classpath) for multiy module projects. (And we do not want it to intrefere with the one generated by the jar plugin). The mavenarchiver can only be used if the jar names include the version, that is not the normal behavior of the maven-eclipse-plugin, i now made a extra option to change the project name to the "maven compatible" name with version. i can post this patch but it is based on the realeased 2.3 version. At the moment i do not have the time to diliver a patch based on the current SNAPSHOT. when you want it please report it here, because than i will make some checks first.
Hide
Permalink
Richard van Nieuwenhoven added a comment -

this is the patch that i use to

  • create eclipse- only manifests
  • to define the eclipse lib directory equal to the maven ear lib directory
  • to generate the project names as artifact names (including version)
  • to generate a WTP able application.xml

to activate the extentions add:

  • -Declipse.wtpmanifest=true
  • -Declipse.wtpapplicationxml=true
  • -Declipse.addVersionToProjectName=true
Show
Richard van Nieuwenhoven added a comment - this is the patch that i use to
  • create eclipse- only manifests
  • to define the eclipse lib directory equal to the maven ear lib directory
  • to generate the project names as artifact names (including version)
  • to generate a WTP able application.xml
to activate the extentions add:
  • -Declipse.wtpmanifest=true
  • -Declipse.wtpapplicationxml=true
  • -Declipse.addVersionToProjectName=true
Hide
Permalink
Richard van Nieuwenhoven added a comment -

This is the pre build version of the patch for anyone who wants to try it.

Show
Richard van Nieuwenhoven added a comment - This is the pre build version of the patch for anyone who wants to try it.
Hide
Permalink
Brian Fox added a comment -

Patch needs to be updated and should include a test.

Show
Brian Fox added a comment - Patch needs to be updated and should include a test.
Hide
Permalink
Richard van Nieuwenhoven added a comment -

re patched for version 2.5-SNAPSHOT

now including an initial test case (i will write more detailed asserts in the next 2 weeks). But because these were a lot of changes, i do not want to do them again on a changed trunk......

my changes in short

  • an IdeDependency now knows the name of the eclipse project if it is in the reactor.
  • an IdeDependency now has an equals that supports multiple system dependencies to the same file
  • an IdeDependency now knows if a system dependency is outside or inside the reactor
    some work has to be done here how to detect it correctly
  • duplicate dependencies (to the same file) are not included in the classpath
  • an eclipse application.xml can be generated in a target/eclipseEar directory
    this resolves the problem of wtp including far to mutch in the ear
  • eclipse manifests are written so that they do not interfere with the maven manifest's
    in a extra resource directory not known by maven, i commented out the code
    that uses that standard pexus stuff to generate a manifest because that requires
    a dependency resolution that failes in a lot of tests..
  • changed multible places where the getArtifactId() is used instead of getEclipseProjectName()
  • the ComponentWriter now uses the deployPath for the ear plugin definition
  • the ComponentWriter will not include jars outside the reactor in the component
    (this is specially for dependencies on jars of an application server)

Please report me if the patch has any problems that prohibiting an apply. So that i correct it immediately.
Does anyone has tips for the manifest generation problems?

Ritchie

Show
Richard van Nieuwenhoven added a comment - re patched for version 2.5-SNAPSHOT now including an initial test case (i will write more detailed asserts in the next 2 weeks). But because these were a lot of changes, i do not want to do them again on a changed trunk...... my changes in short
  • an IdeDependency now knows the name of the eclipse project if it is in the reactor.
  • an IdeDependency now has an equals that supports multiple system dependencies to the same file
  • an IdeDependency now knows if a system dependency is outside or inside the reactor some work has to be done here how to detect it correctly
  • duplicate dependencies (to the same file) are not included in the classpath
  • an eclipse application.xml can be generated in a target/eclipseEar directory this resolves the problem of wtp including far to mutch in the ear
  • eclipse manifests are written so that they do not interfere with the maven manifest's in a extra resource directory not known by maven, i commented out the code that uses that standard pexus stuff to generate a manifest because that requires a dependency resolution that failes in a lot of tests..
  • changed multible places where the getArtifactId() is used instead of getEclipseProjectName()
  • the ComponentWriter now uses the deployPath for the ear plugin definition
  • the ComponentWriter will not include jars outside the reactor in the component (this is specially for dependencies on jars of an application server)
Please report me if the patch has any problems that prohibiting an apply. So that i correct it immediately. Does anyone has tips for the manifest generation problems? Ritchie
Hide
Permalink
Brian Fox added a comment -

Hi Rich, I sent you this email several weeks ago but perhaps it was blocked:

Hi Ritchie,
I tried applying your patch. Unfortunately, svn doesn't handle newly added files in patches very well, especially binary ones. Can you do the following?

Remove all files from the tree that are not new, leaving behind just the tree of new files, and zip it up? Then attach it or email it to me. I'll take this zip and unpack it over the eclipse folder and apply the rest of your patch. I can then submit it to a branch where we can review it and tweak if needed before merging.

Thanks,
Brian

Show
Brian Fox added a comment - Hi Rich, I sent you this email several weeks ago but perhaps it was blocked: Hi Ritchie, I tried applying your patch. Unfortunately, svn doesn't handle newly added files in patches very well, especially binary ones. Can you do the following? Remove all files from the tree that are not new, leaving behind just the tree of new files, and zip it up? Then attach it or email it to me. I'll take this zip and unpack it over the eclipse folder and apply the rest of your patch. I can then submit it to a branch where we can review it and tweak if needed before merging. Thanks, Brian
Hide
Permalink
Brian Fox added a comment -

Rich, I applied the patch along with the new files to a branch: http://svn.apache.org/repos/asf/maven/plugins/branches/maven-eclipse-plugin-MECLIPSE-213

Take a look and try out the plugin to make sure everything works as you expect. The code builds and all the tests pass so it looks good so far.

Show
Brian Fox added a comment - Rich, I applied the patch along with the new files to a branch: http://svn.apache.org/repos/asf/maven/plugins/branches/maven-eclipse-plugin-MECLIPSE-213 Take a look and try out the plugin to make sure everything works as you expect. The code builds and all the tests pass so it looks good so far.
Hide
Permalink
Richard van Nieuwenhoven added a comment -

Just tested it on 3 different projects, looks very good! all worked!

Do you need more tests before releasing the changes to the 2.5-SNAPSHOT ?

Or should i wait for your 2.5-SNAPSHOT update?

Show
Richard van Nieuwenhoven added a comment - Just tested it on 3 different projects, looks very good! all worked! Do you need more tests before releasing the changes to the 2.5-SNAPSHOT ? Or should i wait for your 2.5-SNAPSHOT update?
Hide
Permalink
Brian Fox added a comment -

merged in the branch. Thanks for the patch Richard!

Show
Brian Fox added a comment - merged in the branch. Thanks for the patch Richard!
Hide
Permalink
Shelley Baker added a comment - - edited

I've grabbed the snapshot and have done some preliminary testing of this bug. It looks good so far. I have one comment which may be outside the scope of this particular bug, but is very closely related to better JEE support with maven and wtp – when generating the wtp-friendly projects (eclipseEar, etc.), is it possible to reference the available projects from the workspace rather than maven repository? For example, referencing an EAR's modules from the local repo instead of the workspace nearly defeats the purpose of developing JEE apps within the IDE. It would be nice if all Eclipse-generated configuration files would have the ability to reference projects within the workspace when desired, but in particular, the .component file within an EAR should reference the modules available within the workspace. This bug fix will resolve several maven/wtp woes, but the lack of workspace references is one major outstanding issue. (This comment is also related to MECLIPSE-74.)

Show
Shelley Baker added a comment - - edited I've grabbed the snapshot and have done some preliminary testing of this bug. It looks good so far. I have one comment which may be outside the scope of this particular bug, but is very closely related to better JEE support with maven and wtp – when generating the wtp-friendly projects (eclipseEar, etc.), is it possible to reference the available projects from the workspace rather than maven repository? For example, referencing an EAR's modules from the local repo instead of the workspace nearly defeats the purpose of developing JEE apps within the IDE. It would be nice if all Eclipse-generated configuration files would have the ability to reference projects within the workspace when desired, but in particular, the .component file within an EAR should reference the modules available within the workspace. This bug fix will resolve several maven/wtp woes, but the lack of workspace references is one major outstanding issue. (This comment is also related to MECLIPSE-74.)
Hide
Permalink
Richard van Nieuwenhoven added a comment -

The NPE is fixed (with tests) in the patch for MECLIPSE-333.

I am looking into a way to detect current projects / artifacts in the workspace, but for now use the multi module builds for them. If they are not an option for your case, use a "build" pom that references all projects in your workspace (this way they will be linked together) .

Show
Richard van Nieuwenhoven added a comment - The NPE is fixed (with tests) in the patch for MECLIPSE-333. I am looking into a way to detect current projects / artifacts in the workspace, but for now use the multi module builds for them. If they are not an option for your case, use a "build" pom that references all projects in your workspace (this way they will be linked together) .

People

Vote (4)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
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.