patch against 0.4 I'm afraid, not the trunk. Future patches will be against the right branch / trunk!

new task that generates configuration for Wtp modules (as opposed to web apps).

Updated patch addressing issue in EclipseUtils when a project file is empty

i will try eclipse-wtp-integration as soon as the patch is applied.
several of my projects can benefit from that.

one thing, i noticed regarding eclipse-integration is, that
the generated .classpath is bound to a specific user.home
dir.

i have my eclipse-workspaces on a usb-disk and for some
reasons i have to work as different user on different machines.
but this brakes the gradle-generated eclipse .classpath. i would
have to regenerate each time i switch user.

solution for this could be either to use eclipses classpath-variables
or to have the option to switch on ivy-retrieve -> retrieve dependant
artifacts into ${project.dir}/lib.

I hope I can manage it to apply the patch today.

There is already an issue about portable eclipse files: http://jira.codehaus.org/browse/GRADLE-196

additional fixes, cumulative against the first patch

I've added a second patch which fixes a few small issues that have been shaken out in testing. One more patch to follow shortly with updated documentation.

Attached a patch which introduces a new sample project "wtp-project" which demonstrates a multi module WTP project, and updated the war plugin documentation (my latex is a bit rusty...).

Hi Phil,

I have applied the first patch to my working copy. I have a couple of questions:

• There is an empty file called 'EclipseProjectFile.java' in the patch. Can I simply ignore it?
• Why is the eclipseWtpModule task added by the JavaPlugin, not the WarPlugin?
• Patch 2 and 3 are to be applied against trunk, right? You basically have already answered this in the first comment. Just want to be sure.

Cheers,

Hans

• There is an empty file called 'EclipseProjectFile.java' in the patch. Can I simply ignore it?

Yes, that's a hangover from some other, non submitted work I've been doing to hide the dom manipulations behind a proper model. Go ahead and ignore/remove it.

• Why is the eclipseWtpModule task added by the JavaPlugin, not the WarPlugin?

The wtpModule task makes a non-war project into a WTP module project and will typically be used in sibling projects that contain library code. It'd seemed more logical to add it to the JavaPlugin as most library projects won't produce Wars. Take a look at the same project in Patch 3 for a working example

• Patch 2 and 3 are to be applied against trunk, right? You basically have already answered this in the first comment. Just want to be sure.

Patch 2 is cumulative against Patch 1, so it should apply against both.

Patch 3 is against trunk (as of this morning)

Thanks. The patches I apply against 0.4 are merged afterwards into trunk.

The EclipseProjectTest is failing:

java.lang.AssertionError: 
Expected: "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\n<projectDescription>\n  <name>myProject</name>\n  <comment/>\n  <projects/>\n  <natures/>\n  <buildSpec>\n    <buildCommand/>\n  </buildSpec>\n</projectDescription>\n"
     got: "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n\n<projectDescription>\n  <name>myProject</name>\n  <comment/>\n  <projects/>\n  <natures/>\n  <buildSpec/>\n</projectDescription>\n"

	at org.junit.Assert.assertThat(Assert.java:502)
	at org.junit.Assert.assertThat(Assert.java:492)
	at org.gradle.api.tasks.ide.eclipse.EclipseProjectTest.checkProjectFile(EclipseProjectTest.java:74)
	at org.gradle.api.tasks.ide.eclipse.EclipseProjectTest.generateSimpleProject(EclipseProjectTest.java:68)

I'm wondering if this is caused somehow by my merging. Does this test works in your working copy?

Sorry, took out too much from the patch file - ammended src/test/resources/org/gradle/api/tasks/ide/eclipse/expectedSimpleProjectFile.txt attached.

Thanks. The unit tests are passing now. But the integration tests are failing.

In buildSrc/src/main/groovy/org/gradle/build/integtests/JavaProject.groovy we run integration tests for eclipse file generation.

To speed up to get to the integration tests I call the Gradle build like:

gradle -s -Dskip.test -Dskip.javadoc -Dskip.groovydoc -Dskip.archive_all-jdk14_zip -Dskip.userguide -Dskip.archive_src_zip clean integTest

Ah, was unaware of the integration builds. Attached is a modified buildSrc/src/main/resources/org/gradle/build/integtests/javaproject/expectedWebApp1WtpFile.txt

• modified module and lib syntax to match (correct) output generated by revised plugins

Hi Phil,

everything works fine now. I have committed your code patches to trunk.

Some comments/open issues:

• FYI: In the WarPlugin I have modified one line of your patch to eclipseWtp.dependsOn(((ProjectDependency) dependentProject).getProject().getPath() + ":eclipseProject");. In the original code you have used the name property with a trailing colon. This works for one level multi-project builds but not for deeper nesting.
• It would be cool to have a unit tests for EclipseWtpModule
• It would be also very cool to have a basic integration test for the new stuff you have provided. I don't if it makes sense to enhance the JavaProject or if it would be better to use your sample project for this.

I haven't applied your doc patch yet. Somehow it contains absolute paths from your machine. I could somehow extract the stuff. But if it is easy for you it would be handy to have a modified version.

Thank you so much Phil. Good Eclipse support is essential for competing with Maven.

Hans,

I'll get a unit test for eclipseWtpModule written shortly.

I've attached a new doc/sample patch. To apply it, you should just be able to invoke:

patch --dry-run -p1 < ../gradle-eclipsewtp-sample-and-docs.patch

in the root of your checked out tree (eg trunk/)