Assemblies and destination dir

[hdockter]

Right now jars are put into the libs dir and zips/tars into the  
distribution dir. As we have now unified the tasks dists and libs into  
assemblies I think it would make sense to put all archives into the  
same dir (e.g. assemblies). The reasons for that are more or less the  
same as for unifying the tasks.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Tom Eyckmans]

2009/9/18 Hans Dockter <mail@...>

Right now jars are put into the libs dir and zips/tars into the distribution dir. As we have now unified the tasks dists and libs into assemblies I think it would make sense to put all archives into the same dir (e.g. assemblies). The reasons for that are more or less the same as for unifying the tasks.

Makes sence, I like assemblies as a name.
 

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Hans Dockter wrote:
> Right now jars are put into the libs dir and zips/tars into the
> distribution dir. As we have now unified the tasks dists and libs into
> assemblies I think it would make sense to put all archives into the
> same dir (e.g. assemblies). The reasons for that are more or less the
> same as for unifying the tasks.
>

I don't think they're quite the same thing. The task name expresses what
I want to achieve, ie I want to assemble every thing that the build
produces. The location under $buildDir expresses the type of the thing.
I think this is a good pattern to follow.

You could argue the 'assemblies' is the type of the things being built.
However, I don't think 'assemblies' really expresses the type of the
thing very well. It's not a term I hear used in conversation to
collectively describe jars, wars, zips or tars. I think some options are:

1) Discard the type and put them directly under $buildDir
2) Use a generic type and put them under $buildDir/archives
3) Use specific types and put them under $buildDir/jars, $buildDir/wars,
$buildDir/zips, etc

I think 3 is a good option. It scales well if we were to add new types
of things like application bundles, rpms, native shared libs or native
applications, as they have a natural home.


Adam


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[hdockter]

On Sep 21, 2009, at 11:18 PM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> Right now jars are put into the libs dir and zips/tars into the  
>> distribution dir. As we have now unified the tasks dists and libs  
>> into assemblies I think it would make sense to put all archives  
>> into the same dir (e.g. assemblies). The reasons for that are more  
>> or less the same as for unifying the tasks.
>>
>
> I don't think they're quite the same thing. The task name expresses  
> what I want to achieve, ie I want to assemble every thing that the  
> build produces. The location under $buildDir expresses the type of  
> the thing. I think this is a good pattern to follow.
>
> You could argue the 'assemblies' is the type of the things being  
> built. However, I don't think 'assemblies' really expresses the type  
> of the thing very well. It's not a term I hear used in conversation  
> to collectively describe jars, wars, zips or tars. I think some  
> options are:
>
> 1) Discard the type and put them directly under $buildDir
> 2) Use a generic type and put them under $buildDir/archives
> 3) Use specific types and put them under $buildDir/jars, $buildDir/
> wars, $buildDir/zips, etc
>
> I think 3 is a good option. It scales well if we were to add new  
> types of things like application bundles, rpms, native shared libs  
> or native applications, as they have a natural home.

I agree. One use case I had in mind was to iterate over the produced  
archives and do something with those. But of course you would not use  
a hard coded paths but use the task objects for figuring this out.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email