Gradle for platform development?

[Chip Collier]

Hi folks,


Out of curiosity, is anyone using Gradle for their development?


Thanks!

Chip

[Tim Boudreau]

I've considered it a few times, but haven't ever decided it was worth it.

I've seen a *lot* of projects with incredibly complicated build systems
that typically only one person understands if anyone does (and that
includes NetBeans' own Ant infrastructure - though that's far from the
worst I've seen), and seen that cost teams a lot of time and energy. Ant
gives you enough rope to hang yourself unless you're more disciplined than
you can ever guarantee that every human being on a team is.

Gradle similarly gives you enough rope to hang yourself.

IMO, the bottom line is, if your project's build infrastructure is
interesting, something is usually wrong with the project. There is a lot
not to like about Maven, but when you want to do something, er,
"interesting" with the way your software is built, there *should* be some
resistance there to push back, so that you have to be really sure there's a
genuine need to do something fancy - because that means adding complexity
that has a cost, and "it seemed like a good idea at the time" is not a good
enough reason for that.

So in that sense, Gradle seems like a step backwards or at best sideways.
I get the appeal of scriptable builds, but my experience is that more
often than not, the ability to do that does more harm than good.

-Tim

[Radim Kubacki]

Hi,

AFAIK most likely the answer is not. Now, my question is why do you want to
do this?

Some ideas on the possibility to do NB platform development with Gradle:
1. My suggestion is to wrap Ant build into Gradle. If this is done as a
plugin you can try to mark inputs and outputs from various tasks and
probably will get a faster build. Use these projects as default apisupport
projects in the IDE to keep all the goodness of advanced tooling support.
Possibly look for / add possibility to run Gradle tasks from IDE even if it
is not Gradle project. Make sure you can launch tests and the app / module
/ module suite from Gradle. I can try to do it just to see how difficult it
would be.

2. Ant based apisupport is nice but its dependency management is awkward
(anyone using Ivy for that purpose?). It'd be nice to get the first step
and mix it with dependencies from maven-netbeans-plugin or Ivy. At least
for me that sounds like a benefit. I do know how hard it would be. I do
want to reuse maven-netbeans-plugin directly. For one it is probably harder
and for another IIRC it use Ant tasks from NetBeans harness anyway.

Would you be willing to contribute to this?

To Tim: You know, I am opinionated on this topic. Yes, I agree there is
enough rope in Gradle. Build scripts are part of the code similarly as
Chef/Puppet/Ansible recipes. And similarly to these you want to split
declarative (what) and imperative (how) parts. It is encouraged by best
practices in Gradle. This is one of the areas where different tools will
give you different guidance. Partly this is why it is easy to make your own
trap in Maven too(maven-ant-plugin to migrate old build stuff and add some
maven-groovy-plugin to cover what does not fit to Maven convention).

-Radim

Post by Chip Collier
Hi folks,
Out of curiosity, is anyone using Gradle for their development?
Thanks!
Chip

[Chip Collier]

Thanks for the responses.

AFAIK most likely the answer is not. Now, my question is why do you want to do this?

The tl;dr version is that I would like to move to a single build system for our repository at work. At the moment we have an assortment of shell scripts, Makefiles, build.sbt, gruntfile.js, setup.py, CMakeLists.txt, *.pro files (qmake), and now a couple of pom.xml. If we can replace or wrap these layer by layer so that everyone can simply expect to see or use a build.gradle that would be a very good thing.

Gradle similarly gives you enough rope to hang yourself.

It's important that our build is not tied to specific IDE or platform. Gradle might offer a lot of rope, but trust me when I say we're already all tangled up in a multitude of other ropes. It would actually be nice to unify our build process on a system that supports the breadth of languages we use and offers enough flexibility to orchestrate our releases. Aside from the wide language support, Gradle plugins offer a lot of value for the kinds of automation available. And the only really interesting thing about our idea of a build here is that it's essentially a lot of subprojects. Each build itself isn't that interesting, but building everything and releasing it can be pretty exciting because it's all over the map where and how any of it happens.
There isn't currently a single person here that understands it all (the original authors have since moved to other companies), however I'm attempting to grok as much as I can in order to bring back some sanity. Because if your build system isn't capable of automating *everything* you need, "life will find a way" to do it otherwise.

It didn't take much to convince my boss and our client that leveraging the Netbeans RCP is a huge win for the project and now I want to make sure that I remove any impedance for future contributors or maintainers. I chose Maven despite having never used it because it made development with IntelliJ with a mix of Scala and Java a great deal easier. Yet it's a lot of training before you even get to the good stuff of learning and using the RCP.
I generally find Sbt to be an agreeable build system but it's very specific to Scala. I briefly considered working on an Sbt plugin for RCP development, but other than having a personal interest in that it didn't seem like a good use of my employers time because it wouldn't be solving the larger issues of a unified build in our repository.

I'd be very happy to contribute to an effort to bring Gradle to RCP development. I'm not opposed to the idea of Gradle wrapping another build if that gets the ball rolling and truth be told that will still be required for other parts of the repository (anywhere we need to use setup.py for instance, and potentially any Qt applications/plugins).

Cheers,
Chip


----- Original Message -----

From: "Radim Kubacki" <***@kubacki.cz>
To: ***@platform.netbeans.org
Sent: Monday, January 13, 2014 1:55:43 AM
Subject: [platform-dev] Re: Gradle for platform development?

Hi,

AFAIK most likely the answer is not. Now, my question is why do you want to do this?

Some ideas on the possibility to do NB platform development with Gradle:
1. My suggestion is to wrap Ant build into Gradle. If this is done as a plugin you can try to mark inputs and outputs from various tasks and probably will get a faster build. Use these projects as default apisupport projects in the IDE to keep all the goodness of advanced tooling support. Possibly look for / add possibility to run Gradle tasks from IDE even if it is not Gradle project. Make sure you can launch tests and the app / module / module suite from Gradle. I can try to do it just to see how difficult it would be.

2. Ant based apisupport is nice but its dependency management is awkward (anyone using Ivy for that purpose?). It'd be nice to get the first step and mix it with dependencies from maven-netbeans-plugin or Ivy. At least for me that sounds like a benefit. I do know how hard it would be. I do want to reuse maven-netbeans-plugin directly. For one it is probably harder and for another IIRC it use Ant tasks from NetBeans harness anyway.

Would you be willing to contribute to this?

To Tim: You know, I am opinionated on this topic. Yes, I agree there is enough rope in Gradle. Build scripts are part of the code similarly as Chef/Puppet/Ansible recipes. And similarly to these you want to split declarative (what) and imperative (how) parts. It is encouraged by best practices in Gradle. This is one of the areas where different tools will give you different guidance. Partly this is why it is easy to make your own trap in Maven too(maven-ant-plugin to migrate old build stuff and add some maven-groovy-plugin to cover what does not fit to Maven convention).

-Radim


2014/1/11 Chip Collier < ***@laika.com >


Hi folks,


Out of curiosity, is anyone using Gradle for their development?


Thanks!

Chip

[Radim Kubacki]

OK, that makes sense. Having one build system for such a heterogeneous set
of technologies is a nice vision.

If I understand correctly you have a project(s) using NetBeans RCP and
develop it using Maven. There is Java used and possibly Scala and the IDE
of choice is IntelliJ (and/or NetBeans?). Now giving the second thought to
idea of wrapping Ant build with Gradle I think it has to be possible to do
it even with dependency management similarly as it is done in Maven support
for NetBeans. I mean to move module dependencies from Ant's
nbproject/project.xml into build.gradle (Maven also has its dependencies in
pom.xml only). Sounds interesting and I can try to sketch something.
Unfortunately my big problem is lack of time.

Regards,
Radim

Post by Chip Collier
Thanks for the responses.

Post by Chip Collier

Post by Radim Kubacki
AFAIK most likely the answer is not. Now, my question is why do you

want to do this?
The tl;dr version is that I would like to move to a single build system
for our repository at work. At the moment we have an assortment of shell
scripts, Makefiles, build.sbt, gruntfile.js, setup.py, CMakeLists.txt,
*.pro files (qmake), and now a couple of pom.xml. If we can replace or wrap
these layer by layer so that everyone can simply expect to see or use a
build.gradle that would be a very good thing.

Post by Chip Collier

Post by Radim Kubacki
Gradle similarly gives you enough rope to hang yourself.

It's important that our build is not tied to specific IDE or platform.
Gradle might offer a lot of rope, but trust me when I say we're already all
tangled up in a multitude of other ropes. It would actually be nice to
unify our build process on a system that supports the breadth of languages
we use and offers enough flexibility to orchestrate our releases. Aside
from the wide language support, Gradle plugins offer a lot of value for the
kinds of automation available. And the only really interesting thing about
our idea of a build here is that it's essentially a lot of subprojects.
Each build itself isn't that interesting, but building everything and
releasing it can be pretty exciting because it's all over the map where and
how any of it happens.
There isn't currently a single person here that understands it all (the
original authors have since moved to other companies), however I'm
attempting to grok as much as I can in order to bring back some sanity.
Because if your build system isn't capable of automating *everything* you
need, "life will find a way" to do it otherwise.
It didn't take much to convince my boss and our client that leveraging the
Netbeans RCP is a huge win for the project and now I want to make sure that
I remove any impedance for future contributors or maintainers. I chose
Maven despite having never used it because it made development with
IntelliJ with a mix of Scala and Java a great deal easier. Yet it's a lot
of training before you even get to the good stuff of learning and using the
RCP.
I generally find Sbt to be an agreeable build system but it's very
specific to Scala. I briefly considered working on an Sbt plugin for RCP
development, but other than having a personal interest in that it didn't
seem like a good use of my employers time because it wouldn't be solving
the larger issues of a unified build in our repository.
I'd be very happy to contribute to an effort to bring Gradle to RCP
development. I'm not opposed to the idea of Gradle wrapping another build
if that gets the ball rolling and truth be told that will still be required
for other parts of the repository (anywhere we need to use setup.py for
instance, and potentially any Qt applications/plugins).
Cheers,
Chip
------------------------------
*Sent: *Monday, January 13, 2014 1:55:43 AM
*Subject: *[platform-dev] Re: Gradle for platform development?
Hi,
AFAIK most likely the answer is not. Now, my question is why do you want to do this?
1. My suggestion is to wrap Ant build into Gradle. If this is done as a
plugin you can try to mark inputs and outputs from various tasks and
probably will get a faster build. Use these projects as default apisupport
projects in the IDE to keep all the goodness of advanced tooling support.
Possibly look for / add possibility to run Gradle tasks from IDE even if it
is not Gradle project. Make sure you can launch tests and the app / module
/ module suite from Gradle. I can try to do it just to see how difficult it
would be.
2. Ant based apisupport is nice but its dependency management is awkward
(anyone using Ivy for that purpose?). It'd be nice to get the first step
and mix it with dependencies from maven-netbeans-plugin or Ivy. At least
for me that sounds like a benefit. I do know how hard it would be. I do
want to reuse maven-netbeans-plugin directly. For one it is probably harder
and for another IIRC it use Ant tasks from NetBeans harness anyway.
Would you be willing to contribute to this?
To Tim: You know, I am opinionated on this topic. Yes, I agree there is
enough rope in Gradle. Build scripts are part of the code similarly as
Chef/Puppet/Ansible recipes. And similarly to these you want to split
declarative (what) and imperative (how) parts. It is encouraged by best
practices in Gradle. This is one of the areas where different tools will
give you different guidance. Partly this is why it is easy to make your own
trap in Maven too(maven-ant-plugin to migrate old build stuff and add some
maven-groovy-plugin to cover what does not fit to Maven convention).
-Radim

Post by Chip Collier
Hi folks,
Out of curiosity, is anyone using Gradle for their development?
Thanks!
Chip

[Chip Collier]

Whatever you come up with (and whenever you have both the time and motivation/interest) I'd love to see it. In the mean time I'm going to look over the Maven plugins as a guide to a working Gradle plugin or build. I'll post as I have updates.

Cheers,

Chip

----- Original Message -----

From: "Radim Kubacki" <***@kubacki.cz>
To: ***@platform.netbeans.org
Sent: Monday, January 13, 2014 11:17:51 PM
Subject: [platform-dev] Re: Gradle for platform development?

OK, that makes sense. Having one build system for such a heterogeneous set of technologies is a nice vision.

If I understand correctly you have a project(s) using NetBeans RCP and develop it using Maven. There is Java used and possibly Scala and the IDE of choice is IntelliJ (and/or NetBeans?). Now giving the second thought to idea of wrapping Ant build with Gradle I think it has to be possible to do it even with dependency management similarly as it is done in Maven support for NetBeans. I mean to move module dependencies from Ant's nbproject/project.xml into build.gradle (Maven also has its dependencies in pom.xml only). Sounds interesting and I can try to sketch something. Unfortunately my big problem is lack of time.

Regards,
Radim


2014/1/13 Chip Collier < ***@laika.com >



Thanks for the responses.

AFAIK most likely the answer is not. Now, my question is why do you want to do this?

The tl;dr version is that I would like to move to a single build system for our repository at work. At the moment we have an assortment of shell scripts, Makefiles, build.sbt, gruntfile.js, setup.py, CMakeLists.txt, *.pro files (qmake), and now a couple of pom.xml. If we can replace or wrap these layer by layer so that everyone can simply expect to see or use a build.gradle that would be a very good thing.

Gradle similarly gives you enough rope to hang yourself.

It's important that our build is not tied to specific IDE or platform. Gradle might offer a lot of rope, but trust me when I say we're already all tangled up in a multitude of other ropes. It would actually be nice to unify our build process on a system that supports the breadth of languages we use and offers enough flexibility to orchestrate our releases. Aside from the wide language support, Gradle plugins offer a lot of value for the kinds of automation available. And the only really interesting thing about our idea of a build here is that it's essentially a lot of subprojects. Each build itself isn't that interesting, but building everything and releasing it can be pretty exciting because it's all over the map where and how any of it happens.
There isn't currently a single person here that understands it all (the original authors have since moved to other companies), however I'm attempting to grok as much as I can in order to bring back some sanity. Because if your build system isn't capable of automating *everything* you need, "life will find a way" to do it otherwise.

It didn't take much to convince my boss and our client that leveraging the Netbeans RCP is a huge win for the project and now I want to make sure that I remove any impedance for future contributors or maintainers. I chose Maven despite having never used it because it made development with IntelliJ with a mix of Scala and Java a great deal easier. Yet it's a lot of training before you even get to the good stuff of learning and using the RCP.
I generally find Sbt to be an agreeable build system but it's very specific to Scala. I briefly considered working on an Sbt plugin for RCP development, but other than having a personal interest in that it didn't seem like a good use of my employers time because it wouldn't be solving the larger issues of a unified build in our repository.

I'd be very happy to contribute to an effort to bring Gradle to RCP development. I'm not opposed to the idea of Gradle wrapping another build if that gets the ball rolling and truth be told that will still be required for other parts of the repository (anywhere we need to use setup.py for instance, and potentially any Qt applications/plugins).

Cheers,
Chip



From: "Radim Kubacki" < ***@kubacki.cz >
To: ***@platform.netbeans.org
Sent: Monday, January 13, 2014 1:55:43 AM
Subject: [platform-dev] Re: Gradle for platform development?


Hi,

AFAIK most likely the answer is not. Now, my question is why do you want to do this?

Some ideas on the possibility to do NB platform development with Gradle:
1. My suggestion is to wrap Ant build into Gradle. If this is done as a plugin you can try to mark inputs and outputs from various tasks and probably will get a faster build. Use these projects as default apisupport projects in the IDE to keep all the goodness of advanced tooling support. Possibly look for / add possibility to run Gradle tasks from IDE even if it is not Gradle project. Make sure you can launch tests and the app / module / module suite from Gradle. I can try to do it just to see how difficult it would be.

2. Ant based apisupport is nice but its dependency management is awkward (anyone using Ivy for that purpose?). It'd be nice to get the first step and mix it with dependencies from maven-netbeans-plugin or Ivy. At least for me that sounds like a benefit. I do know how hard it would be. I do want to reuse maven-netbeans-plugin directly. For one it is probably harder and for another IIRC it use Ant tasks from NetBeans harness anyway.

Would you be willing to contribute to this?

To Tim: You know, I am opinionated on this topic. Yes, I agree there is enough rope in Gradle. Build scripts are part of the code similarly as Chef/Puppet/Ansible recipes. And similarly to these you want to split declarative (what) and imperative (how) parts. It is encouraged by best practices in Gradle. This is one of the areas where different tools will give you different guidance. Partly this is why it is easy to make your own trap in Maven too(maven-ant-plugin to migrate old build stuff and add some maven-groovy-plugin to cover what does not fit to Maven convention).

-Radim


2014/1/11 Chip Collier < ***@laika.com >

<blockquote>
Hi folks,


Out of curiosity, is anyone using Gradle for their development?


Thanks!

Chip






</blockquote>