Maven integration - feedback wanted
|
View:
New views
16 Messages
—
Rating Filter:
Alert me
|
 |
Maven integration - feedback wanted
by Peter Ledbrook-2
::
Rate this Message:
Hi,
I have been looking into Grails/Maven integration in the last couple of days, and I would like some feedback from real Maven users on a proposal: * all Grails JAR files are deployed to Maven with corresponding POMs * Maven/Gant integration so that Gant targets can be called from Maven and its plugins * package Grails' Gant scripts into a JAR file that can be declared as a project dependency * "grails create-app --maven" generates a pom.xml with the Grails dependencies included and the GMaven and Grails Maven plugins configured * "mvn compile" uses GMaven and the standard Java compiler instead of delegating to "grails compile" * Grails plugins declare their dependencies in Maven form (either as a pom.xml or in a Gant script) * Grails Maven plugin hooks into standard build cycle and copies files into the correct location for the War plugin I looked into a Grails archetype, but I can't really see a way of creating the Grails directory structure directly. So what I'm thinking of doing is having a simple archetype that installs a POM and then the user can run "mvn grails:initialize" or something like that to create the actual application files. What do people think? Some of the feedback will go into issue http://jira.codehaus.org/browse/GRAILS-38 Cheers, Peter -- Software Engineer G2One, Inc. http://www.g2one.com/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by tomas lin
::
Rate this Message:
Hi Peter,
Sounds amazing, the plugin management within a pom file is definitively a great feature. It seems counter-intuitive to have to use an archetype and then have to call another command to run a grails project. Maven already has a complicated and convoluted learning curve, and it seems like most maven users are very protective of this. I think that getting started with grails for maven users should be as plain vanilla maven as possible, otherwise you get into this weird "grailsfied maven" project that is unlike other maven projects. Have you thought about putting the full grails stack under the <resources> tag of the archetype, this would mean the directory structure would be archetype/src/main/resources/grails-app and archetype/src/main/resources/web-app. This would allow me to run maven create without the extra structure problem. can we also have a grails update-pom or something like this that will generate a POM for existing projects that already have plugins defined rather than simply allowing pom creation at startup time? Will there be Gant scripts for each phase of the Maven lifecycle? ( http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference ) . Right now, the Octo plugin has goals that are not visible to the user, it simply wraps gant calls for the proper places in the life cycle. But this makes extending the cycle much more difficult, it would be nice to have editable targets that wrap the existing grails targets, so for package, for example, we would have a grails War target, but also add our won custom targets. On Wed, Jun 11, 2008 at 8:57 AM, Peter Ledbrook <peter@...> wrote: > Hi, > > I have been looking into Grails/Maven integration in the last couple > of days, and I would like some feedback from real Maven users on a > proposal: > > * all Grails JAR files are deployed to Maven with corresponding POMs > > * Maven/Gant integration so that Gant targets can be called from Maven > and its plugins > > * package Grails' Gant scripts into a JAR file that can be declared as > a project dependency > > * "grails create-app --maven" generates a pom.xml with the Grails > dependencies included and the GMaven and Grails Maven plugins > configured > > * "mvn compile" uses GMaven and the standard Java compiler instead of > delegating to "grails compile" > > * Grails plugins declare their dependencies in Maven form (either as a > pom.xml or in a Gant script) > > * Grails Maven plugin hooks into standard build cycle and copies files > into the correct location for the War plugin > > I looked into a Grails archetype, but I can't really see a way of > creating the Grails directory structure directly. So what I'm thinking > of doing is having a simple archetype that installs a POM and then the > user can run "mvn grails:initialize" or something like that to create > the actual application files. > > What do people think? Some of the feedback will go into issue > http://jira.codehaus.org/browse/GRAILS-38 > > Cheers, > > Peter > > -- > Software Engineer > G2One, Inc. > http://www.g2one.com/ > > --------------------------------------------------------------------- > 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 |
|
|
Re: Maven integration - feedback wanted
by Raphaël
::
Rate this Message:
Hi,
2008/6/11 Tomas Lin <tomaslin@...>: > Hi Peter, > > Sounds amazing, the plugin management within a pom file is > definitively a great feature. > > It seems counter-intuitive to have to use an archetype and then have > to call another command to run a grails project. Maven already has a > complicated and convoluted learning curve, and it seems like most > maven users are very protective of this. I think that getting started > with grails for maven users should be as plain vanilla maven as > possible, otherwise you get into this weird "grailsfied maven" project > that is unlike other maven projects. > > Have you thought about putting the full grails stack under the > <resources> tag of the archetype, this would mean the directory > structure would be archetype/src/main/resources/grails-app and > archetype/src/main/resources/web-app. This would allow me to run maven > create without the extra structure problem. Don't forget that by default everything in src/main/resources is copied to the classpath. Maybe src/main/resources/web-app should go to src/main/webapp (like the maven-war-plugin expect it) Regards, Raphaël > > can we also have a grails update-pom or something like this that will > generate a POM for existing projects that already have plugins defined > rather than simply allowing pom creation at startup time? > > Will there be Gant scripts for each phase of the Maven lifecycle? ( > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference > ) . Right now, the Octo plugin has goals that are not visible to the > user, it simply wraps gant calls for the proper places in the life > cycle. But this makes extending the cycle much more difficult, it > would be nice to have editable targets that wrap the existing grails > targets, so for package, for example, we would have a grails War > target, but also add our won custom targets. > > > > On Wed, Jun 11, 2008 at 8:57 AM, Peter Ledbrook <peter@...> wrote: >> Hi, >> >> I have been looking into Grails/Maven integration in the last couple >> of days, and I would like some feedback from real Maven users on a >> proposal: >> >> * all Grails JAR files are deployed to Maven with corresponding POMs >> >> * Maven/Gant integration so that Gant targets can be called from Maven >> and its plugins >> >> * package Grails' Gant scripts into a JAR file that can be declared as >> a project dependency >> >> * "grails create-app --maven" generates a pom.xml with the Grails >> dependencies included and the GMaven and Grails Maven plugins >> configured >> >> * "mvn compile" uses GMaven and the standard Java compiler instead of >> delegating to "grails compile" >> >> * Grails plugins declare their dependencies in Maven form (either as a >> pom.xml or in a Gant script) >> >> * Grails Maven plugin hooks into standard build cycle and copies files >> into the correct location for the War plugin >> >> I looked into a Grails archetype, but I can't really see a way of >> creating the Grails directory structure directly. So what I'm thinking >> of doing is having a simple archetype that installs a POM and then the >> user can run "mvn grails:initialize" or something like that to create >> the actual application files. >> >> What do people think? Some of the feedback will go into issue >> http://jira.codehaus.org/browse/GRAILS-38 >> >> Cheers, >> >> Peter >> >> -- >> Software Engineer >> G2One, Inc. >> http://www.g2one.com/ >> >> --------------------------------------------------------------------- >> 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 > > > |
|
|
Re: Maven integration - feedback wanted
by philippo
::
Rate this Message:
Hi,
good idea - we'd desperately need the ability to run mvn site (generate groovydoc?javadoc?) and would like to switch off test run (via -Dmaven.test.skip). Complying to the maven directory file structure is another plus. Thanks Phil |
|
|
Re: Maven integration - feedback wanted
by Peter Ledbrook-2
::
Rate this Message:
> It seems counter-intuitive to have to use an archetype and then have
> to call another command to run a grails project. Maven already has a > complicated and convoluted learning curve, and it seems like most > maven users are very protective of this. I think that getting started > with grails for maven users should be as plain vanilla maven as > possible, otherwise you get into this weird "grailsfied maven" project > that is unlike other maven projects. OK, I'll look into this. > Have you thought about putting the full grails stack under the > <resources> tag of the archetype, this would mean the directory > structure would be archetype/src/main/resources/grails-app and > archetype/src/main/resources/web-app. This would allow me to run maven > create without the extra structure problem. I'm not sure whether "grails-app" should go under "src/main/resources" since there are a lot of classes under "grails-app". I was thinking of something like "src/main/grails". > can we also have a grails update-pom or something like this that will > generate a POM for existing projects that already have plugins defined > rather than simply allowing pom creation at startup time? Yes. I think that is a definite requirement. > Will there be Gant scripts for each phase of the Maven lifecycle? ( > http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference > ) . Right now, the Octo plugin has goals that are not visible to the > user, it simply wraps gant calls for the proper places in the life > cycle. But this makes extending the cycle much more difficult, it > would be nice to have editable targets that wrap the existing grails > targets, so for package, for example, we would have a grails War > target, but also add our won custom targets. I don't really understand this part. The existing Gant scripts will pretty much stay as they are, I expect. For the package phase, I'm planning on using the existing WAR plugin if possible. One other thing to bear in mind is the plugins. I think to integrate Grails nicely, Maven users we will have to sacrifice the Grails build event mechanism, which may cause problems with some plugins. It basically depends on how much use is made of the existing Gant scripts from Maven builds. I haven't thought too hard about this because it's painful :) Cheers, Peter -- Software Engineer G2One, Inc. http://www.g2one.com/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by tomas lin
::
Rate this Message:
>
>> Will there be Gant scripts for each phase of the Maven lifecycle? ( >> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference >> ) . Right now, the Octo plugin has goals that are not visible to the >> user, it simply wraps gant calls for the proper places in the life >> cycle. But this makes extending the cycle much more difficult, it >> would be nice to have editable targets that wrap the existing grails >> targets, so for package, for example, we would have a grails War >> target, but also add our won custom targets. > > I don't really understand this part. The existing Gant scripts will > pretty much stay as they are, I expect. For the package phase, I'm > planning on using the existing WAR plugin if possible. > I am thinking about a simple Gant wrapper for maven lifecycle events. Have a Package.groovy that will allow us to do extra stuff for maven builds. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by Peter Ledbrook-2
::
Rate this Message:
> good idea - we'd desperately need the ability to run mvn site (generate
> groovydoc?javadoc?) > and would like to switch off test run (via -Dmaven.test.skip). Do you know whether this is an option handled by the Surefire plugin, or does Maven simply skip the "test" phase? > Complying to the maven directory file structure is another plus. The "grails-app" directory makes this difficult, which is why I'm suggesting "src/main/grails" in its place. Other suggestions are welcome (such as "src/main/resources/grails-app") particularly as my Maven experience is limited. Cheers, Peter -- Software Engineer G2One, Inc. http://www.g2one.com/ --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by Luke Daley
::
Rate this Message:
On 11/06/2008, at 10:57 PM, Peter Ledbrook wrote: > I have been looking into Grails/Maven integration in the last couple > of days, and I would like some feedback from real Maven users on a > proposal: Sorry for the late reply. > * all Grails JAR files are deployed to Maven with corresponding POMs I am not entirely sure the jars need to be deployed to a repo. You aren't going to eliminate the need to actually install grails on disk. > * Maven/Gant integration so that Gant targets can be called from Maven > and its plugins Absolutely. > * package Grails' Gant scripts into a JAR file that can be declared as > a project dependency Do you have a use case for this? > * "grails create-app --maven" generates a pom.xml with the Grails > dependencies included and the GMaven and Grails Maven plugins > configured Would be nice, but I think it's around the wrong way. I don't think Grails should have to know about Maven: Maven should know about Grails. > * "mvn compile" uses GMaven and the standard Java compiler instead of > delegating to "grails compile" What's the benefit here? ‘grails compile’ may introduce new magic in the future which we would potentially miss out on. I don't see any benefit of not using grails' own compile mechanism. > * Grails plugins declare their dependencies in Maven form (either as a > pom.xml or in a Gant script) You can do this now in a roundabout way, have a look at the ldap plugin. > * Grails Maven plugin hooks into standard build cycle and copies files > into the correct location for the War plugin Again, why? I would rather be 100% sure that when I build the WAR with Maven I get the exact same war I would have got with ‘grails war’ p.s. I am not trying to be negative here, I desperately want this functionality. I just want to make sure the right problems are being solved. LD. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by mykol
::
Rate this Message:
My 2cents..
I would really love to see Maven support be available in Grails eventually. Benefits that I see include: - transitive dependency - more transparent versioning for declared dependencies - a better integrator between source code and IDEs via maven plugins such as maven eclipse plugin and maven idea plugin, or IDE plugin such as that of netbeans - support for multi-module projects (imagine domains and services for example having a separate module with asynchronous versioning and producing separate jars) - an open standard That said, it won't be easy consolidating the different philosophies brought to the table. - both have it's own standard directory layout - both have it's own development lifecycle - utilities of Grails are built-in via Groovy scripts. Maven via maven plugins If Grails is to support Maven, I think there's gonna be a lot of compromise. So imho, it's either Grails fully adhere to the Maven philosophy, or pass up Maven support altogether and instead implement Maven's better features (like my previous suggestion). On Thu, Jun 19, 2008 at 7:43 AM, Luke Daley <ld@...> wrote:
|
|
|
Re: Maven integration - feedback wanted
by crowne
::
Rate this Message:
Hi Peter,
Sorry for the late reply. First of all, I am thrilled that the grails team is going to include the MTG plugin for 1.1 Secondly, I am positively blown-away that changes to the directory structure are being done to support co-existance with maven - thanks a whole bunch. For skipping tests, see this link http://www.nabble.com/Maven-integration---feedback-wanted-to17776961.html It basically states that -Dmaven.test.skip is honored by both surefire and the compiler plugin, and that -DskipTests or the equivalent pom configuration is a surefire only option. More importantly, and I hope that I'm not too late here, wrt the location of the "grails-app" stuff. I would suggest that you follow the groovy source file location used by GMaven. http://groovy.codehaus.org/GMaven+-+Building+Groovy+Projects I believe that this should be done whether or not gmaven is used to compile the groovy classes. Even if mtg is invoked to wrap the grails commands, those that want to use gmaven at a later stage would have an easier migration path. The general maven convention when it comes to location of source files is to separate main and test into two distinct directories under src and then group by type, java, groovy, ruby, resources etc. You typically would have the ability to override the location of the compiled output, so that you could once again build up a binary image of groovy-app under the target folder. The resulting structure would then look something like the below: src \main \groovy \java \resources \ruby \scala \web-app \test \groovy \java \resources \ruby \scala \web-app target \groovy-app . . . OK, so I wouldn't expect to see ruby and scala sources in a default grails-app, its mostly for demonstration purposes. I do anticipate a gotcha, when we want to disable compilation of the groovy classes for debugging and hot-code changes, this needs some thought - I don't have an answer off-hand, there may already be a gmaven option, I haven't looked. Good luck, and thanks some more! Cheers, Neil Crow.
|
|
|
Re: Maven integration - feedback wanted
by Brian T. H. Guan
::
Rate this Message:
Hi all,
I came late to this discussion this time round but I must claim credit to be the first one asking for tighter maven support (Feb 06): https://fisheye.codehaus.org/browse/GRAILS-38 Like many previous posts, I really appreciate the fact that the grails team is FINALLY considering support maven for real eventhough they have been resisting it for the longest time... but finally I guess succumbed to popular demand :-) Here's my $0.02 for a more mavenish directory layout for Grails... how about something like this: For most subdirs (and then some) under current grails project/grails-app... * src/main/grails-conf * src/main/grails-controllers * src/main/grails-command? * src/main/grails-domain * src/main/grails-filters? * src/main/grails-services * src/main/grails-taglib * src/main/grails-util (The reason for this seaming verbose layout is that immediately under these directories, there is nothing but packages and code) The rest: * src/main/resources * src/main/web-app * src/main/groovy * src/main/java * src/main/grails-scripts * src/main/grails-templates (for when you run grails install-templates) Then * src/test/grails-unit * src/test/grails-integration For plugins, they are really kind of weird. They combine source code, scripts (that hooks into the build via events), resources, and libraries. I think may be a scheme where upon calling install-plugin XYZ, the project's pom.xml get modified to include the needed lib as dependencies, then some entry is added to the improved maven-grails-plugin section in the pom to record that this grails-plugin is to be included, and essentially treat it like a code generator. Thus code+resources+scripts get downloaded to: * target/generated-sources/grails-XYZ-plugin/... and later the maven-grails-pluin will pick up stuff from there to proceed with the build. My wish is that a fully maven integrated grails project can be built without a prior installed grails environment on disk... if this really can't be avoided, it could be downloaded as embeded into maven-grails-plugin, or just downloaded and put under project/target/grails during build. Possible? May be we can even engage the Maven team for help/suggestion? - Brian On Sun, Jun 22, 2008 at 2:42 PM, crowne <crowneil@...> wrote: > > Hi Peter, > > Sorry for the late reply. > First of all, I am thrilled that the grails team is going to include the MTG > plugin for 1.1 > Secondly, I am positively blown-away that changes to the directory structure > are being done to support co-existance with maven - thanks a whole bunch. > > For skipping tests, see this link > http://www.nabble.com/Maven-integration---feedback-wanted-to17776961.html > It basically states that -Dmaven.test.skip is honored by both surefire and > the compiler plugin, > and that -DskipTests or the equivalent pom configuration is a surefire only > option. > > More importantly, and I hope that I'm not too late here, wrt the location of > the "grails-app" stuff. > I would suggest that you follow the groovy source file location used by > GMaven. > http://groovy.codehaus.org/GMaven+-+Building+Groovy+Projects > > I believe that this should be done whether or not gmaven is used to compile > the groovy classes. > Even if mtg is invoked to wrap the grails commands, those that want to use > gmaven at a later stage would have an easier migration path. > > The general maven convention when it comes to location of source files is to > separate main and test into two distinct directories under src and then > group by type, java, groovy, ruby, resources etc. > You typically would have the ability to override the location of the > compiled output, so that you could once again build up a binary image of > groovy-app under the target folder. > The resulting structure would then look something like the below: > src > \main > \groovy > \java > \resources > \ruby > \scala > \web-app > \test > \groovy > \java > \resources > \ruby > \scala > \web-app > target > \groovy-app > . > . > . > > OK, so I wouldn't expect to see ruby and scala sources in a default > grails-app, its mostly for demonstration purposes. > > I do anticipate a gotcha, when we want to disable compilation of the groovy > classes for debugging and hot-code changes, this needs some thought - I > don't have an answer off-hand, there may already be a gmaven option, I > haven't looked. > > Good luck, and thanks some more! > > Cheers, > Neil Crow. > > > Peter Ledbrook-2 wrote: >> >>> good idea - we'd desperately need the ability to run mvn site (generate >>> groovydoc?javadoc?) >>> and would like to switch off test run (via -Dmaven.test.skip). >> >> Do you know whether this is an option handled by the Surefire plugin, >> or does Maven simply skip the "test" phase? >> >>> Complying to the maven directory file structure is another plus. >> >> The "grails-app" directory makes this difficult, which is why I'm >> suggesting "src/main/grails" in its place. Other suggestions are >> welcome (such as "src/main/resources/grails-app") particularly as my >> Maven experience is limited. >> >> Cheers, >> >> Peter >> >> -- >> Software Engineer >> G2One, Inc. >> http://www.g2one.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> >> > > -- > View this message in context: http://www.nabble.com/Maven-integration---feedback-wanted-tp17776961p18059371.html > Sent from the grails - user mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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 |
|
|
Re: Maven integration - feedback wanted
by Graeme Rocher-2
::
Rate this Message:
Note Peter/Neil we are not considering changing the directory
structure of regular Grails applications, merely those who choose to use Maven Maven will very much be an optional thing in Grails as my hatred for it has not wavered, but those crazy enough to use it will get what they want Cheers On Tue, Jun 24, 2008 at 9:24 AM, Brian Guan <brian.guan@...> wrote: > Hi all, > > I came late to this discussion this time round but I must claim credit > to be the first one asking for tighter maven support (Feb 06): > > https://fisheye.codehaus.org/browse/GRAILS-38 > > Like many previous posts, I really appreciate the fact that the grails > team is FINALLY considering support maven for real eventhough they > have been resisting it for the longest time... but finally I guess > succumbed to popular demand :-) > > Here's my $0.02 for a more mavenish directory layout for Grails... how > about something like this: > > For most subdirs (and then some) under current grails project/grails-app... > > * src/main/grails-conf > * src/main/grails-controllers > * src/main/grails-command? > * src/main/grails-domain > * src/main/grails-filters? > * src/main/grails-services > * src/main/grails-taglib > * src/main/grails-util > > (The reason for this seaming verbose layout is that immediately under > these directories, there is nothing but packages and code) > > > The rest: > * src/main/resources > * src/main/web-app > * src/main/groovy > * src/main/java > * src/main/grails-scripts > * src/main/grails-templates (for when you run grails install-templates) > > Then > * src/test/grails-unit > * src/test/grails-integration > > > For plugins, they are really kind of weird. They combine source code, > scripts (that hooks into the build via events), resources, and > libraries. I think may be a scheme where upon calling install-plugin > XYZ, the project's pom.xml get modified to include the needed lib as > dependencies, then some entry is added to the improved > maven-grails-plugin section in the pom to record that this > grails-plugin is to be included, and essentially treat it like a code > generator. > > Thus code+resources+scripts get downloaded to: > > * target/generated-sources/grails-XYZ-plugin/... > > and later the maven-grails-pluin will pick up stuff from there to > proceed with the build. > > My wish is that a fully maven integrated grails project can be built > without a prior installed grails environment on disk... if this really > can't be avoided, it could be downloaded as embeded into > maven-grails-plugin, or just downloaded and put under > project/target/grails during build. > > Possible? May be we can even engage the Maven team for help/suggestion? > > - Brian > > > > On Sun, Jun 22, 2008 at 2:42 PM, crowne <crowneil@...> wrote: >> >> Hi Peter, >> >> Sorry for the late reply. >> First of all, I am thrilled that the grails team is going to include the MTG >> plugin for 1.1 >> Secondly, I am positively blown-away that changes to the directory structure >> are being done to support co-existance with maven - thanks a whole bunch. >> >> For skipping tests, see this link >> http://www.nabble.com/Maven-integration---feedback-wanted-to17776961.html >> It basically states that -Dmaven.test.skip is honored by both surefire and >> the compiler plugin, >> and that -DskipTests or the equivalent pom configuration is a surefire only >> option. >> >> More importantly, and I hope that I'm not too late here, wrt the location of >> the "grails-app" stuff. >> I would suggest that you follow the groovy source file location used by >> GMaven. >> http://groovy.codehaus.org/GMaven+-+Building+Groovy+Projects >> >> I believe that this should be done whether or not gmaven is used to compile >> the groovy classes. >> Even if mtg is invoked to wrap the grails commands, those that want to use >> gmaven at a later stage would have an easier migration path. >> >> The general maven convention when it comes to location of source files is to >> separate main and test into two distinct directories under src and then >> group by type, java, groovy, ruby, resources etc. >> You typically would have the ability to override the location of the >> compiled output, so that you could once again build up a binary image of >> groovy-app under the target folder. >> The resulting structure would then look something like the below: >> src >> \main >> \groovy >> \java >> \resources >> \ruby >> \scala >> \web-app >> \test >> \groovy >> \java >> \resources >> \ruby >> \scala >> \web-app >> target >> \groovy-app >> . >> . >> . >> >> OK, so I wouldn't expect to see ruby and scala sources in a default >> grails-app, its mostly for demonstration purposes. >> >> I do anticipate a gotcha, when we want to disable compilation of the groovy >> classes for debugging and hot-code changes, this needs some thought - I >> don't have an answer off-hand, there may already be a gmaven option, I >> haven't looked. >> >> Good luck, and thanks some more! >> >> Cheers, >> Neil Crow. >> >> >> Peter Ledbrook-2 wrote: >>> >>>> good idea - we'd desperately need the ability to run mvn site (generate >>>> groovydoc?javadoc?) >>>> and would like to switch off test run (via -Dmaven.test.skip). >>> >>> Do you know whether this is an option handled by the Surefire plugin, >>> or does Maven simply skip the "test" phase? >>> >>>> Complying to the maven directory file structure is another plus. >>> >>> The "grails-app" directory makes this difficult, which is why I'm >>> suggesting "src/main/grails" in its place. Other suggestions are >>> welcome (such as "src/main/resources/grails-app") particularly as my >>> Maven experience is limited. >>> >>> Cheers, >>> >>> Peter >>> >>> -- >>> Software Engineer >>> G2One, Inc. >>> http://www.g2one.com/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >>> >>> >>> >> >> -- >> View this message in context: http://www.nabble.com/Maven-integration---feedback-wanted-tp17776961p18059371.html >> Sent from the grails - user mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> 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 > > > -- Graeme Rocher Grails Project Lead G2One, Inc. Chief Technology Officer http://www.g2one.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by crowne
::
Rate this Message:
Hi Graeme,
Are you advocating 2 different project directory structures depending on what build tool is selected? I would much prefer to see a single directory structure, regardless of the build tool, whether it be gant, maven, ant+ivy, gradle, rake or raven. OK, so it might sound a bit crazy to have so much redundancy. Also the addition of more choices may impact ramp-up time and learning curve. However from the heated discussion that I've seen on this topic it seems like the build tool is a developer preference much like an IDE, or perhaps this is imposed by the environment that the developer is working in. Although I think that the flexibility introduced by making these choices possible will be good for the adoption of grails. I would like to see the default gant build as the master, which specifies how the binary artifacts should be generated. The gant build should be the standard against which all other build tools are measured for grails projects, this way the different build tools feel less like a fork to me, and more like an API implementation. I think that there is value in developers knowing where to look for projects files, especially if they are getting to grips with a new build tool. Gradle uses the "maven" structure by default, ant and therefore gant would be able to use this structure too, a "maven" type of directory structure does not mean that you have to use maven. I would like to see the best of all or both worlds, with the ability to swap worlds for a new perspective during the development cycle. Perhaps this isn't as intrusive as it sounds, MTG just wraps the existing grails tools, so the changes to gant should be fairly transparent, perhaps this will be different in later iterations. The grails tooling could be changed resolve using parameterised "base-locations", then the directory structures could be changed along with the "base-location" parameter values. Please give these comments some consideration, your response would be much appreciated. I think that if this could be pulled off, then we can all move on to solving that "world-peace" issue ;) Regards, Neil Crow.
|
|
|
Re: Maven integration - feedback wanted
by Luke Daley
::
Rate this Message:
I think crowne makes some really good points in the previous post.
Personally, I think Brian's approaching is too much like trying to turn Grails into Maven… That is just not going to work. Grails is not Maven, never will be. The goal here should be "How can we support integrating Grails development into Maven workflows/ projects". I don't think we _need_ to change the grails project structure at all. We need to make Maven work with Grails. And only really enough to drive the process. There is no real advantage to imposing the Maven structure on a grails project _unless_ through Maven limitations we can't get it to work with the Grails structure. That said, if compromises can be made that don't negatively impact Grails then sure why not. I guess my point is, let's not get carried away here. Let's identify real use cases and make sure we support them. -- LD. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by Graeme Rocher-2
::
Rate this Message:
Agreed 100% Luke
Cheers On Tue, Jun 24, 2008 at 12:05 PM, Luke Daley <ld@...> wrote: > I think crowne makes some really good points in the previous post. > Personally, I think Brian's approaching is too much like trying to turn > Grails into Maven… That is just not going to work. > > Grails is not Maven, never will be. The goal here should be "How can we > support integrating Grails development into Maven workflows/projects". > > I don't think we _need_ to change the grails project structure at all. We > need to make Maven work with Grails. And only really enough to drive the > process. There is no real advantage to imposing the Maven structure on a > grails project _unless_ through Maven limitations we can't get it to work > with the Grails structure. > > That said, if compromises can be made that don't negatively impact Grails > then sure why not. > > I guess my point is, let's not get carried away here. Let's identify real > use cases and make sure we support them. > > -- > > LD. > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Graeme Rocher Grails Project Lead G2One, Inc. Chief Technology Officer http://www.g2one.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: Maven integration - feedback wanted
by gregorypierce
::
Rate this Message:
Good, good - let the hate flow through you :)
----------------------------------- Gregory Pierce @ iPhone On Jun 24, 2008, at 4:33 AM, "Graeme Rocher" <graeme@...> wrote: > Note Peter/Neil we are not considering changing the directory > structure of regular Grails applications, merely those who choose to > use Maven > > Maven will very much be an optional thing in Grails as my hatred for > it has not wavered, but those crazy enough to use it will get what > they want > > Cheers > > On Tue, Jun 24, 2008 at 9:24 AM, Brian Guan <brian.guan@...> > wrote: >> Hi all, >> >> I came late to this discussion this time round but I must claim >> credit >> to be the first one asking for tighter maven support (Feb 06): >> >> https://fisheye.codehaus.org/browse/GRAILS-38 >> >> Like many previous posts, I really appreciate the fact that the >> grails >> team is FINALLY considering support maven for real eventhough they >> have been resisting it for the longest time... but finally I guess >> succumbed to popular demand :-) >> >> Here's my $0.02 for a more mavenish directory layout for Grails... >> how >> about something like this: >> >> For most subdirs (and then some) under current grails project/ >> grails-app... >> >> * src/main/grails-conf >> * src/main/grails-controllers >> * src/main/grails-command? >> * src/main/grails-domain >> * src/main/grails-filters? >> * src/main/grails-services >> * src/main/grails-taglib >> * src/main/grails-util >> >> (The reason for this seaming verbose layout is that immediately under >> these directories, there is nothing but packages and code) >> >> >> The rest: >> * src/main/resources >> * src/main/web-app >> * src/main/groovy >> * src/main/java >> * src/main/grails-scripts >> * src/main/grails-templates (for when you run grails install- >> templates) >> >> Then >> * src/test/grails-unit >> * src/test/grails-integration >> >> >> For plugins, they are really kind of weird. They combine source >> code, >> scripts (that hooks into the build via events), resources, and >> libraries. I think may be a scheme where upon calling install-plugin >> XYZ, the project's pom.xml get modified to include the needed lib as >> dependencies, then some entry is added to the improved >> maven-grails-plugin section in the pom to record that this >> grails-plugin is to be included, and essentially treat it like a code >> generator. >> >> Thus code+resources+scripts get downloaded to: >> >> * target/generated-sources/grails-XYZ-plugin/... >> >> and later the maven-grails-pluin will pick up stuff from there to >> proceed with the build. >> >> My wish is that a fully maven integrated grails project can be built >> without a prior installed grails environment on disk... if this >> really >> can't be avoided, it could be downloaded as embeded into >> maven-grails-plugin, or just downloaded and put under >> project/target/grails during build. >> >> Possible? May be we can even engage the Maven team for help/ >> suggestion? >> >> - Brian >> >> >> >> On Sun, Jun 22, 2008 at 2:42 PM, crowne <crowneil@...> wrote: >>> >>> Hi Peter, >>> >>> Sorry for the late reply. >>> First of all, I am thrilled that the grails team is going to >>> include the MTG >>> plugin for 1.1 >>> Secondly, I am positively blown-away that changes to the directory >>> structure >>> are being done to support co-existance with maven - thanks a whole >>> bunch. >>> >>> For skipping tests, see this link >>> http://www.nabble.com/Maven-integration---feedback-wanted-to17776961.html >>> It basically states that -Dmaven.test.skip is honored by both >>> surefire and >>> the compiler plugin, >>> and that -DskipTests or the equivalent pom configuration is a >>> surefire only >>> option. >>> >>> More importantly, and I hope that I'm not too late here, wrt the >>> location of >>> the "grails-app" stuff. >>> I would suggest that you follow the groovy source file location >>> used by >>> GMaven. >>> http://groovy.codehaus.org/GMaven+-+Building+Groovy+Projects >>> >>> I believe that this should be done whether or not gmaven is used >>> to compile >>> the groovy classes. >>> Even if mtg is invoked to wrap the grails commands, those that >>> want to use >>> gmaven at a later stage would have an easier migration path. >>> >>> The general maven convention when it comes to location of source >>> files is to >>> separate main and test into two distinct directories under src and >>> then >>> group by type, java, groovy, ruby, resources etc. >>> You typically would have the ability to override the location of the >>> compiled output, so that you could once again build up a binary >>> image of >>> groovy-app under the target folder. >>> The resulting structure would then look something like the below: >>> src >>> \main >>> \groovy >>> \java >>> \resources >>> \ruby >>> \scala >>> \web-app >>> \test >>> \groovy >>> \java >>> \resources >>> \ruby >>> \scala >>> \web-app >>> target >>> \groovy-app >>> . >>> . >>> . >>> >>> OK, so I wouldn't expect to see ruby and scala sources in a default >>> grails-app, its mostly for demonstration purposes. >>> >>> I do anticipate a gotcha, when we want to disable compilation of >>> the groovy >>> classes for debugging and hot-code changes, this needs some >>> thought - I >>> don't have an answer off-hand, there may already be a gmaven >>> option, I >>> haven't looked. >>> >>> Good luck, and thanks some more! >>> >>> Cheers, >>> Neil Crow. >>> >>> >>> Peter Ledbrook-2 wrote: >>>> >>>>> good idea - we'd desperately need the ability to run mvn site >>>>> (generate >>>>> groovydoc?javadoc?) >>>>> and would like to switch off test run (via -Dmaven.test.skip). >>>> >>>> Do you know whether this is an option handled by the Surefire >>>> plugin, >>>> or does Maven simply skip the "test" phase? >>>> >>>>> Complying to the maven directory file structure is another plus. >>>> >>>> The "grails-app" directory makes this difficult, which is why I'm >>>> suggesting "src/main/grails" in its place. Other suggestions are >>>> welcome (such as "src/main/resources/grails-app") particularly as >>>> my >>>> Maven experience is limited. >>>> >>>> Cheers, >>>> >>>> Peter >>>> >>>> -- >>>> Software Engineer >>>> G2One, Inc. >>>> http://www.g2one.com/ >>>> >>>> --- >>>> ------------------------------------------------------------------ >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>>> >>> >>> -- >>> View this message in context: http://www.nabble.com/Maven-integration---feedback-wanted-tp17776961p18059371.html >>> Sent from the grails - user mailing list archive at Nabble.com. >>> >>> >>> --- >>> ------------------------------------------------------------------ >>> 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 >> >> >> > > > > -- > Graeme Rocher > Grails Project Lead > G2One, Inc. Chief Technology Officer > http://www.g2one.com > > --------------------------------------------------------------------- > 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 |
| Free embeddable forum powered by Nabble | Forum Help |
