Steve Appling wrote:
Did you ever wonder why the gradle-wrapper jar went from 10k in
version 0.5 to 1,140k in version 0.6. It's because the jar task has
been broken :(
The convention resouceCollection is always added to the jar even if
you specify another fileset. This results in strange behavior, such as:
task wrapperJar(type: Jar) {
appendix = 'wrapper'
fileSet(dir: classesDir) {
include 'org/gradle/wrapper/'
}
}
For the previous task, it will end up with the fileset from the
convention (fileSet(dir:classesDir)) in addition to the one you
specified above. This means that files which meet both specs will
actually end up in the jar twice! I didn't even know you could do
that, but you can see the duplicates of Wrapper.class in
gradle-wrapper-0.6.jar (and later).
I think the problem is introduced in
AbstractArchiveTask.resourceCollections (AbstractArchiveTask.java line
229):
resourceCollections = GUtil.chooseCollection(resourceCollections,
getResourceCollections())
If you are setting up a new resourceCollections, you probably don't
need to add the convention one first.
Sometimes you do, and sometimes you don't. For a JAR, you probably
don't, but sometimes do. For a WAR, you probably do, but sometimes
don't. Our model isn't rich enough for us to tell, nor is our convention
mapping flexible enough to deal with it. Hopefully we can get something
better in the 0.8 release.
I think this is the same problem as
http://jira.codehaus.org/browse/GRADLE-530. I've 'fixed' it for now by
not including the classes fileset as a resource collection in the
convention mapping for Jar tasks.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email