On 13/08/2013, at 4:49 AM, kelemen <attila.keleme...@gmail.com> wrote:
> 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. Absolutely. You're running code in the build process, and the build process may have certain constraints on which version of the JVM it requires. So this means you need to deal with the fact that the build may be using Java 5. That could be by compiling your actions and results for Java 5 or by refusing to import the build or by disabling certain things or whatever you like. However, there are things we can do to improve this: 1. Almost always the constraint is there because the project produces output for Java 5. We can make this more explicit in the build, so we will be able to tell the difference between 'I build things for Java 5 but it's fine to run Gradle on Java whatever' and 'I need to run my build on Java 5'. This would greatly reduce the number of builds that must run using Java 5 down to the point that you could probably just choose to not support them. 2. The tooling API falls back to run the action in the client in the case where it cannot be run in the build process. So, the API remains the same but it will just run more slowly for Java 5 builds. 3. If you steer clear of the Java 6 and 7 APIs, then we can transform the actions and results classes when we load them in the build process to downgrade them to Java 5 byte code. 4. We compile the actions and result classes on the fly in the build process. eg you give us the source or some groovy script. > > 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 <[hidden email]> > 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] <[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
