Creating a component

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Creating a component

Lóránt Pintér-2
Hi,

Is it future-proof to create my own SoftwareComponents to be published via “ivy-publishing”? Does anyone do this already except for the Java and War plugins?

I’m asking this because SoftwareComponent is in an internal package, and I’ve had some bad experiences with non-stable APIs changing in Gradle 2.0 (I’m looking at you, Binary). :)

Thanks.

-- 

Lóránt Pintér

Developer at Prezi

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a component

Daz DeBoer-2
Hey
Nope, this is not future-proof and is likely to change substantially in the coming months. There's a lot of work going on in order to allow custom component models, which will feed into both dependency resolution and publishing. But for now, only use this if you're prepared to keep updated with the changes.
Daz


On Wed, Jul 23, 2014 at 2:58 PM, Lóránt Pintér <[hidden email]> wrote:
Hi,

Is it future-proof to create my own SoftwareComponents to be published via “ivy-publishing”? Does anyone do this already except for the Java and War plugins?

I’m asking this because SoftwareComponent is in an internal package, and I’ve had some bad experiences with non-stable APIs changing in Gradle 2.0 (I’m looking at you, Binary). :)

Thanks.

-- 

Lóránt Pintér

Developer at Prezi




--
Darrell (Daz) DeBoer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a component

Lóránt Pintér
Hey Daz,

Thanks. Is the DSL for “ivy-publish” about to change as well (it’s @Incubating, just like Binary!), or is it just the classes and interfaces like SoftwareComponent?

-- 
Lóránt

On Wednesday 23 July 2014 at 23:03, Daz DeBoer wrote:

Hey
Nope, this is not future-proof and is likely to change substantially in the coming months. There's a lot of work going on in order to allow custom component models, which will feed into both dependency resolution and publishing. But for now, only use this if you're prepared to keep updated with the changes.
Daz


On Wed, Jul 23, 2014 at 2:58 PM, Lóránt Pintér <[hidden email]> wrote:
Hi,

Is it future-proof to create my own SoftwareComponents to be published via “ivy-publishing”? Does anyone do this already except for the Java and War plugins?

I’m asking this because SoftwareComponent is in an internal package, and I’ve had some bad experiences with non-stable APIs changing in Gradle 2.0 (I’m looking at you, Binary). :)

Thanks.

-- 

Lóránt Pintér

Developer at Prezi




--
Darrell (Daz) DeBoer

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a component

Daz DeBoer-2
The DSL for 'ivy-publish' _may_ change, as we switch it to use the new configuration model. Certainly the semantics of when things are created and configured will change. For the better. 

The current 'deferred configuration' model that the publishing plugins use was a dead-end, and the new configuration model will address this in a much more powerful and elegant way. This will make it much easier to configure the tasks used in publishing, or to configure the project version prior to it being used to configure the publication. (This is currently pretty painful).



On Wed, Jul 23, 2014 at 3:06 PM, Lóránt Pintér <[hidden email]> wrote:
Hey Daz,

Thanks. Is the DSL for “ivy-publish” about to change as well (it’s @Incubating, just like Binary!), or is it just the classes and interfaces like SoftwareComponent?

-- 
Lóránt

On Wednesday 23 July 2014 at 23:03, Daz DeBoer wrote:

Hey
Nope, this is not future-proof and is likely to change substantially in the coming months. There's a lot of work going on in order to allow custom component models, which will feed into both dependency resolution and publishing. But for now, only use this if you're prepared to keep updated with the changes.
Daz


On Wed, Jul 23, 2014 at 2:58 PM, Lóránt Pintér <[hidden email]> wrote:
Hi,

Is it future-proof to create my own SoftwareComponents to be published via “ivy-publishing”? Does anyone do this already except for the Java and War plugins?

I’m asking this because SoftwareComponent is in an internal package, and I’ve had some bad experiences with non-stable APIs changing in Gradle 2.0 (I’m looking at you, Binary). :)

Thanks.

-- 

Lóránt Pintér

Developer at Prezi




--
Darrell (Daz) DeBoer




--
Darrell (Daz) DeBoer
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a component

Lóránt Pintér
Okay, I looked a little deeper.

I can’t seem to find any official DSL or API (even incubating) for adding dependencies to published artifacts right now. Am I missing something? If this is the case, then I can as well create a component, because I’ll be working with changing APIs anyway. :(

Another question: I want to publish my projects to Ivy via IvyPublications, and I also want to refer to them via ProjectDependency's from other projects. In such a case it seems to me that I need to add my artifacts both to IvyPublication.artifact() and to the Project.getArtifacts() container. Am I reading this right?

Thanks.

-- 
Lóránt

On Wednesday 23 July 2014 at 23:16, Daz DeBoer wrote:

The DSL for 'ivy-publish' _may_ change, as we switch it to use the new configuration model. Certainly the semantics of when things are created and configured will change. For the better. 

The current 'deferred configuration' model that the publishing plugins use was a dead-end, and the new configuration model will address this in a much more powerful and elegant way. This will make it much easier to configure the tasks used in publishing, or to configure the project version prior to it being used to configure the publication. (This is currently pretty painful).



On Wed, Jul 23, 2014 at 3:06 PM, Lóránt Pintér <[hidden email]> wrote:
Hey Daz,

Thanks. Is the DSL for “ivy-publish” about to change as well (it’s @Incubating, just like Binary!), or is it just the classes and interfaces like SoftwareComponent?

-- 
Lóránt

On Wednesday 23 July 2014 at 23:03, Daz DeBoer wrote:

Hey
Nope, this is not future-proof and is likely to change substantially in the coming months. There's a lot of work going on in order to allow custom component models, which will feed into both dependency resolution and publishing. But for now, only use this if you're prepared to keep updated with the changes.
Daz


On Wed, Jul 23, 2014 at 2:58 PM, Lóránt Pintér <[hidden email]> wrote:
Hi,

Is it future-proof to create my own SoftwareComponents to be published via “ivy-publishing”? Does anyone do this already except for the Java and War plugins?

I’m asking this because SoftwareComponent is in an internal package, and I’ve had some bad experiences with non-stable APIs changing in Gradle 2.0 (I’m looking at you, Binary). :)

Thanks.

-- 

Lóránt Pintér

Developer at Prezi




--
Darrell (Daz) DeBoer




--
Darrell (Daz) DeBoer

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Creating a component

Daz DeBoer-2
On Thu, Jul 24, 2014 at 6:50 AM, Lóránt Pintér <[hidden email]> wrote:
Okay, I looked a little deeper.

I can’t seem to find any official DSL or API (even incubating) for adding dependencies to published artifacts right now. Am I missing something? If this is the case, then I can as well create a component, because I’ll be working with changing APIs anyway. :(

That's correct. The story for this is https://github.com/gradle/gradle/blob/master/design-docs/publication-model.md#allow-outgoing-dependency-declarations-to-be-customized, which is not yet done. This would make a nice contribution, if anyone has the inclination.


Another question: I want to publish my projects to Ivy via IvyPublications, and I also want to refer to them via ProjectDependency's from other projects. In such a case it seems to me that I need to add my artifacts both to IvyPublication.artifact() and to the Project.getArtifacts() container. Am I reading this right?

No, you shouldn't need to do this. When a project defines a publication via the new publishing mechanism, another project can access that publication via a project dependency. You can see this in action in this integration test and this sample.


Thanks.

-- 
Lóránt

On Wednesday 23 July 2014 at 23:16, Daz DeBoer wrote:

The DSL for 'ivy-publish' _may_ change, as we switch it to use the new configuration model. Certainly the semantics of when things are created and configured will change. For the better. 

The current 'deferred configuration' model that the publishing plugins use was a dead-end, and the new configuration model will address this in a much more powerful and elegant way. This will make it much easier to configure the tasks used in publishing, or to configure the project version prior to it being used to configure the publication. (This is currently pretty painful).



On Wed, Jul 23, 2014 at 3:06 PM, Lóránt Pintér <[hidden email]> wrote:
Hey Daz,

Thanks. Is the DSL for “ivy-publish” about to change as well (it’s @Incubating, just like Binary!), or is it just the classes and interfaces like SoftwareComponent?

-- 
Lóránt

On Wednesday 23 July 2014 at 23:03, Daz DeBoer wrote:

Hey
Nope, this is not future-proof and is likely to change substantially in the coming months. There's a lot of work going on in order to allow custom component models, which will feed into both dependency resolution and publishing. But for now, only use this if you're prepared to keep updated with the changes.
Daz


On Wed, Jul 23, 2014 at 2:58 PM, Lóránt Pintér <[hidden email]> wrote:
Hi,

Is it future-proof to create my own SoftwareComponents to be published via “ivy-publishing”? Does anyone do this already except for the Java and War plugins?

I’m asking this because SoftwareComponent is in an internal package, and I’ve had some bad experiences with non-stable APIs changing in Gradle 2.0 (I’m looking at you, Binary). :)

Thanks.

-- 

Lóránt Pintér

Developer at Prezi




--
Darrell (Daz) DeBoer




--
Darrell (Daz) DeBoer




--
Darrell (Daz) DeBoer
Loading...