On 12/29/18 6:46 PM, Scott Palmer wrote:
+1 Great to see more support for Gradle.
How does this plugin compare to the existing Gradle plugin? Would it make
sense to merge your efforts?
That is a good question. The two plugins have very different coding
styles. IMHO Attila's plugin does the NetBeans <-> Gradle communication
in a nicer way (though the generic idea is the same), mine, if I may say
so, is more seamless fit into the IDE.
I would really like to see support for Gradle-based native C/C++ projects.
I can imagine that we could work out something when the C++ donation
gets released, Probably for NetBeans 12.0 (or whatever that version
number would be).
Scott
On Dec 29, 2018, at 6:02 PM, John McDonnell <mcdonnell.j...@gmail.com> wrote:
Very cool, it'll be nice to have Gradle and Maven in NetBeans moving
forward.
From what I see, new frameworks seem to be coming out supporting Gradle, so
being able to have Gradle as a first class citizen along with Maven that
would be really great.
Regards
John
On Sat, 29 Dec 2018 at 19:57, Laszlo Kishalmi <laszlo.kisha...@gmail.com>
wrote:
Dear all,
I would like to donate my Gradle works to Apache NetBeans.
Right now the code is here:
https://github.com/lkishalmi/incubator-netbeans/tree/gradle-support
I just recently rebased it on master, so there is no conflicts. If I'd
create a PR from it that would mean 317 new files and ~35k line of code.
The current state of the plugin:
* It Opens Gradle Projects resource efficiently
* It is based on the ideas found in our Maven Plugin
* It supports JavaSE and Groovy development
* Unit Testing
* Code Coverage
* JPA projects
* Spring (the little support we have for that)
* Navigator for project task
* Custom Task execution
* Output processing
* Debugging (even single methods)
* Creating new projects
The shady side:
* The Gradle <-> NetBeans project discovery and communication.
Based on simple property serialization. Ugly Groovy code, well the
deserialization Java code isn't that nice as well
* Limited number of unittest
* Being a sole developer there could be glitches here and there as of
lack of wider testing.
* Gradle is required to build the NetBeans <-> Gradle tooling
This adds a binary
groovy/gradle/netbeans-gradle-tooling/gradle/wrapper/gradle-wrapper.jar
to the source distribution package, though this file is not
distributed. So Apace might agree with that.
Introduced External Dependencies:
* Gradle Tooling API (Apache Licensed)
o slf4j (Apache Licensed)
* JaCoCo Core Library (EPL 1.0)
The whole JaCoCo project uses other libraries distributed under
different licenses, I need to make sure that the core is EPL 1.0 only
Areas to Improve:
* There is no support for Ergonomy
* Module versions might be incorrectly specified, I did the best I could
* Add Groovy project support (could be trivial)
* Improve Gradle <-> JDK incompatibility check.
* Profiling
* Compile on Save (that's an icy territory)
* Improve project Settings
* Whatever you think...
Future Works:
* I also have a JavaEE support module started, I can donate somewhat
later to the enterprise cluster.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
