Quantcast

Grails-Doc?

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Grails-Doc?

bobbywarner
Looks like no commits have been migrated from pledbook/grails-doc to the real one (grails/grails-doc) since Nov 2nd.  How come?

Also, in the latest build (http://hudson.grails.org/job/grails_docs_2.0.x/lastSuccessfulBuild/artifact/build/docs/index.html) it says the version is 2.1.0.BUILD-SNAPSHOT when it should still be 2.0.0, right?  I was going to try and fix this, but then realized I didn't know where it had to be fixed, ha!  In build.gradle it looks for an existing system setting or makes it 1.4.0.BUILD-SNAPSHOT.  So, it must be pulling this 2.1.0.BUILD-SNAPSHOT from a system variable, right?  In which case, how do I fix this for the build?  Please let me know.


Thanks,
Bobby
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-Doc?

pledbrook
> Looks like no commits have been migrated from pledbook/grails-doc to the real
> one (grails/grails-doc) since Nov 2nd.  How come?

The 2.0.x branch got introduced, giving me a bit of a headache over
how to proceed. That and having other stuff on my plate :)

> Also, in the latest build
> (http://hudson.grails.org/job/grails_docs_2.0.x/lastSuccessfulBuild/artifact/build/docs/index.html)
> it says the version is 2.1.0.BUILD-SNAPSHOT when it should still be 2.0.0,
> right?  I was going to try and fix this, but then realized I didn't know
> where it had to be fixed, ha!  In
> https://github.com/grails/grails-doc/blob/master/build.gradle build.gradle
> it looks for an existing system setting or makes it 1.4.0.BUILD-SNAPSHOT.
> So, it must be pulling this 2.1.0.BUILD-SNAPSHOT from a system variable,
> right?  In which case, how do I fix this for the build?  Please let me know.

The 'master' on grails-core is now 2.1.0.BUILD-SNAPSHOT, and that's
what I assume is being built by grails-doc. Note that the user guide
version is pulled from the build.properties of whatever grailsHome is
pointed to.

I guess I need to sort this out, but I'm still unsure what to do about
pledbrook/grails-doc. Should 'master' on there simply be mapped to the
'2.0.x' branch of grails/grails-doc? Or should I introduce a 2.0.x
branch into pledbrook/grails-doc? But then making sure that
contributors commit onto that branch will be tricky.

Peter

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

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-Doc?

bobbywarner
No worries at all if you're busy.  I was just curious.

I would only have master on pledbrook/grails-doc (no branches) and only pull in commits to master on grails/grails-doc. In order to do this though, master on grails/grails-doc has to be for the next version to be released of Grails. In other words, grails/grails-doc master would be for 2.0 right now, not 2.1.  When 2.0 final is released, then you create a branch for it 2.0.x and master on grails/grails-doc is for 2.1.

The only issue would be if someone wants to write docs that don't belong in the next release. In other words, if someone wanted to write docs for 2.1 right now (or whatever is master on grails-core in the future) that shouldn't be included in 2.0.  Does this ever happen?


Thanks,
Bobby
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Grails & Maven Redux

mlawler
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

Graeme Rocher
Administrator
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

jpearlin
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails-Doc?

pledbrook
In reply to this post by bobbywarner
> I would only have master on pledbrook/grails-doc (no branches) and only pull
> in commits to master on grails/grails-doc. In order to do this though,
> master on grails/grails-doc has to be for the next version to be released of
> Grails. In other words, grails/grails-doc master would be for 2.0 right now,
> not 2.1.  When 2.0 final is released, then you create a branch for it 2.0.x
> and master on grails/grails-doc is for 2.1.

grails/grails-doc master is for 2.1 right now. That said, I think
you're right about a single branch on pledbrook/grails-doc. I can't
envisage any contributions there for a version that hasn't been
released yet (2.1), although when the first milestone is out that may
change. Hopefully by then I'll be able to send GitHub messages to all
collaborators on pledbrook/grails-doc :)

> The only issue would be if someone wants to write docs that don't belong in
> the next release. In other words, if someone wanted to write docs for 2.1
> right now (or whatever is master on grails-core in the future) that
> shouldn't be included in 2.0.  Does this ever happen?

Unheard of I think. We can revisit once first 2.1 milestone hits the streets.

Peter

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

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

mlawler
In reply to this post by jpearlin
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: 0411 539876
www.selera.com


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

Lee Butts
I'm using a patched version of the 1.3.7 plugin at the moment which does a better job of merging our projects dependencies with that of the plugin: https://github.com/mahileeb/grails-maven

My biggest pain point is library clashes between Grails and our parent pom which I am trying to re-use as the parent of the pom for my Grails app. Also 1.3.7's tight coupling to Log4J isn't playing nice with our use of log4j-over-slf4j (but that's not really maven related).

Appreciate any work done on making the maven integration better! Would also be great if it could be back ported to work with 1.3.7

cheers

Lee

On 24 November 2011 13:56, 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: <a href="tel:02%204223%200052" value="+33242230052" target="_blank">02 4223 0052
mob: <a href="tel:0411%20539876" value="+33411539876" target="_blank">0411 539876
www.selera.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

jpearlin
In reply to this post by mlawler
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: 0411 539876
www.selera.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

mlawler
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: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

jpearlin
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: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

Graeme Rocher
Administrator
grails-hibernate is the replace for grails-gorm. But yes Grails 2.0 also needs grails-datastore-gorm

Cheers

On Fri, Dec 2, 2011 at 4:42 PM, Jonathan Pearlin <[hidden email]> 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: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com






--
Graeme Rocher
Grails Project Lead
SpringSource - A Division of VMware
http://www.springsource.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

mlawler
In reply to this post by jpearlin
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: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

jpearlin
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: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Grails & Maven Redux

mlawler
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: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com

<selera-email-logo.jpg>



regards,

Michael Lawler
Enterprise Software Architect
work: 02 4223 0052
mob: 0411 539876
www.selera.com


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Maven -> Grails Memory Utilisation

mlawler
Hi All,

I've retested Jonathan's maven plugin and confirmed that an existing issue from the 1.x days is still around. :-(

If you have a multi-module maven project that includes lots of child grails apps/plugins, then the build will run out of memory fairly quickly because the invocations from maven to grails seem to reload all the classes separately for each invocation, and chew tons of PermGen.

To test, I built a maven project that contains 8 child grails apps. Each app is a vanilla "grails create-app my-app<n>"

When I build the root maven module and watch the class loading and memory consumption I see about 100MB of PermGen is required to build each grails app, and is NOT released after each module has completed building. Therefore, by the time the build gets to the 8th app or plugin, we are all out of heap/permgen even with generous allocations. i.e. I hit 1.2GB of heap and 800MB of PermGen and the build fails.

In contrast, the custom "thin wrapper" (around the grails command line) maven plugin we use does not even hit 25MB of PermGen for the entire identical 8 app project. It uses the command line to launch a new process for each grails task and so by definition after each task is done, the process is done and the memory is reclaimed.

I suspect the mechanics for this relate to the use of classloaders in grails launcher and grails itself.

Any thoughts?

Michael



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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven -> Grails Memory Utilisation

pledbrook
> I suspect the mechanics for this relate to the use of classloaders in grails launcher and grails itself.
>
> Any thoughts?

This sounds like a blocking issue. We should probably investigate
forking new JVMs the way that Ant supported. There will be an
additional cost in build time, but I don't see a way round that unless
we can clear the PermGen (which is pretty unlikely).

Peter

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

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Standalone GORM in 2.0?

mlawler
In reply to this post by mlawler
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Standalone GORM in 2.0?

burtbeckwith
If you can email me (off-list) a small app that works in 1.3.7 I'll see what it takes to get it working in 2.0.

Burt

> 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
>
>
>

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

    http://xircles.codehaus.org/manage_email


12
Loading...