Grails-Doc?

[jpearlin]

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

[pledbrook]

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

 

This is connected to the use of JLine for doing console output. I'm not sure whether the Maven plugin can activate the "--plain-output" option, but I would recommend doing so if it can. We should also look into fixing the underlying issue. If it's easily reproducible with the Maven plugin, all the better.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

[mlawler]

Hi Jonathon,

Yes, I encountered that problem :-) I am on OSX Terminal. I noticed that the output is a bit ugly since the line prefixes coming from maven are newlined and then do not match the following grails output. Needs cleaning up.

Interestingly, our thin grails wrapper doesnt have either of those problems.

It does however repeat lines where the console line is being "appended to" (i.e. with dots indicating progress. But the terminal is fine afterwards.

Michael

On 08/12/2011, at 1:55 AM, Jonathan Pearlin wrote:

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

[jpearlin]

Hi Michael,

    I will try working in the fix Peter suggested (the --plain-output) to see if that helps to clean up the output from Grails when executed via the Maven plugin (hopefully I will get to it by the end of this week/weekend).

Thanks,

--Jonathan

On Wed, Dec 7, 2011 at 2:07 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathon,

Yes, I encountered that problem :-) I am on OSX Terminal. I noticed that the output is a bit ugly since the line prefixes coming from maven are newlined and then do not match the following grails output. Needs cleaning up.

Interestingly, our thin grails wrapper doesnt have either of those problems.

It does however repeat lines where the console line is being "appended to" (i.e. with dots indicating progress. But the terminal is fine afterwards.

Michael

On 08/12/2011, at 1:55 AM, Jonathan Pearlin wrote:

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

[jpearlin]

All,

    I made the change suggested by Peter to pass the "--plain-output" switch to Grails from the Maven plugin and it definitely changes the output.  However, it does not solve the problem of the standard out disappearing after running via Maven (as Peter suggested it might not).  If we feel that we should be using the plain output, let me know and I will push the change up to my github repo for the grails-maven plugin.  The next step will be to do further investigation into why it is eating the standard out.  Any pointers at where to start in the Grails code (i.e. where JLine gets configured for use) would be greatly appreciated.

Thanks,

--Jonathan

On Thu, Dec 8, 2011 at 5:21 AM, Jonathan Pearlin <[hidden email]> wrote:

Hi Michael,

    I will try working in the fix Peter suggested (the --plain-output) to see if that helps to clean up the output from Grails when executed via the Maven plugin (hopefully I will get to it by the end of this week/weekend).

Thanks,

--Jonathan

On Wed, Dec 7, 2011 at 2:07 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathon,

Yes, I encountered that problem :-) I am on OSX Terminal. I noticed that the output is a bit ugly since the line prefixes coming from maven are newlined and then do not match the following grails output. Needs cleaning up.

Interestingly, our thin grails wrapper doesnt have either of those problems.

It does however repeat lines where the console line is being "appended to" (i.e. with dots indicating progress. But the terminal is fine afterwards.

Michael

On 08/12/2011, at 1:55 AM, Jonathan Pearlin wrote:

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

[Graeme Rocher-4]

The problem is almost certainly JLine's ConsoleReader and how it interacts with standard out in the context of Maven

Cheers

On Mon, Dec 12, 2011 at 4:37 PM, Jonathan Pearlin <[hidden email]> wrote:

All,

    I made the change suggested by Peter to pass the "--plain-output" switch to Grails from the Maven plugin and it definitely changes the output.  However, it does not solve the problem of the standard out disappearing after running via Maven (as Peter suggested it might not).  If we feel that we should be using the plain output, let me know and I will push the change up to my github repo for the grails-maven plugin.  The next step will be to do further investigation into why it is eating the standard out.  Any pointers at where to start in the Grails code (i.e. where JLine gets configured for use) would be greatly appreciated.

Thanks,

--Jonathan

On Thu, Dec 8, 2011 at 5:21 AM, Jonathan Pearlin <[hidden email]> wrote:

Hi Michael,

    I will try working in the fix Peter suggested (the --plain-output) to see if that helps to clean up the output from Grails when executed via the Maven plugin (hopefully I will get to it by the end of this week/weekend).

Thanks,

--Jonathan

On Wed, Dec 7, 2011 at 2:07 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathon,

Yes, I encountered that problem :-) I am on OSX Terminal. I noticed that the output is a bit ugly since the line prefixes coming from maven are newlined and then do not match the following grails output. Needs cleaning up.

Interestingly, our thin grails wrapper doesnt have either of those problems.

It does however repeat lines where the console line is being "appended to" (i.e. with dots indicating progress. But the terminal is fine afterwards.

Michael

On 08/12/2011, at 1:55 AM, Jonathan Pearlin wrote:

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

[Graeme Rocher-4]

Question, do you get any prompts during the build?

On Mon, Dec 12, 2011 at 4:37 PM, Jonathan Pearlin <[hidden email]> wrote:

All,

    I made the change suggested by Peter to pass the "--plain-output" switch to Grails from the Maven plugin and it definitely changes the output.  However, it does not solve the problem of the standard out disappearing after running via Maven (as Peter suggested it might not).  If we feel that we should be using the plain output, let me know and I will push the change up to my github repo for the grails-maven plugin.  The next step will be to do further investigation into why it is eating the standard out.  Any pointers at where to start in the Grails code (i.e. where JLine gets configured for use) would be greatly appreciated.

Thanks,

--Jonathan

On Thu, Dec 8, 2011 at 5:21 AM, Jonathan Pearlin <[hidden email]> wrote:

Hi Michael,

    I will try working in the fix Peter suggested (the --plain-output) to see if that helps to clean up the output from Grails when executed via the Maven plugin (hopefully I will get to it by the end of this week/weekend).

Thanks,

--Jonathan

On Wed, Dec 7, 2011 at 2:07 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathon,

Yes, I encountered that problem :-) I am on OSX Terminal. I noticed that the output is a bit ugly since the line prefixes coming from maven are newlined and then do not match the following grails output. Needs cleaning up.

Interestingly, our thin grails wrapper doesnt have either of those problems.

It does however repeat lines where the console line is being "appended to" (i.e. with dots indicating progress. But the terminal is fine afterwards.

Michael

On 08/12/2011, at 1:55 AM, Jonathan Pearlin wrote:

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

[jpearlin]

No, because we have the --non-interactive switch being sent to Grails from Maven.  I can try removing this to see if we get prompts at all.

--Jonathan

On Mon, Dec 12, 2011 at 8:13 AM, Graeme Rocher <[hidden email]> wrote:

Question, do you get any prompts during the build?

On Mon, Dec 12, 2011 at 4:37 PM, Jonathan Pearlin <[hidden email]> wrote:

All,

    I made the change suggested by Peter to pass the "--plain-output" switch to Grails from the Maven plugin and it definitely changes the output.  However, it does not solve the problem of the standard out disappearing after running via Maven (as Peter suggested it might not).  If we feel that we should be using the plain output, let me know and I will push the change up to my github repo for the grails-maven plugin.  The next step will be to do further investigation into why it is eating the standard out.  Any pointers at where to start in the Grails code (i.e. where JLine gets configured for use) would be greatly appreciated.

Thanks,

--Jonathan

On Thu, Dec 8, 2011 at 5:21 AM, Jonathan Pearlin <[hidden email]> wrote:

Hi Michael,

    I will try working in the fix Peter suggested (the --plain-output) to see if that helps to clean up the output from Grails when executed via the Maven plugin (hopefully I will get to it by the end of this week/weekend).

Thanks,

--Jonathan

On Wed, Dec 7, 2011 at 2:07 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathon,

Yes, I encountered that problem :-) I am on OSX Terminal. I noticed that the output is a bit ugly since the line prefixes coming from maven are newlined and then do not match the following grails output. Needs cleaning up.

Interestingly, our thin grails wrapper doesnt have either of those problems.

It does however repeat lines where the console line is being "appended to" (i.e. with dots indicating progress. But the terminal is fine afterwards.

Michael

On 08/12/2011, at 1:55 AM, Jonathan Pearlin wrote:

Hi Michael,

    Sounds great.  I am curious if you ran into an issue I have been seeing when building Grails 2.0 via Maven.  After the build completes, Grails appears to have stolen the standard input (I can type, but I cannot see what I am typing in that terminal window).  There appears to be no way to get it back, other than closing the terminal window and starting over.  I suspect this is being caused by the Grails Gant scripts and/or something it is doing underneath in Grails itself.

Thanks,

--Jonathan

On Mon, Dec 5, 2011 at 3:44 PM, Michael Lawler <[hidden email]> wrote:

HI Jonathan,

Cheers. Not sure why I didn't see that grails/grails-launcher project on github. Building it solved my problem. I can also confirm that the JNDI initialisation problem that used to occur in maven+grails1.x does not occur in the 2.0.X release anymore. Good work!

I will now look at comparing build-time speed and memory utilisation for multi-module maven projects that have lots of grails apps or plugins as children.

Michael

On 06/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

   Not sure what has changed.  I should be retrieving the Grails Launcher project from http://repo.grails.org/grails/core.  I was able to build the plugin successfully on my machine (mvn clean package), so I went ahead and deleted the grails-launcher project from my local .m2 and rebuilt it.  Both built successfully, with the second attempt re-downloading the grails-launcher artifact:

Downloaded: http://repo.grails.org/grails/core/org/grails/grails-launcher/1.0.0-SNAPSHOT/grails-launcher-1.0.0-20110603.025229-4.jar

Perhaps you have some stale copy of it in your .m2 repository?  The classes definitely exist in the copy currently under Grails in GitHub (which is where I believe the one that is getting pushed to the grails Maven repo is coming from):

https://github.com/grails/grails-launcher/tree/master/grails-launcher/src/main/java/org/grails/launcher

Do you happen to have some other repository that contains a version from Luke's repository listed in your Maven settings.xml file that is being found first (and therefore the artifact is coming from there instead of the Grails Maven repository)?  I would clear the artifact out of your .m2 and see where Maven thinks it is downloading it from.  It should be the same (with possibly a newer timestamp) as the "Downloaded" message I pasted above.

--Jonathan

On Mon, Dec 5, 2011 at 1:26 AM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

Yes, I was on the wrong branches.

Now I am trying to build your grails-maven-plugin/feature/2.0.0.RC1Fix and I have encountered a problem with the GrailsLauncher/GrailsExec stuff.

[ERROR] /Users/michael/workspaces/github/grails-maven/src/main/java/org/grails/maven/plugin/AbstractGrailsMojo.java:[49,26] package org.grails.launcher does not exist

Its trying to:

import org.grails.launcher.GrailsLauncher;

import org.grails.launcher.RootLoader;

I dug around and found Luke Daleys grails-launcher repo and your grails-exec repo but I dont see that either of them have that class. I only see org.grails.exec.GrailsExecutor in your repo. Any ideas?

Michael

On 03/12/2011, at 2:42 AM, Jonathan Pearlin wrote:

Hi Michael,

    I believe that grails-datastore-gorm is the replacement for grails-gorm (I'll have to look at the dependency tree to see why/where that is getting pulled in -- I thought I fixed that a while back, as that was one of the first issues I ran into -- perhaps you pulled the wrong branch of the archetype?  The branch with my changes is 'feature/grailsDependenciesPom').  I have not updated the dependencies since the guys started to cut the RC2 of 2.0.0, so my 2.0.X branch is definitely out of date and I know that they have switched the spring dependencies to RC2 as well (which I have not gotten a chance to update yet).  I also noticed the issue with grails-data-mapping (something is pulling in 1.0.0.BUILD-SNAPSHOT as well as 1.0.0.RC1) when building via Maven.  As for building the core, I've never done anything more than ./gradlew install to get it built and pushed to my local .m2, so I am not sure why you would have dependency issues attempting to build it.

   As for anything you fix in the dependency POM (or the other projects), please send me a pull request so I can incorporate them into my repo!

Thanks,

--Jonathan

On Thu, Dec 1, 2011 at 9:56 PM, Michael Lawler <[hidden email]> wrote:

Hi Jonathan,

I'm trying to put this together in order to play with it.

1) I downloaded built the 2.0x grails/grails-core (not yours - it seems old?).

2) I downloaded and reversioned your grails-dependencies, grails-maven and grails-maven-archetype to match the same version as grails-core

When I try to build a fresh new grails app from the archetype, it fails due to a missing dependency on grails-gorm.

I cant find grails-gorm anywhere? Is it still around or did it get refactored to grails-datastore-gorm?

Also I encountered a dependency problem between grails/grails-core/2.0x and SpringSource/grails-data-mapping.

grails-core/2.0x still has 1.0.0.BUILD-SNAPSHOT versions for various grails-data-mapping artefacts. I hacked them to the latest 1.0.0.RC3 artefacts being produced by SpringSource/grails-data-mapping

Any pointers appreciated - this is the first time I've built the grails-core, and I'm probably missing something

regards,

Michael

On 29/11/2011, at 2:45 AM, Jonathan Pearlin wrote:

Hi Michael,

    Everything is currently available in my Github account:

https://github.com/jdpgrailsdev/grails-dependencies
https://github.com/jdpgrailsdev/grails-maven
https://github.com/jdpgrailsdev/grails-maven-archetype
https://github.com/jdpgrailsdev/grails-core

You will need to use the 2.0.X branch of grails-core to get a fix that is required for Grails plugins to be resolved correctly from a POM file (Graeme has pushed this up to the main Grails repo as well).  I have added a new project called "grails-dependencies" that has a POM full of the required Grails runtime dependencies, that is now referenced by the POM created by the archetype.  I am also looking at creating an archetype for Grails plugins, as the POM for those projects is slightly different than the one used by a regular Grails application.

As for the JNDI issue, I have definitely seen it before in 1.3.x (it complaining when Grails goes to initialize it again a second time, as you point out).  However, I have not seen the issue so far in any of my 2.x testing (that's not to say that it doesn't exist, but I haven't been able to reproduce it yet).

--Jonathan

On Wed, Nov 23, 2011 at 4:56 PM, Michael Lawler <[hidden email]> wrote:

Johnathon,

Sounds great. Let me know when it is ready for a spin. (Is it stable now?) I'm happy to evaluate it against my build use case. I will build a trivial demo multi-module maven project with two plugins and an app and see how it goes.

Have you encountered/tackled the issue around JNDI initialisation for subsequent grails apps/plugins within a larger maven project? If I recall, the issue was that the way JNDI initialised, it wont tolerate being initialised a second time within the same JVM process.

regards,

Michael

On 24/11/2011, at 2:31 AM, Jonathan Pearlin wrote:

Michael,

    You are definitely correct about the "handing over" of the execution by Maven to Grails as the root of a lot of the issues.  As Graeme mentioned, I am currently working on cleaning a lot of this up so that at least the dependency management side can be extracted from BuildConfig.groovy for libraries AND Grails plugins (that has also been "Maven-ized" -- that is, those that have POM's and are installed to a Maven repo) for 2.0.  The goal of these changes is to be able to do exactly what you have described:  build multiple plugins and Grails applications via nothing more than modules using the Grails Maven plugin to compile, install plugins, and package Grails applications.  I have been able to do that so far in my testing of the changes (although I have not attempted a multi-module build, but nothing I have seen leads me to believe that it would not work as well).

--Jonathan

On Wed, Nov 23, 2011 at 2:43 AM, Graeme Rocher <[hidden email]> wrote:

We are working on improvements to the Maven plugin for 2.0 these are
in progress at

https://github.com/jdpgrailsdev/grails-maven/tree/feature/2.0.0.RC1Fix

But there is no release as of yet

Cheers

On Wed, Nov 23, 2011 at 5:01 AM, Michael Lawler
<[hidden email]> wrote:
> Hi,
>
> Is anyone using maven to build a hierarchical multi-module project that incorporates multiple grails plugins and grails applications?
>
> I'm currently doing this on grails-1.3.7 with my own custom maven plugin that is just a thin wrapper around the grails CLI. In our process, Maven doesn't do much for grails modules but hand over the execution of goals to the grails environment via cli. Dep mgmt is handled by grails according to BuildConfig.groovy.
>
> I am looking at porting our project to grails-2.0 now.
>
> I need to decide whether to continue with my wrapper based build approach (which I dont really have any serious problems with, apart from its not very DRY in some places), or to spend some time re-evaluating the use of the official maven-grails-plugin to build grails plugins and apps within a larger maven project.
>
> One of the issues we had last time (a year ago) was IIRC a test-phase initialisation conflict around the re-initialisation of JNDI within the same JVM process, as the maven build encountered the second plugin or application within the greater project. i.e. a single grails app or plugin within a larger maven multi-module project works fine, but the test phase was failing if you had more than 1 grails plugin or grails app being built. We started one some development that changed the official plugin to fork off grails commands off into their own processes like the surefire maven plugin does (that addresses the testing initialisation problem), but we lost steam on that approach and reverted to the current simple wrapper approach.
>
> One of the benefits of our current approach is that our grails plugins and apps (even though they are built in the context of a larger multi-module maven project) are just plain old grails projects, and we work with them using the standard grails CLI. Its only when we want to build the whole project from the top, or our CI server is building the project, that maven is in control. Because there is no maven really involved in the internals of the our projects, our projects are completely grails native and we dont suffer any compatibility problems by choosing to use maven to coordinate the larger build process.
>
> Any thoughts?
>
> Is there any current documentation on the state of Maven integration for grails 2.0?
>
> regards,
> Michael
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

<selera-email-logo.jpg>

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com

[mlawler]

Hi,

I have been trying to progress this myself, but I am stuck :-)

I have simple Grails 2.0 example (that doesnt work) that contains:
 (a) a vanilla 2.0.0 grails plugin with a single domain object 'demo.Book'. the plugin can be packaged by the release plugin ('grails maven-install') to build and install a jar (binary plugin) into your local .m2 repo
 (b) a maven project that tests standalone GORM via a single test case that loads an application context and tries to persist and find a Book via GORM. (test case currently fails)

For the test case applicationContext.xml I have tried to build an appropriate grails.xml file and provide the necessary beans for the context so that it simulates normal web app startup.

I have confirmed that the domain class is loaded in GrailsApplicationFactoryBean.afterPropertiesSet() (based on explicitly listing the domain class's name in the grails.xml resource section.

I get the following error:

  testStandaloneGorm(standalone.GormTest): Error creating bean with name 'transactionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Post-processing of the FactoryBean's object failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.codehaus.groovy.grails.orm.hibernate.ConfigurableLocalSessionFactoryBean]: Error configuring GORM dynamic behavior: No such property: domainClasses for class: org.codehaus.groovy.grails.commons.DefaultGrailsApplication; nested exception is groovy.lang.MissingPropertyException: No such property: domainClasses for class: org.codehaus.groovy.grails.commons.DefaultGrailsApplication

Can anyone explain which part of grails is responsible for setting up the 'domainClasses' property on the GrailsApplication object?

This is critical for my project. I am happy to build and work with a patched version of grails for a while until official support is implemented or documented.

regards,
Michael




On 07/12/2011, at 5:53 PM, Michael Lawler wrote:

> Hi (Burt?)
>
> Does anyone know of any success with Standalone GORM using grails 2.0? This is critical for me.
>
> Using the previous <gorm:sessionFactory> approach (that works fine in 1.3.7) we encounter an error that the GrailsDomainMappingClassContent is not available.
>
> If I try to wire one of those into the context, then it needs a GrailsApplication. I can dummy a default one of those, but it needs an ApplicationContext and I couldnt get that to work correctly.
>
> If I try to replicate what happens in the grails application context, using GrailsApplicationFactoryBean etc, the applicationContext initialisation fails with No such property: domainClasses for the DefaultGrailsApplication class.
>
> Any pointers on how I should move forward trying to get this working?
>
> regards,
> Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[mlawler]

Hi,

Burt Beckwith has solved this for me by providing some code for a new factory that subclasses the application factory bean:

package standalone;

  import org.codehaus.groovy.grails.commons.GrailsApplicationFactoryBean;

  public class InitializingGrailsApplicationFactoryBean extends GrailsApplicationFactoryBean {
     @Override
     public void afterPropertiesSet() throws Exception {
        super.afterPropertiesSet();
        super.getObject().initialise();
     }
  }

and then change the bean class in applicationContext.xml to:

  <bean id="grailsApplication" class="standalone.InitializingGrailsApplicationFactoryBean">

Thanks Burt.

Michael

On 19/12/2011, at 2:19 PM, Michael Lawler wrote:

Hi,

I have been trying to progress this myself, but I am stuck :-)

I have simple Grails 2.0 example (that doesnt work) that contains:
(a) a vanilla 2.0.0 grails plugin with a single domain object 'demo.Book'. the plugin can be packaged by the release plugin ('grails maven-install') to build and install a jar (binary plugin) into your local .m2 repo
(b) a maven project that tests standalone GORM via a single test case that loads an application context and tries to persist and find a Book via GORM. (test case currently fails)

For the test case applicationContext.xml I have tried to build an appropriate grails.xml file and provide the necessary beans for the context so that it simulates normal web app startup.

I have confirmed that the domain class is loaded in GrailsApplicationFactoryBean.afterPropertiesSet() (based on explicitly listing the domain class's name in the grails.xml resource section.

I get the following error:

 testStandaloneGorm(standalone.GormTest): Error creating bean with name 'transactionManager': Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory': Post-processing of the FactoryBean's object failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.codehaus.groovy.grails.orm.hibernate.ConfigurableLocalSessionFactoryBean]: Error configuring GORM dynamic behavior: No such property: domainClasses for class: org.codehaus.groovy.grails.commons.DefaultGrailsApplication; nested exception is groovy.lang.MissingPropertyException: No such property: domainClasses for class: org.codehaus.groovy.grails.commons.DefaultGrailsApplication

Can anyone explain which part of grails is responsible for setting up the 'domainClasses' property on the GrailsApplication object?

This is critical for my project. I am happy to build and work with a patched version of grails for a while until official support is implemented or documented.

regards,
Michael

<standalone200.zip>

On 07/12/2011, at 5:53 PM, Michael Lawler wrote:

Hi (Burt?)

Does anyone know of any success with Standalone GORM using grails 2.0? This is critical for me.

Using the previous <gorm:sessionFactory> approach (that works fine in 1.3.7) we encounter an error that the GrailsDomainMappingClassContent is not available.

If I try to wire one of those into the context, then it needs a GrailsApplication. I can dummy a default one of those, but it needs an ApplicationContext and I couldnt get that to work correctly.

If I try to replicate what happens in the grails application context, using GrailsApplicationFactoryBean etc, the applicationContext initialisation fails with No such property: domainClasses for the DefaultGrailsApplication class.

Any pointers on how I should move forward trying to get this working?

regards,

Michael

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

regards,

Michael Lawler

Enterprise Software Architect

work: 02 4223 0052

mob: [phone]

www.selera.com

[pledbrook]

> Using the previous <gorm:sessionFactory> approach (that works fine in 1.3.7) we encounter an error that the GrailsDomainMappingClassContent is not available.

This sounds like an unnecessary dependency for the GORM JARs (but not
necessarily for the Grails plugin). Does anyone know if it's possible
to remove this dependency?

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email