On 13/08/2013, at 2:30 AM, kelemen <attila.keleme...@gmail.com> wrote:
> 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. You shouldn't have to make any changes, or at least not until we've done some more fixes to the tooling API. > > > 2013/8/12 alex.ruiz.05 [via Gradle] <[hidden email]> > 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]> 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]> > 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]> 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]> > > 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]> 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]> 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]> 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]> > > 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]> 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 > > > View this message in context: Re: Proposal for retrieving multiple types of > models from a project in a single pass, using the Tooling API > Sent from the gradle-dev mailing list archive 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 > > > View this message in context: Re: Proposal for retrieving multiple types of > models from a project in a single pass, using the Tooling API > Sent from the gradle-dev mailing list archive 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 > > > View this message in context: Re: Proposal for retrieving multiple types of > models from a project in a single pass, using the Tooling API > Sent from the gradle-dev mailing list archive 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. > 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 > Sent from the gradle-dev mailing list archive at Nabble.com. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
