Hi Adam, the idea to have general solution for all kinds of models sounds great, but like major rework. (Doesn't this essentially mean splitting the configuration phase as Gradle currently knows it?)
Is this part of your short- or mid-term release-planning? Thanks Tim From: Adam Murdoch [mailto:[email protected]] Sent: Dienstag, 13. August 2013 01:00 To: [email protected] Subject: Re: [gradle-dev] Dynamically enabling publications. On 13/08/2013, at 6:59 AM, Tim Enderling <[email protected]<mailto:[email protected]>> wrote: Hi Adam, as stated in the forum [1], we partly generate Java code using JAXB. Based on Java package names we then create different jars, each of which is published as Ivy artifact. If the process generates no classes for a certain Java package name, we don't want to create the (empty) jar and consequently don't want to add it as an Ivy artefact. If the code wasn't generated I agree that it would be easy to add a configuration-time condition (check whether a corresponding source sub-folder exists). In this case however the package(s) for which Java classes are generated are hidden in JAXB-configuration files (.xjb). Parsing these files during configuration time would essentially double a part of the code generation process, the part that calculates the packages - which seems a bad idea for reasons of consistency. (Just to give you the right impression - we have a few hundreds of projects to be built, following the same conventions. So figuring this out manually is also not really an option.) I hope you can see our requirements behind this. Also I'm pretty sure that there are similar other uses to an execution-time condition for publications like there are for tasks (e.g. depending on the output of other tasks). Absolutely. But there's nothing special about publications in that regard, so I'd rather we had a more general solution. The goal we're moving towards with the publications model, plus the other models, is that: 1. There's a point in time where a model is complete and becomes immutable, so that other things can consume the model. 2. The models describe what is rather than what could be. An onlyIf constraint on IvyArtifact - or any model object, including tasks - doesn't meet either of these goals. Instead, we want a solution that allows you to state: In order to figure out the artefacts to be published, I need to first generate the source. Then, if Gradle needs to know what the artefacts to be published are, then it can take care of generating the source (if they have not been generated already). If Gradle doesn't need to know what the artefacts are, then it can skip generating the source. In other words, there is very little difference between the work that is done to configure a particular model and the work that is done to build a particular file. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
