It just occurred to me that there is another problem with automatic class path detection:
1. My plugin currently uses Java6 and I plan to switch to Java7 this year (since NB switches as well). 2. If the class path is detected automatically then it will put jars not compatible with Java6 (or worse with Java7) on the classpath (if not mine, then NB jars of which I cannot do anything about). 3. This means, that the daemon must use Java6 or Java7 as well. 4. Since Gradle allows users to use Java5 (as far as I know), it would be rude of me to require the user to use Java7. So, I believe I'm forced to create another project which needs only Java5 and depend on that project and only put this one jar (and its dependencies) to the classpath (for the daemon be able to use my BuildAction implementation). By the way, this is something to consider for AndroidStudio as well (as far as I know it needs Java6 as well). 2013/8/12 Kelemen Attila <attila.keleme...@gmail.com> > I don't see how your opinion differs from mine. Actually, I agree with > what you wrote. I just stated that as I have seen in the sources of Gradle, > things will not work out with the current way. That is, I don't see how it > could. Changing how the class loading mechanism works in NetBeans is > practically impossible. NetBeans is a platform, not just an IDE and even if > it was not, possibly many code out there already relies on its class > loading mechanism. Breaking them is not an option, the risk of this change > seems extremely high to me. Other that this, I'm prepared to change the way > my plugin works, if it makes the Tooling API better but to make fundamental > changes in the NetBeans platform is unlikely to happen. > > > 2013/8/12 alex.ruiz.05 [via Gradle] < > ml-node+s1045684n5711680...@n5.nabble.com> > > I quite don't see things the same way. The new API provides something >> really powerful: perform custom logic in Gradle *without* writing plug-ins. >> The main use case is IDEs and the custom logic resides in the IDE (and can >> evolve with the IDE without end-users needing to update their build >> scripts, or plug-in versions, etc.) >> >> It would be ideal to drop in this new API and have everything work >> magically. But I don't think this is 100% possible. It is a tough problem. >> Both sides (client code and Gradle) need to know about each other somehow >> in order to operate (Adam, please correct if I'm wrong.) Either Gradle >> knows about the IDE or the IDE knows about Gradle. The IDE already knows >> about Gradle, after all it has a plug-in already using Gradle APIs. My take >> is that if this API requires changes in clients (IDEs) it is worth doing >> them for all the benefits the API provides (unless, of course, Adam has a >> way to go around this.) >> >> In the case of IDEA (and Studio), the IntelliJ folks are already working >> on a way to let us specify the classpath necessary for this new API to >> work: http://youtrack.jetbrains.com/issue/IDEA-111910 . >> >> >> >> >> On Mon, Aug 12, 2013 at 6:32 AM, kelemen <[hidden >> email]<http://user/SendEmail.jtp?type=node&node=5711680&i=0> >> > wrote: >> >>> I have debugged into the Tooling API and see what it does to determine >>> the required jar files. Actually, I believe that the problem is not the >>> fault of the IDE. Gradle makes two wrong assumptions: >>> >>> 1. URLClassLoader instances are used in the class loader hierarchy. >>> Actually, NetBeans has a different class loader which prevents accessing >>> classes not for the NB module. >>> 2. The ClassLoader of the class implementing BuildAction is enough. This >>> is not true because I have to wrap other plugins' actions as well (such as >>> NBAndroid) and they use an unrelated ClassLoader. >>> >>> This issue is by far not trivial to solve and I don't know if Gradle can >>> solve this on its own without the client code (e.g.: NB Gradle plugin) >>> telling it where additional jars are located. >>> >>> >>> 2013/8/12 alex.ruiz.05 [via Gradle] <[hidden >>> email]<http://user/SendEmail.jtp?type=node&node=5711677&i=0> >>> > >>> >>>> Even if this happens in Eclipse, we are not giving Adam enough >>>> information to troubleshoot the problem (assuming the problem is in Gradle, >>>> which I'm not sure.) >>>> >>>> I'm looking into how IDEA does things, to verify where the problem is >>>> and if it possible to do something in IDEA to solve the classpath issue. I >>>> will check with the IJ folks (once I understand how IDEA is doing the >>>> RMI-less import,) they definitely have a better understanding of >>>> classloading in IDEA, and they may find a solution (which may help solve >>>> the issue in other IDEs.) >>>> >>>> >>>> On Mon, Aug 12, 2013 at 12:42 AM, kelemen <[hidden >>>> email]<http://user/SendEmail.jtp?type=node&node=5711675&i=0> >>>> > wrote: >>>> >>>>> I would rather not simply consider this as an Idea bug because the >>>>> same error is thrown in NetBeans and it would be good to know what would >>>>> happen in Eclipse too. Also, I would like to test this when I wrap code >>>>> from another plugin of NetBeans (using another ClassLoader). >>>>> >>>>> >>>>> 2013/8/12 alex.ruiz.05 [via Gradle] <[hidden >>>>> email]<http://user/SendEmail.jtp?type=node&node=5711674&i=0> >>>>> > >>>>> >>>>> Hi Adam, >>>>>> >>>>>> I did some testing and, in fact, the problem is in IntelliJ. Long >>>>>> story short: they recently (as in last Friday) removed usage of RMI to >>>>>> import a Gradle project into IDEA (or Studio.) The classpath is not >>>>>> correctly set with RMI off. With RMI on the classpath is properly set, >>>>>> and >>>>>> the new API works. I haven't tested our whole use case, but at least with >>>>>> RMI on, we don't get the 'class not found' exception. >>>>>> >>>>>> I'll follow up with the IntelliJ folks. >>>>>> >>>>>> Thanks! >>>>>> -Alex >>>>>> >>>>>> >>>>>> On Mon, Aug 12, 2013 at 12:20 AM, Alex Ruiz <[hidden >>>>>> email]<http://user/SendEmail.jtp?type=node&node=5711673&i=0> >>>>>> > wrote: >>>>>> >>>>>>> Hi Adam, >>>>>>> >>>>>>> Thanks to the diagnostics you added, it seems that the problem is in >>>>>>> IntelliJ. I'm attaching the output of both Studio (IDEA) and a simple >>>>>>> Java >>>>>>> app. The classpath from Studio is empty, while the one from the simple >>>>>>> Java >>>>>>> app is correct. I'm going to test a little bit more on Studio, and if >>>>>>> this >>>>>>> is an issue with IDEA, I'll let the IDEA folks know about this issue. >>>>>>> >>>>>>> Thanks, >>>>>>> -Alex >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Aug 11, 2013 at 9:54 PM, Alex Ruiz <[hidden >>>>>>> email]<http://user/SendEmail.jtp?type=node&node=5711673&i=1> >>>>>>> > wrote: >>>>>>> >>>>>>>> Thanks, Adam. In addition to Attila's example, I'll extract my code >>>>>>>> into a unit test to make it easier to run. >>>>>>>> >>>>>>>> >>>>>>>> On Sun, Aug 11, 2013 at 4:37 PM, kelemen <[hidden >>>>>>>> email]<http://user/SendEmail.jtp?type=node&node=5711673&i=2> >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> You can debug my plugin easily: >>>>>>>>> >>>>>>>>> 1. Download the current sources: >>>>>>>>> https://github.com/kelemen/netbeans-gradle-project/tree/gradle_1.8_tooling_api >>>>>>>>> 2. Install NetBeans (I'm using 7.3.1 but should work with 7.2 as >>>>>>>>> well). >>>>>>>>> 3. Build the project. >>>>>>>>> 4. Debug (This will start a new instance of NB). >>>>>>>>> 5. Open any project. >>>>>>>>> >>>>>>>>> Note 1: It is important to always build the project before run >>>>>>>>> because it seems that NB don't automatically build NB Maven based >>>>>>>>> modules >>>>>>>>> (unlike simple Maven projects). >>>>>>>>> >>>>>>>>> Note 2: If you want to step into the sources of the Tooling API, >>>>>>>>> you have to right click on the "Dependencies" node and "Download >>>>>>>>> Sources". >>>>>>>>> >>>>>>>>> Also, you need to configure, the Gradle version used to load the >>>>>>>>> project. You can do this in Tools/Options/Miscellaneous/Gradle for >>>>>>>>> every >>>>>>>>> project but by default the version defined for the wrapper is used, >>>>>>>>> so you >>>>>>>>> can rely on that. Anyway, every method the Tooling API allows is >>>>>>>>> possible >>>>>>>>> to use as a Gradle location. See the wiki: >>>>>>>>> https://github.com/kelemen/netbeans-gradle-project/wiki/Project-Properties >>>>>>>>> ("Gradle >>>>>>>>> home") >>>>>>>>> >>>>>>>>> These are the new lines printed by the most recent Tooling API: >>>>>>>>> >>>>>>>>> Tooling API ClassLoader: ModuleCL@91ed751[org.netbeans.gradle.project] >>>>>>>>> (class org.netbeans.StandardModule$OneModuleClassLoader) >>>>>>>>> * Classpath: >>>>>>>>> [file:/C:/Program%20Files/NetBeans%207.3/platform/lib/boot.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-modules.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util-lookup.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/org-openide-util.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ja.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_pt_BR.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_ru.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/boot_zh_CN.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ja.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_pt_BR.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_ru.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-modules_zh_CN.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ja.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_pt_BR.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_ru.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util-lookup_zh_CN.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ja.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_pt_BR.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_ru.jar, >>>>>>>>> file:/C:/Program%20Files/NetBeans%207.3/platform/lib/locale/org-openide-util_zh_CN.jar, >>>>>>>>> file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/dt.jar, >>>>>>>>> file:/C:/Program%20Files/Java/jdk1.7.0_13/lib/tools.jar] >>>>>>>>> * Codesource: >>>>>>>>> jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/ >>>>>>>>> * Resource: >>>>>>>>> jar:file:/C:/git.repo/netbeans-gradle-project/target/netbeans_clusters/extra/modules/ext/org.netbeans.gradle.project/org-gradle/gradle-tooling-api.jar!/org/gradle/tooling/internal/consumer/connection/ActionAwareConsumerConnection$DefaultBuildActionSerializationDetails.class >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2013/8/12 Adam Murdoch [via Gradle] <[hidden >>>>>>>>> email]<http://user/SendEmail.jtp?type=node&node=5711670&i=0> >>>>>>>>> > >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've added some diagnostics to the latest nightly build. Can you >>>>>>>>>> give this a try and send me the output. It's logged to System.out. >>>>>>>>>> >>>>>>>>>> Also is there some way I can run your code to debug what's going >>>>>>>>>> on? >>>>>>>>>> >>>>>>>>>> On 11/08/2013, at 4:35 AM, kelemen <[hidden >>>>>>>>>> email]<http://user/SendEmail.jtp?type=node&node=5711668&i=0>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> The new API throws an exception for me. Here is the stacktrace: >>>>>>>>>> https://gist.github.com/kelemen/6201595 >>>>>>>>>> >>>>>>>>>> And here is the code using the new API: >>>>>>>>>> >>>>>>>>>> https://github.com/kelemen/netbeans-gradle-project/blob/d3a82f4f761fc6bf8ebcf75b00ae8da81f89ce58/src/main/java/org/netbeans/gradle/project/model/NbGradle18ModelLoader.java >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> View this message in context: >>>>>>>>>> http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711666.html >>>>>>>>>> Sent from the gradle-dev mailing list archive at Nabble.com. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe from this list, please visit: >>>>>>>>>> >>>>>>>>>> http://xircles.codehaus.org/manage_email >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Adam Murdoch >>>>>>>>>> Gradle Co-founder >>>>>>>>>> http://www.gradle.org >>>>>>>>>> VP of Engineering, Gradleware Inc. - Gradle Training, >>>>>>>>>> Support, Consulting >>>>>>>>>> http://www.gradleware.com >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------ >>>>>>>>>> If you reply to this email, your message will be added to the >>>>>>>>>> discussion below: >>>>>>>>>> >>>>>>>>>> http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711668.html >>>>>>>>>> To unsubscribe from Proposal for retrieving multiple types of >>>>>>>>>> models from a project in a single pass, using the Tooling API, click >>>>>>>>>> here. >>>>>>>>>> NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> View this message in context: Re: Proposal for retrieving >>>>>>>>> multiple types of models from a project in a single pass, using the >>>>>>>>> Tooling >>>>>>>>> API<http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711670.html> >>>>>>>>> Sent from the gradle-dev mailing list >>>>>>>>> archive<http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html>at >>>>>>>>> Nabble.com. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> If you reply to this email, your message will be added to the >>>>>> discussion below: >>>>>> >>>>>> http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711673.html >>>>>> To unsubscribe from Proposal for retrieving multiple types of models >>>>>> from a project in a single pass, using the Tooling API, click here. >>>>>> NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> View this message in context: Re: Proposal for retrieving multiple >>>>> types of models from a project in a single pass, using the Tooling >>>>> API<http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711674.html> >>>>> Sent from the gradle-dev mailing list >>>>> archive<http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html>at >>>>> Nabble.com. >>>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> If you reply to this email, your message will be added to the >>>> discussion below: >>>> >>>> http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711675.html >>>> To unsubscribe from Proposal for retrieving multiple types of models >>>> from a project in a single pass, using the Tooling API, click here. >>>> NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >>>> >>> >>> >>> ------------------------------ >>> View this message in context: Re: Proposal for retrieving multiple >>> types of models from a project in a single pass, using the Tooling >>> API<http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711677.html> >>> Sent from the gradle-dev mailing list >>> archive<http://gradle.1045684.n5.nabble.com/gradle-dev-f1436218.html>at >>> Nabble.com. >>> >> >> >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711680.html >> To unsubscribe from Proposal for retrieving multiple types of models >> from a project in a single pass, using the Tooling API, click >> here<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5711516&code=YXR0aWxhLmtlbGVtZW44NUBnbWFpbC5jb218NTcxMTUxNnwtMTMxMjM2NTcwMA==> >> . >> NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> >> > > -- View this message in context: http://gradle.1045684.n5.nabble.com/Proposal-for-retrieving-multiple-types-of-models-from-a-project-in-a-single-pass-using-the-Tooling-AI-tp5711516p5711682.html Sent from the gradle-dev mailing list archive at Nabble.com.
