Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2347

Using Grails 2.0.0, external jar files are not included in build path

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.8.1.RELEASE
    • Fix Version/s: 2.9.0.M2
    • Component/s: GRAILS
    • Environment:

      Grails 2.0.0, Groovy 1.8.4, STS v2.8.1 Release
      Windows 7 64-bi

      Description

      After starting a new grails 2.0.0 project (not upgrading my old one) there seems to be no way for any external jars to be added to the project. I have added my jars on the build path (tried adding them as external jars, as native jars and as a part of a user defined library), placed them inside the lib folder and then tried refreshing dependencies. Despite all that, I keep getting compile time errors from missing imports, as it seems that the compiler does not know where to look for the imported packages.

      I face the above issue with Grails v2.0.0 + Groovy v1.8.4 + sts 2.8.1 release.

      Let me add that while using Grails v1.3.7 + Groovy v1.7.10 + sts 2.8.1, I faced no problems with imported jars whatsoever.

        Activity

        Hide
        Kris De Volder (c) added a comment -

        Hi Christopher, this sounds quite serious.

        Is it possible for you to provide a sample application, or some step-by-step instructions for me to create such a sample app, that demontrates the problem.

        I.e. I need to be able to see the state the project is in to be able to determine why the compiler isn't finding what it should be finding. Once I figure that out, I may be able to help by either fixing a potential bug, and/or giving you some instructions on how to work around the problem.

        Kris

        Show
        Kris De Volder (c) added a comment - Hi Christopher, this sounds quite serious. Is it possible for you to provide a sample application, or some step-by-step instructions for me to create such a sample app, that demontrates the problem. I.e. I need to be able to see the state the project is in to be able to determine why the compiler isn't finding what it should be finding. Once I figure that out, I may be able to help by either fixing a potential bug, and/or giving you some instructions on how to work around the problem. Kris
        Hide
        Kris De Volder (c) added a comment -

        PS: You said you had no problems with Grails 1.3.7, so perhaps you could describe in a bit more detail how you would have setup your project with an external jar with 1.3.7. I can then try out for myself to do the same with Grails 2.0.

        Show
        Kris De Volder (c) added a comment - PS: You said you had no problems with Grails 1.3.7, so perhaps you could describe in a bit more detail how you would have setup your project with an external jar with 1.3.7. I can then try out for myself to do the same with Grails 2.0.
        Hide
        Christopher Varakliotis added a comment - - edited

        Hello Kris and thanks for the quick response.

        I forgot to mention that the same behavior is encountered at runtime, when trying to connect to a database (in my case to a mysql server using the appropriate mysql connector).
        So a simple way to replicate the problem (at least in my case) would be to follow these steps:

        0a. Point sts to the grails 2.0.0 installation folder

        0b. Install groovy 1.8.4 (http://dist.springsource.com/release/TOOLS/third-party/groovy-grails/e3.7) and switch to the new version

        1. create a new grails project

        2. create a simple domain class (i added a user class with 2 string fields and no constraints)

        3. tell mysql server to create an empty schema (i created a schema named 'dummy')

        4. configure DataSource.groovy so that it points to the mysql server running on localhost and define the schema for the development environment. For example:

        – existing code –

        dataSource

        { pooled = true driverClassName = "com.mysql.jdbc.Driver" username = "root" password = "your_root_password" }

        – existing code –

        development {
        dataSource

        { dbCreate = "update" // one of 'create', 'create-drop', 'update', 'validate', '' url = "jdbc:mysql://localhost/dummy" }

        }

        – existing code –

        5. Put a mysql connector into the /lib folder (i used this one: http://www.mysql.com/downloads/connector/j/)

        6. Finally, run-app.

        After running this dummy project I get the following exception:

        org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class 'com.mysql.jdbc.Driver'

        which shows that (at runtime) grails cannot find the jar I placed into /lib. Same thing happens (on compile this time) when my code imports packages residing in a jar that I placed in /lib.

        On the other hand, switching back to grails 1.3.7/groovy 1.7.10 and following the exact same steps makes every problem disappear.

        Show
        Christopher Varakliotis added a comment - - edited Hello Kris and thanks for the quick response. I forgot to mention that the same behavior is encountered at runtime, when trying to connect to a database (in my case to a mysql server using the appropriate mysql connector). So a simple way to replicate the problem (at least in my case) would be to follow these steps: 0a. Point sts to the grails 2.0.0 installation folder 0b. Install groovy 1.8.4 ( http://dist.springsource.com/release/TOOLS/third-party/groovy-grails/e3.7 ) and switch to the new version 1. create a new grails project 2. create a simple domain class (i added a user class with 2 string fields and no constraints) 3. tell mysql server to create an empty schema (i created a schema named 'dummy') 4. configure DataSource.groovy so that it points to the mysql server running on localhost and define the schema for the development environment. For example: – existing code – dataSource { pooled = true driverClassName = "com.mysql.jdbc.Driver" username = "root" password = "your_root_password" } – existing code – development { dataSource { dbCreate = "update" // one of 'create', 'create-drop', 'update', 'validate', '' url = "jdbc:mysql://localhost/dummy" } } – existing code – 5. Put a mysql connector into the /lib folder (i used this one: http://www.mysql.com/downloads/connector/j/ ) 6. Finally, run-app. After running this dummy project I get the following exception: org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class 'com.mysql.jdbc.Driver' which shows that (at runtime) grails cannot find the jar I placed into /lib. Same thing happens (on compile this time) when my code imports packages residing in a jar that I placed in /lib. On the other hand, switching back to grails 1.3.7/groovy 1.7.10 and following the exact same steps makes every problem disappear.
        Hide
        Kris De Volder (c) added a comment -

        Thanks for the detailed instructions.

        Before you posted them, I also already tried a bit, placing a jar file in the lib folder and I indeed don't see the files placed in there being added to the classpath.

        A scenario where compile fails is easier to debug (compared to one where there's a runtime error with something like JDBC driver... which requires a lot more stuff to setup to recreate problem). So I'm trying to work with compile errors for now.

        It could be that Grails 2.0 doesn't work with the lib folder anymore. First thing I'll need to determine is if this is a problem with the STS tooling or Grails itself.

        BTW: this may help for you. You can try adding a flat dir repository in BuildConfig.groovy.

            ...
            repositories {
                inherits true // Whether to inherit repository definitions from plugins
                ...
                mavenCentral()
        	flatDir name:'myJars', dirs:"myJars"  //Adds a folder called 'myJars'as flat 'repository'
                ...
            }
        
            dependencies {
        	compile ":help:0.0.0"
                // runtime 'mysql:mysql-connector-java:5.1.16'
            }
        

        This will find a jar called "help-0.0.0.jar" from the 'myJars' folder to your classpath. (Actually will copy the file to your ivy cache and add that, but that shouldn't matter).

        This seems to work for me. (But I haven't tested it much yet, all I know is that the jar does indeed get added to classpath if you do it this way).

        My supsicion is that something is broken/changed in how either STS or Grails 2.0 itself is handling the libs folder. If you use the ivy dependency DSL, which is a more common thing to do, I think, it probably works more reliably.

        Perhaps that could be a workaround for you while I look into the lib folder issue further.

        Kris

        Show
        Kris De Volder (c) added a comment - Thanks for the detailed instructions. Before you posted them, I also already tried a bit, placing a jar file in the lib folder and I indeed don't see the files placed in there being added to the classpath. A scenario where compile fails is easier to debug (compared to one where there's a runtime error with something like JDBC driver... which requires a lot more stuff to setup to recreate problem). So I'm trying to work with compile errors for now. It could be that Grails 2.0 doesn't work with the lib folder anymore. First thing I'll need to determine is if this is a problem with the STS tooling or Grails itself. BTW: this may help for you. You can try adding a flat dir repository in BuildConfig.groovy. ... repositories { inherits true // Whether to inherit repository definitions from plugins ... mavenCentral() flatDir name:'myJars', dirs:"myJars" //Adds a folder called 'myJars'as flat 'repository' ... } dependencies { compile ":help:0.0.0" // runtime 'mysql:mysql-connector-java:5.1.16' } This will find a jar called "help-0.0.0.jar" from the 'myJars' folder to your classpath. (Actually will copy the file to your ivy cache and add that, but that shouldn't matter). This seems to work for me. (But I haven't tested it much yet, all I know is that the jar does indeed get added to classpath if you do it this way). My supsicion is that something is broken/changed in how either STS or Grails 2.0 itself is handling the libs folder. If you use the ivy dependency DSL, which is a more common thing to do, I think, it probably works more reliably. Perhaps that could be a workaround for you while I look into the lib folder issue further. Kris
        Hide
        Christopher Varakliotis added a comment -

        Thanks for the tip Kris.
        Fortunately I had already resolved the mysql issue by adding the connector as a runtime dependency. Unfortunately I rely on many external jars that can't be obtained via a repository (i.e. specific libraries for editing audio files).

        But since there is no harm in switching back to 1.3.7, I will continue my work and hope for the best!

        Show
        Christopher Varakliotis added a comment - Thanks for the tip Kris. Fortunately I had already resolved the mysql issue by adding the connector as a runtime dependency. Unfortunately I rely on many external jars that can't be obtained via a repository (i.e. specific libraries for editing audio files). But since there is no harm in switching back to 1.3.7, I will continue my work and hope for the best!
        Hide
        Kris De Volder (c) added a comment -

        Strange, now that I go back to Grails 2.0... no longer able to reproduce the problem. I.e. I drop my 'help.jar' (or help-0.0.0.jar) file into the lib folder and it shows up on the classpath after refresh dependencies.

        I am also able to use it from a 'run-app' and get no compile or runtime errors related to the classes in the file.

        BTW: Found that another person has had this (or at least similar) issue with 2.0.0.M1:
        http://grails.1312388.n4.nabble.com/2-0-0-M1-oracle-gt-ClassNotFoundException-td3745675.html

        Suggestion there was to run "grails clean".

        It could be some kind of corrupted state in some of Grails or .ivy caches. Could you try to delete your .gradle folder? (e.g. when I have funny Grails stuff happening, I usually do "rm -fr ~/.grails". A bit drastic, but this clears out any possibly broken cache files.

        Show
        Kris De Volder (c) added a comment - Strange, now that I go back to Grails 2.0... no longer able to reproduce the problem. I.e. I drop my 'help.jar' (or help-0.0.0.jar) file into the lib folder and it shows up on the classpath after refresh dependencies. I am also able to use it from a 'run-app' and get no compile or runtime errors related to the classes in the file. BTW: Found that another person has had this (or at least similar) issue with 2.0.0.M1: http://grails.1312388.n4.nabble.com/2-0-0-M1-oracle-gt-ClassNotFoundException-td3745675.html Suggestion there was to run "grails clean". It could be some kind of corrupted state in some of Grails or .ivy caches. Could you try to delete your .gradle folder? (e.g. when I have funny Grails stuff happening, I usually do "rm -fr ~/.grails". A bit drastic, but this clears out any possibly broken cache files.
        Hide
        Kris De Volder (c) added a comment -

        PS: Grails 2.0 keeps its ivy cache below .grails folder. But 1.3.7 keeps it ivy cache in ~/.ivy2.

        Show
        Kris De Volder (c) added a comment - PS: Grails 2.0 keeps its ivy cache below .grails folder. But 1.3.7 keeps it ivy cache in ~/.ivy2.
        Hide
        Kris De Volder (c) added a comment -

        BTW: I really appreciate you could try if clearing cached files resolved the issue for you. If this a problem that consistently happens it is really quite serious and should be fixed. I'd feel much better closing this issue knowing that it is just some cache corruption rather than a serious Grails 2.0 regression.

        Show
        Kris De Volder (c) added a comment - BTW: I really appreciate you could try if clearing cached files resolved the issue for you. If this a problem that consistently happens it is really quite serious and should be fixed. I'd feel much better closing this issue knowing that it is just some cache corruption rather than a serious Grails 2.0 regression.
        Hide
        Christopher Varakliotis added a comment -

        You were right, 'grails clean' did it.

        I didn't need to clean any of the other caches though(~/.grails & ~/.ivy2), nor hit refresh dependencies (I had already done that once).

        So I guess it's a matter of messy grails cache files, I will keep that in mind from now on. It's strange that it happens on every new project I create though (I would guess it would take a while for those caches to create such trouble)

        Thanks a lot for the help Kris, you can close the issue now

        Show
        Christopher Varakliotis added a comment - You were right, 'grails clean' did it. I didn't need to clean any of the other caches though(~/.grails & ~/.ivy2), nor hit refresh dependencies (I had already done that once). So I guess it's a matter of messy grails cache files, I will keep that in mind from now on. It's strange that it happens on every new project I create though (I would guess it would take a while for those caches to create such trouble) Thanks a lot for the help Kris, you can close the issue now
        Hide
        Kris De Volder (c) added a comment -

        BTW: I closed this as 'won't fix'. I don't think it right to close as 'Works as Designed'. Cache corruption is obviously not a good thing and shouldn't occur. But it would be very hard to figure out what caused the corruption... so 'won't fix'. Unless we see more problems like this...

        Show
        Kris De Volder (c) added a comment - BTW: I closed this as 'won't fix'. I don't think it right to close as 'Works as Designed'. Cache corruption is obviously not a good thing and shouldn't occur. But it would be very hard to figure out what caused the corruption... so 'won't fix'. Unless we see more problems like this...
        Hide
        Christopher Varakliotis added a comment -

        Well, it seems more like a grails issue that has nothing to do with the ide, so there's nothing to fix really... The only thing an ide could do would be to perform some cache cleaning silently every now and then. I did not have the patience to create a project from command line and see what happens though. And since I haven't seen many people complaining about it maybe it's not such big an issue (or maybe grails 2.0 has not undergone enough testing yet)

        Show
        Christopher Varakliotis added a comment - Well, it seems more like a grails issue that has nothing to do with the ide, so there's nothing to fix really... The only thing an ide could do would be to perform some cache cleaning silently every now and then. I did not have the patience to create a project from command line and see what happens though. And since I haven't seen many people complaining about it maybe it's not such big an issue (or maybe grails 2.0 has not undergone enough testing yet)
        Hide
        Kris De Volder (c) added a comment -

        > so there's nothing to fix really.

        Well, there is, if it is a Grails issue, which is what it looks like, we could consider raising a Jira ticket on Grails itself. But... I wouldn't pursue this further at this point. Though I'd reconsider if we see more problems like this.

        Show
        Kris De Volder (c) added a comment - > so there's nothing to fix really. Well, there is, if it is a Grails issue, which is what it looks like, we could consider raising a Jira ticket on Grails itself. But... I wouldn't pursue this further at this point. Though I'd reconsider if we see more problems like this.
        Hide
        Neil Grover added a comment -

        Just a heads up that I've experienced the need to "grails clean" twice under 2.1.0 in order to get my jars on the classpath. I've only added jars twice so in my case it's safe to say that "grails clean" is probably a requirement after adding jars to the project lib folder.

        Show
        Neil Grover added a comment - Just a heads up that I've experienced the need to "grails clean" twice under 2.1.0 in order to get my jars on the classpath. I've only added jars twice so in my case it's safe to say that "grails clean" is probably a requirement after adding jars to the project lib folder.
        Hide
        Christopher Varakliotis added a comment -

        Thanks for the heads up Neil.
        Running a 'clean' prior to building my projects has become a part of my routine now (even under 2.1.0) and everything works like a charm.

        Show
        Christopher Varakliotis added a comment - Thanks for the heads up Neil. Running a 'clean' prior to building my projects has become a part of my routine now (even under 2.1.0) and everything works like a charm.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Christopher Varakliotis
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: