On Mon, Mar 29, 2010 at 7:10 AM, Geronimo M. H. <[email protected]>wrote:
> Hello, > > until the day before yesterday I felt very happy with gradle as my main > focus > was the build system. Yesterday I startet to change the focus back to my > projects and I had to realize, that my projects are broken :( > > So I have to decide, whether I stay with gradle (introducing some > workarounds) > or whether I go back to ant. > > So let me point out my requirements to a build system and please give me > feedback, how these points fit with the design / development plan of > gradle. > > - I like to distinct between development jarfiles and production jarfiles > (gradle looks very attractive supporting that) > Definitely. > > - I consider the filename of a jarfile like a value of a java Integer > instance - you can't never ever change that value. So changing the name of > a > jarfile is not acceptable for me - no matter whether its a foreign artifact > or the result of my own project. - So is there a way to ensure this using > gradle? > I'm not completely sure about your scenario. Where would the right name be defined and where do you want to prevent changing the name? Would you want to define the name in the root script or in a plugin and you want prevent subprojects changing it. We would like to understand what benefits this give you? How do you achieve this in Ant? > > - the assembling of the jarfilename should be part of the configuration > stage > of gradle. To distinct production artifacts from developer artifacts it is > necessary to change the name based on the task-graph. That works fine with > gradle. But accessing the filename should always return the same name, no > matter whether I access the name via internal or external dependency or > whether I ask the archive-configuration for the artifact names. > That's not true at the moment for gradle - but I can't estimate, whether it > is > my fault or an error from gradle. > I see your point. I can't see how we can improve the task graph approach to provide a result you would like. But you have other possibilities. A boring one would be to call the build with -Partifacts=release or -Partifacts=dev and have probably dev as default. That way the names can be set at the very beginning of the configuration. What I don't like here is the awkwardness of command line properties. Another possible approach would be to use the gradle object. gradle.startParameters.taskNames will give you the task names specified on the command line. The draw back of this approach is that the marker task has to be explicitly specified on the command line. Whereas the taskgraph gives you all tasks to be executed. Depending on your scenario, task rules might be another option. How do you solve this with Ant? > > I think, I can live without the distinction of development and production > jars > and add tasks, that handle the internal cache of gradle - if my > requirements > fit with the feature-plans of the near future (~ 3 months). > If changing jarfilenames is a feature / desing decision of gradle and > you're > not willing to support unchangeable filenames, I have to switch back to ant > or whatever. > Our design decision is to embrace the unknown complexity of the enterprise and enable our users to do what they think is right. So we always looking for new use cases to work on that vision. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > > I look forward to your statements. > > kind regards > > Geronimo > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
