Yes, that would be a task for the Tooling Script. I mentioned it a few
times here and there, that the tooling script is one of the
weakest/strongest (depends on the point of view). It's kind of ugly,
hard coded, not that easy to change. On the other hand it serializes the
data into simple core java types (mostly, Strings, Maps, Sets and Files)
which can be Garbage collected easier than Gradle remote proxies kind of
serialization. Simple way to put it. Uses less memory and does not leak.
So if you want to export something simple from Gradle, I would tweak the
tooling script. If you would shoot for something bigger, then there is a
way to implement some Gradle Model loading using the constructs in
org.netbeans.modules.gradle.loaders, though that thing is a bit premature.
BTW. What would be the thing to be extracted?
On 8/25/21 11:45 AM, Svata Dedic wrote:
Laszlo -
I've tried to find out how could a plugin inspect details of a Task
configured for a gradle project -- but so far I haven't found a way
how to dig out e.g. properties (primitive ones could be sufficient,
maybe) ?
Is there a way or model in current Gradle support that I've missed ?
The tooling groovy script could be capable of getting task
configuration(s) from the live buildscript, so I would prefer that
before some groovy parsing magic.
Thanks,
-S.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.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.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
