On Tue, Apr 6, 2010 at 3:49 PM, Geronimo M. H. <[email protected]> wrote:
> On Tuesday 06 April 2010 15:03:54, Hans Dockter wrote: > > On Tue, Apr 6, 2010 at 11:45 AM, Geronimo M. H. <[email protected] > >wrote: > > > Is that function-style task (?) only available for 'copy' or what am I > > > missing? > > > > Yes. We simply haven't gotten around yet to provide similar methods for > > jar/tar/zip. > > Ok, thanks for this statement. > > > ... It is hard to figure out what goes into the archive > > from looking at the build script. This technique is often used because of > > limitations of the build systems. With the Gradle archive API this is no > > longer an issue. Thus usually the archive should declare what goes in it. > > You're totally right - that's why I'm experimenting with the archive tasks. > Currently I've several perl-scripts involved in the build process and I try > to > replace them by gradle, or integrate them into the build process. > Well - not every script makes sense to convert to gradle, cause the > startup-time of gradle is quite notable. Just to give you an idea of the > time > differences: when I call the perlscript to assemble all my webpages > (currently 34 pages) perl takes 0.3s where as the same job with gradle > takes > 9s > That's way too long. I could offer you to have a look at the script to check for potential improvements. This difference can't be just Groovy startup time (which will continue to improve). > > With some archives, there's no problem to build them without temporary > copy. > What I didn't found out yet, how I could integrate a jar from another local > project, that is related by dependency only. That's the point, where gradle > renames jarfiles, so I extended the jar-task of each project by a > copy-action. > So if there's a way, to fetch jarfiles without any chance of changing the > original filename, I surely can live without any copy. > I know you have posted about that. I had no time yet to go through them yet. > > But it has to be true, that I get the latest build, no an outdated jar from > internal cache ... > > Another point, I'm missing for jar-assembling has to do with legal stuff: > To conform different licenses of dependant libraries, I currently have this > repository layout: > 3rdParty > commons > license.txt > commons-logging.jar > jgoodies > license.txt > bindings.jar > ... > > so when I use dependency copiing, I loose the layout and of cause I loose > the > license files. I could copy my repository, but than I don't have dependency > support of gradle. Currently I don't know, how to solve this the gradle > way. > This looks like an interesting use case. I should read your other mails before but nonetheless I give it a try. One hacky way of solving this would be to check: new File(repositoryJar.parentFile, 'license.txt').isFile() and if it exsists copy it to the distribution. But it would be nice to have more declarative way of solving that. For example by adding a custom configuration. I will check your other emails to understand your scenario better. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > > kind regards > > Geronimo > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
