build fails on :libs:unpuzzle:installEclipse about wuff HOT 29 CLOSED

I'm sorry, but the problem is not reproducible on vanilla VM with the environment: Windows 7 64-bit, Jdk 7 update 55, Gradle 1.11. I just tried it on this configuration. Wuff plugin and all examples compile without errors, all examples are runnable.
Please try the following:

1. delete "C:\Users\YourName.m2"
2. delete "C:\Users\YourName.gradle"
3. delete "C:\Users\YourName.wuff"
4. delete all "build" folders within Wuff (or just clone anew from github)
5. "gradle build" at the root of Wuff.
   What is the result?

from wuff.

Dear Carlo,

Please have a look:

#3

On 11.05.2014 18:07, Carlo Luib-Finetti wrote:

After cloning the git repository, I did a "gradle build" (on Windows 7,
using Jdk1.7 and Gradle 1.11).
Here is the important stack trace:

|Caused by: : Problem: failed to create task or type pom
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any / declarations have taken place.

     at org.apache.tools.ant.UnknownElement.getNotFoundException(UnknownElement.java:499)
     at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:431)
     at org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
     at org.akhikhl.unpuzzle.osgi2maven.Deployer$_deployBundle_closure2.doCall(Deployer.groovy:84

)
at org.akhikhl.unpuzzle.osgi2maven.Deployer.deployBundle(Deployer.groovy:83)
at org.akhikhl.unpuzzle.osgi2maven.Deployer$deployBundle.call(Unknown Source)
at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$_deploy_closure2_closure8.doCall(Eclip
seDeployer.groovy:168)
at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$_deploy_closure2.doCall(EclipseDeploye
r.groovy:167)
at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer.deploy(EclipseDeployer.groovy:166)
at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$deploy.call(Unknown Source)
at org.akhikhl.unpuzzle.Configurer.installEclipse(Configurer.groovy:145)
at org.akhikhl.unpuzzle.Configurer$_apply_closure2_closure7_closure14.doCall(Configurer.groo
vy:66)
at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:502)
|

Please note, the same fail occurs if I do a build on "IdeApp-8" example.

—
Reply to this email directly or view it on GitHub
#3.

Andrey Hihlovskiy, Dipl.-Physiker (russ.)
Systemanalytiker

startext GmbH
Kennedyallee 2; D-53175 Bonn

Tel: +49 (0)228 959 96-25; Fax: +49 (0)228 959 96-66
Internet: www.startext.de
E-Mail: [email protected]

Geschäftsführer: Alexander Herschung, Amtsgericht Bonn HRB 2741
Sitz der Gesellschaft: Bonn

from wuff.

Hello Andrey,
I did what you said. Anyway, I do not like to have Maven oder Gradle caches on "C:\Users\carlo". For Maven, I configured the repository in conf/settings.xml; and for Gradle, I configured an environment variable GRADLE_USER_HOME.
Today I restartet the build for wuff. I found it somewhat strange that I've found the re-establishment of "C:\Users\carlo.m2" (although I have an environment variable named M2_REPO, and although mavenLocal() of Gradle knows my maven repository.

Anyway, the build ended at with a test error:

:libs:wuff-plugin:processTestResources
:libs:wuff-plugin:testClasses
> Building 82% > :libs:wu:libs:wuff-plugin:test

org.akhikhl.wuff.EclipseBundlePluginTest > should inject dependencies FAILED
    org.gradle.api.ProjectConfigurationException at EclipseBundlePluginTest.groovy:54
        Caused by: org.gradle.api.UncheckedIOException at EclipseBundlePluginTest.groovy:54
            Caused by: java.io.IOException at EclipseBundlePluginTest.groovy:54

26 tests completed, 1 failed
:libs:wuff-plugin:test FAILED

Then I went to examples and did a build of IdeApp-8. This came up with "Could not normalize path " and this stacktrace:

Caused by: org.gradle.api.UncheckedIOException: Could not normalize path for file 'D:\Java\git-prj\w
uff\examples\IdeApp-8\MyIdeApp\plugin*.properties'.
        at org.gradle.api.internal.file.AbstractFileResolver.normalise(AbstractFileResolver.java:138
)
        at org.gradle.api.internal.file.AbstractFileResolver.resolve(AbstractFileResolver.java:79)
        at org.gradle.api.internal.file.AbstractFileResolver.resolve(AbstractFileResolver.java:60)
        at org.gradle.api.internal.file.DefaultFileOperations.file(DefaultFileOperations.java:69)
        at org.gradle.api.internal.project.AbstractProject.file(AbstractProject.java:695)
        at org.gradle.api.internal.file.FileOperations$file$0.call(Unknown Source)
        at org.akhikhl.wuff.OsgiBundleConfigurer$_configureTask_processResources_closure11.doCall(Os
giBundleConfigurer.groovy:245)
        at org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:58)
        at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:130)
        at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:110)
        at org.gradle.api.internal.AbstractTask.configure(AbstractTask.java:439)
        at org.gradle.api.internal.AbstractTask.configure(AbstractTask.java:59)
        at org.gradle.api.internal.ClosureBackedAction.execute(ClosureBackedAction.java:50)
        at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:130)
        at org.gradle.util.ConfigureUtil.configure(ConfigureUtil.java:91)
        at org.gradle.api.internal.DefaultNamedDomainObjectCollection$ContainerElementsDynamicObject
.invokeMethod(DefaultNamedDomainObjectCollection.java:324)
        at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:1
47)
        at org.gradle.api.internal.CompositeDynamicObject.invokeMethod(CompositeDynamicObject.java:1
47)
        at org.gradle.api.internal.tasks.DefaultTaskContainer_Decorated.invokeMethod(Unknown Source)

        at org.akhikhl.wuff.OsgiBundleConfigurer.configureTask_processResources(OsgiBundleConfigurer
.groovy:223)
        at org.akhikhl.wuff.JavaConfigurer.configureTasks(JavaConfigurer.groovy:43)
        at org.akhikhl.wuff.OsgiBundleConfigurer.super$3$configureTasks(OsgiBundleConfigurer.groovy)

        at org.akhikhl.wuff.OsgiBundleConfigurer.configureTasks(OsgiBundleConfigurer.groovy:88)
        at org.akhikhl.wuff.EquinoxAppConfigurer.super$4$configureTasks(EquinoxAppConfigurer.groovy)

        at org.akhikhl.wuff.EquinoxAppConfigurer.configureTasks(EquinoxAppConfigurer.groovy:194)
        at org.akhikhl.wuff.Configurer.postConfigure(Configurer.groovy:209)
        at org.akhikhl.wuff.JavaConfigurer.super$2$postConfigure(JavaConfigurer.groovy)
        at org.akhikhl.wuff.JavaConfigurer.postConfigure(JavaConfigurer.groovy:91)

from wuff.

I tried the same scenario with Wuff 0.0.5 from jcenter/maven-central - the problem with "Could not normalize path" is well reproducible.
I met the same problem few days ago and fixed it after 0.0.5 release.
I'll release version 0.0.6 with the fix in a few minutes.

Regarding .m2 folder - I understand your concern. Yes, this folder is hardcoded in Wuff, so it is always re-created. I can move Wuff-specific maven repository to ".wuff" folder. The location of ".wuff" folder is controlled by configuration property wuff.wuffDir. Will it be a good solution for you?

from wuff.

Hi Andrey,
thanks for your immediate response and work!

I just fetched version 0.0.6, did a build on it, and now it's fine. I also build on example IdeApp-8 with no problems. The only thing that didn't work is task 'run'. The eclipse log reports:
java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter

Regarding the directory of the local maven repository, I think it would be a good idea first trying to locate it by parsing 'conf/settings.xml' like this:

String mvnhome = System.getenv()['MAVEN_HOME']
    if (mvnhome) {
        def p = new XmlParser().parse("$mvnhome/conf/settings.xml")
        repoDir = p.localRepository.text()
        println "localRepository = $repoDir"
        def f = new File(repoDir)
        if (f.exists() && f.isDirectory())  {
            println "$repoDir is existing directory!"
        }
    }

and only using $user.home/.m2 as last resort.

The other thing: where can I set ".wuff" dir?

from wuff.

I'll have a look at EclipseStarter problem.

".wuff" dir can be set in wuff configuration in "build.gradle":

wuff {
  wuffDir = '/home/user/wuffDir'
}

wuff configurations are hierarchical, so you can put this to the root project and all subprojects will see and use this declaration. If you go that way, you'll need to apply a plugin to the root project:

apply plugin: 'eclipse-config'

this plugin only creates wuff configuration, nothing else. You don't need 'eclipse-config' on other projects, if they already apply other plugins like 'eclipse-rcp-app', 'eclipse-ide-app', etc.

from wuff.

BTW, thanks for a nice idea with .m2 setup. I will try to implement it over this weekend.

from wuff.

wuffDir must be a file object:

wuff {
  wuffDir = new File('/home/user/wuffDir')
}

(well, I did something like this, but when moving the original folder, poor Windows ran into an error because file path was too long...).

from wuff.

yes, you are right, it is file :) your motivation on customizing directories is clear.

from wuff.

EclipseStarter problem seems to be Windows-specific. It does not appear on Linux, but reliably reproducible on Windows. I'll check how file paths are formatted and handled...
Also things work 100% on both platforms, when running a compiled product. So it is only "run" task that suffers.

from wuff.

I'm having the exact same issue on Windows 7/JDK7/gradle 2.0/wuff 0.0.12.
I also tried gradle 1.11 and older versions of wuff, still same result.
Any further insights what might cause the problem?
Any help is highly appreciated :-)
Stacktrace is more or less the same:

> Problem: failed to create task or type pom
  Cause: The name is undefined.
  Action: Check the spelling.
  Action: Check that any custom tasks/types have been declared.
  Action: Check that any <presetdef>/<macrodef> declarations have taken place.

 at org.apache.tools.ant.UnknownElement.getNotFoundException(UnknownElement.java:499)
 at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:431)
 at org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:163)
 at org.akhikhl.unpuzzle.osgi2maven.Deployer$_deployBundle_closure2.doCall(Deployer.groovy:99)
 at org.akhikhl.unpuzzle.osgi2maven.Deployer.deployBundle(Deployer.groovy:98)
 at org.akhikhl.unpuzzle.osgi2maven.Deployer$deployBundle.call(Unknown Source)
 at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$_deploy_closure2_closure8.doCall(EclipseDeployer.groovy:171)
 at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$_deploy_closure2.doCall(EclipseDeployer.groovy:170)
 at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer.deploy(EclipseDeployer.groovy:169)
 at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$deploy.call(Unknown Source)
 at org.akhikhl.unpuzzle.Configurer.installEclipse(Configurer.groovy:145)
 at org.akhikhl.unpuzzle.Configurer$installEclipse.call(Unknown Source)
 at org.akhikhl.wuff.Configurer.getSelectedEclipseMavenGroup(Configurer.groovy:162)
 at org.akhikhl.wuff.Configurer.postConfigure(Configurer.groovy:212)
 at org.akhikhl.wuff.JavaConfigurer.super$2$postConfigure(JavaConfigurer.groovy)
 at org.akhikhl.wuff.JavaConfigurer.postConfigure(JavaConfigurer.groovy:91)
 at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:40)
 at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(ClosureBackedMethodInvocationDispatch.java:25)
 at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:79)
 at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java:31)
 at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
 at com.sun.proxy.$Proxy13.afterEvaluate(Unknown Source)
 at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfterEvaluate(LifecycleProjectEvaluator.java:67)
 ... 26 more

from wuff.

Could you, please, try reproducing this problem on Wuff 0.0.13-SNAPSHOT?

If you are compiling Wuff examples from Wuff git repository, just do git pull and recompile. Wuff examples already use snapshot version.

Otherwise, please insert the following code in order to use snapshot version:

buildscript {
  repositories {
    mavenLocal()
    jcenter()
    maven { url 'http://oss.jfrog.org/artifactory/oss-snapshot-local' }
  }

  dependencies {
    classpath 'org.akhikhl.wuff:wuff-plugin:0.0.13-SNAPSHOT'
  }
}

repositories {
  mavenLocal()
  jcenter()
  maven { url 'http://oss.jfrog.org/artifactory/oss-snapshot-local' }
}

Important: Please use gradle wrapper for compiling things, i.e. "gradlew.bat build".

from wuff.

Hi!
Thanks for getting back onto this issue. Unfortunately the problem remains, with exactly the same result and stacktrace...

from wuff.

@andreas-schilling,

1. is the error reproducible, when you run via gradle-wrapper?
2. do you run one of Wuff examples (if so, which one) or another app?
3. can you produce the smallest possible gradle script, allowing to reproduce a problem?

from wuff.

@carlolf, is EclipseStarter problem reproducible on Wuff 0.0.13-SNAPSHOT?

from wuff.

@akhikhl yes, it also appears via the gradle wrapper.
I don't run one of the examples, but I will do so soon to make sure they work. I directly gave it a try with one of our projects.

from wuff.

I'll surely fix the problem once we figure out how to reproduce it.

from wuff.

I had the exact same problem on 2 machines (including my Jenkins server) - but others were working well. The problem was, that on those two machines, one of the directories had spaces in them, and Deployer went crazy. Maybe thats the same issue? The error message was the same:

Deploying artifacts
      [zip] Building zip: /tmp/4ad9dac5-e2c1-4f07-bf62-8768fcf59dff/org.apache.axis-1.4.0.v201005080400.jar


FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':client'.
> Problem: failed to create task or type pom
  Cause: The name is undefined.
  Action: Check the spelling.
  Action: Check that any custom tasks/types have been declared.
  Action: Check that any <presetdef>/<macrodef> declarations have taken place.

from wuff.

@mcmil, that's interesting. I'll try to reproduce it on directories with spaces.

from wuff.

I've checked it once more on my machine (had no problems on it up to this point) and I can confirm that spaces cause problems. What I've did:

• Removed .wuff directory from C:\Users\mcmil\ (so that Deployer could act)
• Checked out a fresh copy of my project to the directory gradle test (note the space)
• Executed gradle clean (deployer starts) and after downloading the whole eclipse distribution I've got (after the collecting artifacts phase) an error:

Deploying artifacts
      [zip] Building zip: C:\Users\mcmil\AppData\Local\Temp\f4423c0e-aace-45b6-a
099-a8cc6d5d1872\javax.xml.rpc-1.1.0.v201209140446.jar


FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':client'.
> Problem: failed to create task or type pom
  Cause: The name is undefined.
  Action: Check the spelling.
  Action: Check that any custom tasks/types have been declared.
  Action: Check that any <presetdef>/<macrodef> declarations have taken place.

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring pro
ject ':client'.
(...)    
Caused by: : Problem: failed to create task or type pom
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any <presetdef>/<macrodef> declarations have taken place.

        at org.apache.tools.ant.UnknownElement.getNotFoundException(UnknownEleme
nt.java:499)
        at org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:43
1)
        at org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.jav
a:163)
        at org.akhikhl.unpuzzle.osgi2maven.Deployer$_deployBundle_closure2.doCal
l(Deployer.groovy:109)
        at org.akhikhl.unpuzzle.osgi2maven.Deployer.deployBundle(Deployer.groovy
:108)
        at org.akhikhl.unpuzzle.osgi2maven.Deployer$deployBundle.call(Unknown So
urce)
        at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$_deploy_closure2_c
losure8.doCall(EclipseDeployer.groovy:177)
        at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$_deploy_closure2.d
oCall(EclipseDeployer.groovy:176)
        at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer.deploy(EclipseDepl
oyer.groovy:175)
        at org.akhikhl.unpuzzle.eclipse2maven.EclipseDeployer$deploy$0.call(Unkn
own Source)
        at org.akhikhl.unpuzzle.Configurer.installEclipse(Configurer.groovy:151)

        at org.akhikhl.unpuzzle.Configurer$installEclipse$2.call(Unknown Source)

        at org.akhikhl.wuff.Configurer.getSelectedEclipseMavenGroup(Configurer.g
roovy:166)
        at org.akhikhl.wuff.Configurer.postConfigure(Configurer.groovy:217)
        at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(Cl
osureBackedMethodInvocationDispatch.java:40)
        at org.gradle.listener.ClosureBackedMethodInvocationDispatch.dispatch(Cl
osureBackedMethodInvocationDispatch.java:25)
        at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java
:83)
        at org.gradle.listener.BroadcastDispatch.dispatch(BroadcastDispatch.java
:31)
        at org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocat
ionHandler.invoke(ProxyDispatchAdapter.java:93)
        at com.sun.proxy.$Proxy13.afterEvaluate(Unknown Source)
        at org.gradle.configuration.project.LifecycleProjectEvaluator.notifyAfte
rEvaluate(LifecycleProjectEvaluator.java:67)
        ... 49 more
BUILD FAILED

Full stack trace: http://pastebin.com/ksxVKiMg

• Next I've changed the directory name to gradle_test
• Started gradle clean again - this time everything went well.

Additionally I've observed the same behaviour on Windows and Linux, both under JDK 1.8.0_05x64 and JDK 1.8.0_20x64.

from wuff.

I was facing the same issue. The reason was a space in in the project path.

from wuff.

Last time I tried it wasn't a problem any more.

from wuff.

From my understanding, this fix was supposed to target 0.13? I am using that version and I just encountered the same issue. Removing the spaces from the path fixed the issue, so it appears to still be occurring in the latest release.

For reference, I am using Windows as well with JDK 1.7.0_17-b02

from wuff.

No, it wasn't fixed. It just that our colleagues found workaround (use path without spaces).
Is it a blocker for you?

from wuff.

Blocker may be too strong the word, but it does mean I must rename several project folders. I'm worried however that when we integrate the Gradle builds with our CI server Bamboo, I cannot confirm if all the paths on the remote agents will be space-free.

To sum up: not a blocker at this instant, but there exists a good chance it could be a time bomb.

from wuff.

I agree with your concern. I'll see to fixing it.

from wuff.

Thank you. I'll continue following this issue in the event you want/need me to test the fix.

from wuff.

I'm just getting started with using Wuff. I was following the steps here... https://github.com/akhikhl/wuff/wiki/Convert-existing-Eclipse-plugins-and-apps-to-Gradle and I couldn't understand why my hello world projects wouldn't build. Took me a while to find this page and try the work around of removing spaces from the directory names. Is there an issue created just for this issue? I wouldn't mind taking a crack at fixing it.

from wuff.

Hi there

We are running into this issue (wuff fails if a space is in the project path) in the moment (on Windows and Linux). It’s a major inconvenience for us.

Any chances that this will be fixed soon?

from wuff.