Hi Hans,
sorry for the late response!
> > Sounds like the dilemma of chicken or egg.
>
> I know this situation, as we use a similar approach in the Gradle
> build of Gradle. What we do there right now, is to postpone the
> version configuration of the archives to execution time.
>
> dists {
> zip().doFirst {
> zipFileSet(dir: buildDir) {
> include('*.jar')
> prefix: "${zipRoot}"
> }
> }
> }
>
> This has at least one potential disadvantage. If at configuration some
> other task is interested in the zipFileSets of the zip, it wouldn't
> get the right information. We don't have this use case in our build
> but it could exists. It can also be a little bit confusing for
> uninitiated to understand what is going on and why it is done like
> this. So hopefully we can come up with a more intuitive solution in
> the future.
This is the perfect solution for my problem. I understand the problem you
described, but this is not a use case for us either.
It is neat that you're able to configure the zipFileSet at execution time.
Maybe we should put this into the documentation?
> > For me, the only way around this seems to redefine the dists task:
> > createTask('dists', overwrite: true) {
> > [...]
> > }
> >
> > Unfortunately, I was not able to get this done because I couldn't
> > figure out how to use and configure the Bundle "animal".
>
> I guess I'm missing some background information about the "animal"
> bundle.
You refered to the Bundle Task as "a special animal" in the user guide...
> > and if not, how can you redefine tasks like libs and dists?
>
> You have chosen the right approach for redefining. How would
> redefining solve this problem?
I could redefine the task in a way that it would make use of the prefix
"${zipRoot}" (at execution time).
Thanks for your solution, support and dedication!
Kind Regards
Matthias
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
