search

akhikhl / wuff

Gradle plugin for automating assembly of OSGi/Eclipse bundles and applications
MIT License
152 stars 51 forks source link

Problems After Updating buildDir #11

Closed r02b closed 10 years ago

r02b commented 10 years ago

Hi,

I'm not sure if this is a wuff issue, but I didn't have this problem in a non-wuff compilation, so it seems like a good place to start.

At first, I used the default build directory for my project. Then, I wanted my build directory to be different than the default one. So, in the build.gradle file I've added: project.buildDir = new File("../", "/gradleBuild/"+project.name)

It seemed to be working just fine, but once I removed the old build, located at $myproject/build folder (the default setting), while running the jar task, I receive the following error: .... Caused by: java.lang.IllegalArgumentException: A Jar can only accept a valid file or directory: $myproject/build/classes/main at aQute.bnd.osgi.Jar.(Jar.java:51) at aQute.bnd.osgi.Jar.(Jar.java:69) at aQute.bnd.osgi.Analyzer.setJar(Analyzer.java:833) at org.gradle.api.internal.plugins.osgi.DefaultOsgiManifest.setAnalyzerProperties(DefaultOsgiManifest.java:125) at org.gradle.api.internal.plugins.osgi.DefaultOsgiManifest.getEffectiveManifest(DefaultOsgiManifest.java:69) at org.gradle.api.internal.plugins.osgi.DefaultOsgiManifest_Decorated.getEffectiveManifest(Unknown Source) at org.gradle.api.java.archives.internal.DefaultManifest.writeTo(DefaultManifest.java:151) at org.gradle.api.java.archives.internal.DefaultManifest.writeTo(DefaultManifest.java:35) at org.gradle.api.java.archives.Manifest$writeTo.call(Unknown Source) at org.gradle.api.tasks.bundling.Jar$_closure1_closure3.doCall(Jar.groovy:48) at sun.reflect.GeneratedMethodAccessor869.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:272) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:877) at groovy.lang.Closure.call(Closure.java:412) at groovy.lang.Closure.call(Closure.java:425) at org.gradle.api.internal.file.collections.MapFileTree$FileVisitDetailsImpl.copyTo(MapFileTree.java:155) at org.gradle.api.internal.file.AbstractFileTreeElement.copyFile(AbstractFileTreeElement.java:93) at org.gradle.api.internal.file.AbstractFileTreeElement.copyTo(AbstractFileTreeElement.java:74) ... 82 more

Indicating that the build is actually located within the old configuration (the writing is to the correct address, the source however seems to be the old one).

Have you encountered an issue like this before?

Thanks, Noga

akhikhl commented 10 years ago

No, did not encounter such an issue before. Could you, please, try: project.buildDir = new File("../", "/gradleBuild/"+project.name).canonicalFile

r02b commented 10 years ago

Still the same I'm afraid...

akhikhl commented 10 years ago

I'll try to reproduce it on simple project.

r02b commented 10 years ago

I looked into it some more - it seems to be an OSGI issue. As a workaround I've updated the :jar.manifest.classesDir, which didn't update correctly. It works fine now. Not sure if you should update DefaultOsgiManifest over on your side.

Thanks again for the help!