Issue Details (XML | Word | Printable)

Key: MECLIPSE-344
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Arnaud Heritier
Reporter: Richard van Nieuwenhoven
Votes: 9
Watchers: 8
Operations

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

connecting existing workspace artifact-projects

Created: 14/Nov/07 05:31 AM   Updated: 10/Mar/08 05:53 AM
Component/s: Core : Dependencies resolution and build path (.classpath)
Affects Version/s: 2.4
Fix Version/s: 2.5

Time Tracking:
Not Specified

File Attachments: 1. Text File MECLIPSE-344+rad7.patch (88 kB)
2. File MECLIPSE-344+rad7.tgz (1 kB)
3. Text File MECLIPSE-344.patch (99 kB)
4. File MECLIPSE-344.tgz (1 kB)
5. File workspace-new-files.tgz (10 kB)
6. Text File workspace.patch (11 kB)
7. Text File workspace_with_limit.patch (14 kB)

Issue Links:
Related

Patch Submitted: Yes


 Description  « Hide
This patch enables you to specify your workspace, and all dependent artefacts that are available in your eclipse-workspace will be attached as project references even if they are not in the reactor.

the property can be set with -DworkspaceToConnect=.....

I did not have the time to create Test cases but, i maybe someone can help with that!

The patch is based on the MECLIPSE-333 branch.

as usual the new files are in the extra tgz.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Richard van Nieuwenhoven added a comment - 14/Nov/07 06:01 AM
typo the property is -Declipse.workspaceToConnect=...

Richard van Nieuwenhoven added a comment - 20/Nov/07 04:02 AM
There are a few jira's about exluding some projects from using project references. Now this is rather easy done if the workspace is known.

I extended the patch to include the option:

-Declipse.limitProjectReferencesToWorkspace=true

This option will force projects that are not in the workspace but in the reactor to be used as jars.

this patch includes the original patch!


Arnaud Heritier added a comment - 22/Nov/07 11:52 PM
One question about your patch : Why did you call the configuration variable for the workspace : workspaceToConnect
I believed there was already a workspace var but it's not the case.
The workspace is in the new Mojo for workspace configuration.

Richard van Nieuwenhoven added a comment - 23/Nov/07 01:48 AM
a good question! the problem is that the eclipse.workspace variable is used for something different.
And i didn't want to break the old behavior!

Could you check if it it is still needed? maybe even deprecate it?


Richard van Nieuwenhoven added a comment - 23/Nov/07 09:02 AM
updated the patch to include test cases for the workspace code!

included is now:

  • connect to artefact's available in the workspace as projects
  • use the correct default class path container depending on the compiler
  • exclude artefact's from using project references (by removing them from the workspace)

I did not have the time to refactor the workspace reader stuff... Creating tests took a lot of time..

But i think we should split the workspace configuration class in a class not eclipse specific and an eclipse specific subclass.


Richard van Nieuwenhoven added a comment - 23/Nov/07 09:14 AM
these two include the complete patch on the today trunk R597676

the others are old and included.


Richard van Nieuwenhoven added a comment - 05/Dec/07 04:49 AM
a small fix for my patch that will give the class path container lookup partly back to eclipse.

--------ReadWorkspaceLocations--------------
//add constant
private static final String CLASSPATHENTRY_STANDARD = CLASSPATHENTRY_DEFAULT+"/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/";
--------ReadWorkspaceLocations--------------
//change the method to add defaults known by eclipse
public static HashMap readAvailableJREs( String workspaceLocation, Log logger )
{
HashMap jreMap = new HashMap();
jreMap.put( "1.2", CLASSPATHENTRY_STANDARD+"J2SE-1.2" );
jreMap.put( "1.3", CLASSPATHENTRY_STANDARD+"J2SE-1.3" );
jreMap.put( "1.4", CLASSPATHENTRY_STANDARD+"J2SE-1.4" );
jreMap.put( "1.5", CLASSPATHENTRY_STANDARD+"J2SE-1.5" );
jreMap.put( "5", jreMap.get("1.5") );
jreMap.put( "1.6", CLASSPATHENTRY_STANDARD+"JavaSE-1.6" );
jreMap.put( "6", jreMap.get("1.6") );
--------EclipsePluginTest--------------
// changed test result in testProject38and39()
doTestProject38and39( "project-38", workspace15, "J2SE-1.3" ,null);
-----------------------------------------


Martin Zeltner added a comment - 10/Dec/07 02:21 AM
After the discussion with Richie I'm convinced now that the MECLIPSE-344 covers my needs (MECLIPSE-334) 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. Can anyone give me a link to documentation that convince me that the amount and the formats of these files are stable?

Cheers,
Martin


Richard van Nieuwenhoven added a comment - 10/Dec/07 04:48 AM
this part of file format did not change since 2.0 and that's a long time. It is also protected by a magic code so no version incompatibility possible.

And we will now use a dependency to the original eclipse (binaries) to read them, so i think we are on the save side here


Richard van Nieuwenhoven added a comment - 20/Dec/07 09:49 AM
Updated the patch for the current snapshot and included the standard JRE resolution of eclipse.

The workspace scanning is now re factored to reader and data class.

Now also included is the RAD-7 support (that needs the workspace reading) with tests.

to use the RAD-7 support the option

  • workspaceToConnect must point to the current workspace directory (use ${workspace_loc} in eclipse launches)
  • wtpdefaultserver contains the exact name or a substring of the defined wtp server to use

Benjamin Baril added a comment - 21/Dec/07 12:53 PM
MECLIPSE-344+rad7.tgz is 1kb and does not contain the binary as stated in the above comment.

Richard van Nieuwenhoven added a comment - 21/Dec/07 01:19 PM
it contains the binary files for the patch! "svn diff" can not handle binary files.

Benjamin Baril added a comment - 21/Dec/07 01:53 PM
Ahh, ok, I misunderstood the comment.

Building now


David J. M. Karlsen added a comment - 10/Jan/08 07:46 PM

Arnaud Heritier added a comment - 31/Jan/08 08:09 AM
This issue is fixed. Thanks for all patches submitted by Richard.
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

Arnaud Heritier added a comment - 31/Jan/08 03:12 PM
We have a failure if the worspace doesn't exist and it could be a good idea to add a flag to activate this new feature only if asked (set to false by default).
http://www.nabble.com/maven-eclipse-plugin-2.5-coming-soon-td15207954s177.html

Joerg Schaible added a comment - 01/Feb/08 06:44 AM
Will it link always all projects or is it possible to link only the SNAPSHOTs? The difference is, that with the information from the Eclipse workspace you don't have to rebuild all Eclipse files at once to get the SNAPSHOTs linked. You will have the information now to rebuild the Eclipse projects for a single submodule only, but have the SNAPSHOTs still linked. Therefore it would be really nice to have both operation modes.

Pedro added a comment - 11/Feb/08 01:59 AM
I just noticed a small problem with this fix.
If you have a dependency on a project for source code and tests, the project is
added twice to the "Required projects in the build path".
This of course causes eclipse to complain that the project has been added twice.

<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>outboundInterfaces</artifactId>
<classifier>${environment.type}</classifier>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>outboundInterfaces</artifactId>
<version>${project.version}</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>


Arnaud Heritier added a comment - 09/Mar/08 04:08 PM
This last issue is reported in MECLIPSE-397 but I'm not surethat it is related to this one. You didn't have this problem with 2.4 ?

Arnaud Heritier added a comment - 09/Mar/08 04:33 PM
I think we solved all problems discussed on the mailing list. I close the issue. Please open new ones if necessary

Richard van Nieuwenhoven added a comment - 10/Mar/08 03:31 AM
Only linking the SNAPSHOT's, can be done, the problem is the list of options are getting more and more complex and interweaving.

So i think it is best to make no new option but let the user decide with the eclipse means available (what's in the workspace will be linked).
I think the best solution is to import or delete (just from the workspace) the projects as needed and then let the eclipse plugin connect them.


Barrie Treloar added a comment - 10/Mar/08 05:53 AM
Not having an option as per http://jira.codehaus.org/browse/MECLIPSE-344#action_126688 makes sense to me.

If you have imported the project already into eclipse then link to it, otherwise use m2 repository.