About generating artifacts in 0.6

[hdockter]

For 0.6 we will get rid of the default .libs and dists task.

What we will provide is instead is the following:

As in 0.5 the Java plugin adds a number of configurations to the  
project. Some are used to retrieve dependencies. Other are used for  
artifact handling.

There is the master configuration, to which the default archive is  
assigned.

And there is the configuration named 'default' which extends master  
and runtime. The default configuration can be used by other projects  
to get the classpath of the archives and its runtime dependencies.

What is new in 0.6 is, that the Java plugin adds also the rule, that a  
taskname with the pattern build<configurationName> (can you think of a  
better name?) generates the artifacts associated with the configuration.

BTW: I'm not that happy with the configuration name 'master'. I have  
taken it from the recommended ivy setup of the 'Ant in Action' book. I  
don't have a good alternative. Any more specific name (e.g. libs)  
might be misleading for certain scenarios. Thought?

- Hans

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





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

    http://xircles.codehaus.org/manage_email

[Tom Eyckmans]

2009/4/17 Hans Dockter <mail@...>

For 0.6 we will get rid of the default .libs and dists task.

What we will provide is instead is the following:

As in 0.5 the Java plugin adds a number of configurations to the project. Some are used to retrieve dependencies. Other are used for artifact handling.

There is the master configuration, to which the default archive is assigned.

And there is the configuration named 'default' which extends master and runtime. The default configuration can be used by other projects to get the classpath of the archives and its runtime dependencies.

What is new in 0.6 is, that the Java plugin adds also the rule, that a taskname with the pattern build<configurationName> (can you think of a better name?) generates the artifacts associated with the configuration.

(btw I like this a lot :)), I don't have a problem with build but a possible alternative could be make ?

BTW: I'm not that happy with the configuration name 'master'. I have taken it from the recommended ivy setup of the 'Ant in Action' book. I don't have a good alternative. Any more specific name (e.g. libs) might be misleading for certain scenarios. Thought?

base ? from base dependencies (which are the miminal dependencies so base from basic)

- Hans

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





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

  http://xircles.codehaus.org/manage_email

[Steve Appling]

Hans Dockter wrote:

> For 0.6 we will get rid of the default .libs and dists task.
>
> What we will provide is instead is the following:
>
> As in 0.5 the Java plugin adds a number of configurations to the
> project. Some are used to retrieve dependencies. Other are used for
> artifact handling.
>
> There is the master configuration, to which the default archive is
> assigned.
>
> And there is the configuration named 'default' which extends master and
> runtime. The default configuration can be used by other projects to get
> the classpath of the archives and its runtime dependencies.
>
> What is new in 0.6 is, that the Java plugin adds also the rule, that a
> taskname with the pattern build<configurationName> (can you think of a
> better name?) generates the artifacts associated with the configuration.
>
> BTW: I'm not that happy with the configuration name 'master'. I have
> taken it from the recommended ivy setup of the 'Ant in Action' book. I
> don't have a good alternative. Any more specific name (e.g. libs) might
> be misleading for certain scenarios. Thought?

I don't particularly like the name 'master' either - this implies to me that
there is some type of master/slave relationship.  This is just the configuration
that holds the primary archive.  Perhaps 'main' or 'archive' would be better.

I think I like just 'archive', then 'buildArchive' would be equivalent to the
current 'libs' task.

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Hans Dockter wrote:

> For 0.6 we will get rid of the default .libs and dists task.
>
> What we will provide is instead is the following:
>
> As in 0.5 the Java plugin adds a number of configurations to the
> project. Some are used to retrieve dependencies. Other are used for
> artifact handling.
>
> There is the master configuration, to which the default archive is
> assigned.
>
> And there is the configuration named 'default' which extends master
> and runtime. The default configuration can be used by other projects
> to get the classpath of the archives and its runtime dependencies.
>

Why do we need 2 configurations for this? Can we get rid of 'master'?


Adam



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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Apr 22, 2009, at 2:10 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> For 0.6 we will get rid of the default .libs and dists task.
>>
>> What we will provide is instead is the following:
>>
>> As in 0.5 the Java plugin adds a number of configurations to the  
>> project. Some are used to retrieve dependencies. Other are used for  
>> artifact handling.
>>
>> There is the master configuration, to which the default archive is  
>> assigned.
>>
>> And there is the configuration named 'default' which extends master  
>> and runtime. The default configuration can be used by other  
>> projects to get the classpath of the archives and its runtime  
>> dependencies.
>>
>
> Why do we need 2 configurations for this? Can we get rid of 'master'?

default is the configuration which represents both, the (default)  
artifacts produced by the project as well as the dependencies of those  
artifacts. It is important to note that resolving the default  
configuration with transitive set to false, will still return all  
artifacts and the dependencies, but not the transitive dependencies.  
This is the way Ivy behaves. Therefore we have another configuration  
called master, which just represents the artifacts of the project. As  
we have discussed, with the new rich Configuration API it is possible  
to access the artifacts only. But not in the normal way you work with  
configurations. So I'm not sure if we should get rid of master. What  
I'm sure of is, that we need another name if we keep it. :)

- Hans

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





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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Apr 21, 2009, at 7:42 PM, Steve Appling wrote:

> Hans Dockter wrote:
>> For 0.6 we will get rid of the default .libs and dists task.
>> What we will provide is instead is the following:
>> As in 0.5 the Java plugin adds a number of configurations to the  
>> project. Some are used to retrieve dependencies. Other are used for  
>> artifact handling.
>> There is the master configuration, to which the default archive is  
>> assigned.
>> And there is the configuration named 'default' which extends master  
>> and runtime. The default configuration can be used by other  
>> projects to get the classpath of the archives and its runtime  
>> dependencies.
>> What is new in 0.6 is, that the Java plugin adds also the rule,  
>> that a taskname with the pattern build<configurationName> (can you  
>> think of a better name?) generates the artifacts associated with  
>> the configuration.
>> BTW: I'm not that happy with the configuration name 'master'. I  
>> have taken it from the recommended ivy setup of the 'Ant in Action'  
>> book. I don't have a good alternative. Any more specific name (e.g.  
>> libs) might be misleading for certain scenarios. Thought?
>
> I don't particularly like the name 'master' either - this implies to  
> me that there is some type of master/slave relationship.  This is  
> just the configuration that holds the primary archive.  Perhaps  
> 'main' or 'archive' would be better.
>
> I think I like just 'archive', then 'buildArchive' would be  
> equivalent to the current 'libs' task.

For convenience reasons we still have a libs task. It behaves  
differently to build<Configuration> name, in that it builds the jars  
of all configurations. In simple projects this makes no difference.  
There is also still the dists task, which builds all the other archives.

I think 'archives' is much better than 'master'. I think I also like  
'libs' (although we have a task with the same name). Another  
possibility is to call the configuration 'artifacts'.

- Hans

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





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

    http://xircles.codehaus.org/manage_email