Question about DefaultConfiguration#getDependencies() method

View: New views
3 Messages — Rating Filter:   Alert me  

Question about DefaultConfiguration#getDependencies() method

by Steven Devijver-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
Hey,

I have this configuration:

dependencies {
moduleJars project('java14')
moduleJars project('java15')
}
task moduleJar(type: Jar) {
destinationDir = file('build/jar_for_module')
baseName = project.name
dependsOn configurations.moduleJars.buildDependencies
}

The java15 project depends on the java14 project. However, when I run the moduleJar task the dependency of the java15 project on the java14 project seems to be somehow forgotten:

C:\dev1\spring-framework-2.5.6.SEC01>gradle -s clean build upload | more
:modules:spring-beans:java14:clean
:modules:spring-beans:java15:clean
:modules:spring-core:java14:clean
:modules:spring-core:java15:clean
:modules:spring-core:java14:compileJava
:modules:spring-core:java14:processResources
:modules:spring-core:java14:classes
:modules:spring-core:java14:jar
:modules:spring-core:java15:compileJava
C:\dev1\spring-framework-2.5.6.SEC01\tiger\src\org\springframework\core\annotati
on\AnnotationAwareOrderComparator.java:19: cannot find symbol
symbol  : class OrderComparator
location: package org.springframework.core
import org.springframework.core.OrderComparator;
                               ^

Is this as expected? I found I had to let the moduleJar task depend on the build dependencies of the specific configuration, otherwise the jar file would be empty and the java14 and java15 project would no be built.

Thanks for your help

Steven 


Re: Question about DefaultConfiguration#getDependencies() method

by hdockter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On Oct 16, 2009, at 4:08 PM, Steven Devijver wrote:

Hey,

I have this configuration:

dependencies {
moduleJars project('java14')
moduleJars project('java15')
}
task moduleJar(type: Jar) {
destinationDir = file('build/jar_for_module')
baseName = project.name
dependsOn configurations.moduleJars.buildDependencies
}

The java15 project depends on the java14 project. However, when I run the moduleJar task the dependency of the java15 project on the java14 project seems to be somehow forgotten:

C:\dev1\spring-framework-2.5.6.SEC01>gradle -s clean build upload | more
:modules:spring-beans:java14:clean
:modules:spring-beans:java15:clean
:modules:spring-core:java14:clean
:modules:spring-core:java15:clean
:modules:spring-core:java14:compileJava
:modules:spring-core:java14:processResources
:modules:spring-core:java14:classes
:modules:spring-core:java14:jar
:modules:spring-core:java15:compileJava
C:\dev1\spring-framework-2.5.6.SEC01\tiger\src\org\springframework\core\annotati
on\AnnotationAwareOrderComparator.java:19: cannot find symbol
symbol  : class OrderComparator
location: package org.springframework.core
import org.springframework.core.OrderComparator;
                               ^

Is this as expected? I found I had to let the moduleJar task depend on the build dependencies of the specific configuration, otherwise the jar file would be empty and the java14 and java15 project would no be built.

This is expected (so far). We distinguish between external dependencies and buildable dependencies (e.g projects). Asking a configuration for its files will not automatically trigger a build of those dependencies (because this is not always what you want). Therefore you need to dependOn buildDependencies if you want want to access the files of a configuration with buildable dependencies.

But since 0.8 we have an autowiring for those two steps. Most of the gradle build in tasks make use of this. 

task moduleJar(type: Jar) {
from configurations.moduleJars
}

will make this task automatically dependent on the moduleJars.buildDependencies. There is one thing to notice. If nothing else is added to the jar, you get the message that the jar gets skipped because no files are included. But in fact the archive gets properly created. We will fix this confusing warnings soon.

Does this solve all your issues with this?

- Hans

--
Hans Dockter
Gradle Project Manager

Re: Question about DefaultConfiguration#getDependencies() method

by Adam Murdoch-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.


Steven Devijver wrote:
Hey,

I have this configuration:

dependencies {
moduleJars project('java14')
moduleJars project('java15')
}
task moduleJar(type: Jar) {
destinationDir = file('build/jar_for_module')
baseName = project.name
dependsOn configurations.moduleJars.buildDependencies
}

The java15 project depends on the java14 project. However, when I run the moduleJar task the dependency of the java15 project on the java14 project seems to be somehow forgotten:

C:\dev1\spring-framework-2.5.6.SEC01>gradle -s clean build upload | more
:modules:spring-beans:java14:clean
:modules:spring-beans:java15:clean
:modules:spring-core:java14:clean
:modules:spring-core:java15:clean
:modules:spring-core:java14:compileJava
:modules:spring-core:java14:processResources
:modules:spring-core:java14:classes
:modules:spring-core:java14:jar
:modules:spring-core:java15:compileJava
C:\dev1\spring-framework-2.5.6.SEC01\tiger\src\org\springframework\core\annotati
on\AnnotationAwareOrderComparator.java:19: cannot find symbol
symbol  : class OrderComparator
location: package org.springframework.core
import org.springframework.core.OrderComparator;
                               ^

Is this as expected?

It depends on how you've declared the dependency of the java15 project on the java14 project. How have you done this?

I found I had to let the moduleJar task depend on the build dependencies of the specific configuration, otherwise the jar file would be empty and the java14 and java15 project would no be built.


The auto task dependency stuff is this very much a work in progress - it works for some things and not for others. It really just does the minimum that the java plugin needs at this stage. Hopefully we'll have time to include the general solution in the 0.9 release.


-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org