grails-core sub project names

[Jeff Brown-3]

This is not a very big deal but a small hassle that is a constant hassle for me.

All of our sub projects have names that begin with "grails-*".  The test projects are:

grails-test-suite-base
grails-test-suite-persistence
grails-test-suite-uber
grails-test-suite-web

Something that I do frequently after running tests is open the test report.  For example, the uber test suite report is at grails-test-suite-uber/build/reports/tests/index.html so on the command line I type this:

open grails-test-suite-uber/build/reports/tests/index.html

In order to get that to autocomplete from bash I have to do something like this:

open g <tab> i <tab> t <tab> -s <tab> u <tab> bu <tab> /rep <tab> t <tab> i <tab> <enter>

That would get a little less fiddly if the names of the test projects were reconfigured to something like uber-grails-test-suite instead of grails-test-suite-uber.

A separate but related issue…

I am not sure why all of the sub project names should have "grails-" in them.  The sub projects are namespaced within the grails-core repo so that seems superfluous.  If we remove "grails-" we may have a little work to do to make sure the jar appendixes are correct but that should be a one time cost and it shouldn't be much of a big deal at all.  

What say ye of these 2 small nagging issues?



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email

[Nick Vaidyanathan]

+1

I'd say we're not very DRY, are we? Also,something about grails-core inside of grails-core makes my brain Inception itself.

I know it may seem freaky-deaky and all, but I'd like to see something like https://github.com/grails/grails-core lead to:

grails-core

• plugins
•  i18n, log4j, gsp, servlet, filters, resources...
• bootstrap
• nucleus...fundamental...holy-grail...holy-hand-grenade-of-Antioch (let's have the core core be something more than core, no?)
• crud
• docs
• tests
• uber
• persistence
• web

 Also, as part of tidying up...

• it seems like src/ main/ test/ is a running convention, but it seems to run a little deep...can't tests be first class citizens? (<project>/src <project>/test)
• I know historical namespace preservation is important, and mad props to codehaus and all, but  grails-core / grails-spring / src / main / groovy / org / codehaus / groovy / grails / commons / spring 

is a bit of a mouthful. Can codehaus get mad love in the readme but cut this down to org/grails? 

On Fri, Jul 20, 2012 at 11:11 AM, Jeff Brown <[hidden email]> wrote:

This is not a very big deal but a small hassle that is a constant hassle for me.

All of our sub projects have names that begin with "grails-*".  The test projects are:

grails-test-suite-base
grails-test-suite-persistence
grails-test-suite-uber
grails-test-suite-web

Something that I do frequently after running tests is open the test report.  For example, the uber test suite report is at grails-test-suite-uber/build/reports/tests/index.html so on the command line I type this:

open grails-test-suite-uber/build/reports/tests/index.html

In order to get that to autocomplete from bash I have to do something like this:

open g <tab> i <tab> t <tab> -s <tab> u <tab> bu <tab> /rep <tab> t <tab> i <tab> <enter>

That would get a little less fiddly if the names of the test projects were reconfigured to something like uber-grails-test-suite instead of grails-test-suite-uber.

A separate but related issue…

I am not sure why all of the sub project names should have "grails-" in them.  The sub projects are namespaced within the grails-core repo so that seems superfluous.  If we remove "grails-" we may have a little work to do to make sure the jar appendixes are correct but that should be a one time cost and it shouldn't be much of a big deal at all.

What say ye of these 2 small nagging issues?



jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email

--
Nick Vaidyanathan

PhD Student  - Computer Science - Software Engineering - Artificial Intelligence - Engineering Education

Arizona State University

Lead Visionary- Visionary Software Solutions LLC

@swVisionary 

[Jeff Brown-3]

On Jul 21, 2012, at 2:39 AM, Nick Vaidyanathan wrote:

>
> Also, as part of tidying up...
>
> • it seems like src/ main/ test/ is a running convention, but it seems to run a little deep...can't tests be first class citizens? (<project>/src <project>/test)


I don't think this is a great idea.  The structure described here is well understood by developers and is the default that our build tool expects.

I wouldn't throw a hissy and cry in the mall over it (throw toys out the pram, as my UK friends seem keen to say) if everyone else likes the idea but I would vote -1.




jb
--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/


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

    http://xircles.codehaus.org/manage_email

[rlovtangen]

On Jul 21, 2012, at 8:56 PM, Jeff Brown wrote:

>
> On Jul 21, 2012, at 2:39 AM, Nick Vaidyanathan wrote:
>
>>
>> Also, as part of tidying up...
>>
>> • it seems like src/ main/ test/ is a running convention, but it seems to run a little deep...can't tests be first class citizens? (<project>/src <project>/test)
>
>
> I don't think this is a great idea.  The structure described here is well understood by developers and is the default that our build tool expects.
>
> I wouldn't throw a hissy and cry in the mall over it (throw toys out the pram, as my UK friends seem keen to say) if everyone else likes the idea but I would vote -1.
>

Have to agree with Jeff, it's best to stick to the conventions used by Gradle and Maven. Especially if we want more user contributions. Makes it easy for new developers to get familiar with the source, as everything is located where you expect it to be.


I really wish this was true for Grails applications as well, where tests now are located under test/unit. What bugs me most is the lack of a groovy-folder (test/unit/groovy) as I would like to have other things like test/unit/javascript and test/unit/resources as well.
The switch to Gradle for Grails 3.0 would be a good opportunity to switch to using Gradle conventions.


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

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

Originally when we migrated to Gradle I set it up to not include the grails- prefix in all the sub projects. However, I ran into 

http://issues.gradle.org/browse/GRADLE-1135

Hence why we have what we have now. Not ideal, but until GRADLE-1135 is fixed we are stuck with it. Having said that we don't need POMs for the test suite projects so they could feasibly be renamed.

Cheers

-- 

Graeme Rocher

On Sunday, July 22, 2012 at 10:01 AM, Ronny Løvtangen wrote:

On Jul 21, 2012, at 8:56 PM, Jeff Brown wrote:

On Jul 21, 2012, at 2:39 AM, Nick Vaidyanathan wrote:

Also, as part of tidying up...

• it seems like src/ main/ test/ is a running convention, but it seems to run a little deep...can't tests be first class citizens? (<project>/src <project>/test)

I don't think this is a great idea. The structure described here is well understood by developers and is the default that our build tool expects.

I wouldn't throw a hissy and cry in the mall over it (throw toys out the pram, as my UK friends seem keen to say) if everyone else likes the idea but I would vote -1.

Have to agree with Jeff, it's best to stick to the conventions used by Gradle and Maven. Especially if we want more user contributions. Makes it easy for new developers to get familiar with the source, as everything is located where you expect it to be.

I really wish this was true for Grails applications as well, where tests now are located under test/unit. What bugs me most is the lack of a groovy-folder (test/unit/groovy) as I would like to have other things like test/unit/javascript and test/unit/resources as well.

The switch to Gradle for Grails 3.0 would be a good opportunity to switch to using Gradle conventions.

Ronny

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[GavinHogan2]

FYI That issue got marked as fixed today. Should be in 1.1-rc-1

On Mon, Jul 23, 2012 at 4:27 AM, Graeme Rocher <[hidden email]> wrote:

Originally when we migrated to Gradle I set it up to not include the grails- prefix in all the sub projects. However, I ran into 

http://issues.gradle.org/browse/GRADLE-1135

Hence why we have what we have now. Not ideal, but until GRADLE-1135 is fixed we are stuck with it. Having said that we don't need POMs for the test suite projects so they could feasibly be renamed.

Cheers

-- 

Graeme Rocher

On Sunday, July 22, 2012 at 10:01 AM, Ronny Løvtangen wrote:

On Jul 21, 2012, at 8:56 PM, Jeff Brown wrote:

On Jul 21, 2012, at 2:39 AM, Nick Vaidyanathan wrote:

Also, as part of tidying up...

• it seems like src/ main/ test/ is a running convention, but it seems to run a little deep...can't tests be first class citizens? (<project>/src <project>/test)

I don't think this is a great idea. The structure described here is well understood by developers and is the default that our build tool expects.

I wouldn't throw a hissy and cry in the mall over it (throw toys out the pram, as my UK friends seem keen to say) if everyone else likes the idea but I would vote -1.

Have to agree with Jeff, it's best to stick to the conventions used by Gradle and Maven. Especially if we want more user contributions. Makes it easy for new developers to get familiar with the source, as everything is located where you expect it to be.

I really wish this was true for Grails applications as well, where tests now are located under test/unit. What bugs me most is the lack of a groovy-folder (test/unit/groovy) as I would like to have other things like test/unit/javascript and test/unit/resources as well.

The switch to Gradle for Grails 3.0 would be a good opportunity to switch to using Gradle conventions.

Ronny

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

Good news

-- 

Graeme Rocher

On Tuesday, July 24, 2012 at 3:04 AM, Gavin Hogan wrote:

FYI That issue got marked as fixed today. Should be in 1.1-rc-1

On Mon, Jul 23, 2012 at 4:27 AM, Graeme Rocher <[hidden email]> wrote:

Originally when we migrated to Gradle I set it up to not include the grails- prefix in all the sub projects. However, I ran into 

http://issues.gradle.org/browse/GRADLE-1135

Hence why we have what we have now. Not ideal, but until GRADLE-1135 is fixed we are stuck with it. Having said that we don't need POMs for the test suite projects so they could feasibly be renamed.

Cheers

-- 

Graeme Rocher

On Sunday, July 22, 2012 at 10:01 AM, Ronny Løvtangen wrote:

On Jul 21, 2012, at 8:56 PM, Jeff Brown wrote:

On Jul 21, 2012, at 2:39 AM, Nick Vaidyanathan wrote:

Also, as part of tidying up...

• it seems like src/ main/ test/ is a running convention, but it seems to run a little deep...can't tests be first class citizens? (<project>/src <project>/test)

I don't think this is a great idea. The structure described here is well understood by developers and is the default that our build tool expects.

I wouldn't throw a hissy and cry in the mall over it (throw toys out the pram, as my UK friends seem keen to say) if everyone else likes the idea but I would vote -1.

Have to agree with Jeff, it's best to stick to the conventions used by Gradle and Maven. Especially if we want more user contributions. Makes it easy for new developers to get familiar with the source, as everything is located where you expect it to be.

I really wish this was true for Grails applications as well, where tests now are located under test/unit. What bugs me most is the lack of a groovy-folder (test/unit/groovy) as I would like to have other things like test/unit/javascript and test/unit/resources as well.

The switch to Gradle for Grails 3.0 would be a good opportunity to switch to using Gradle conventions.

Ronny

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[John Fletcher-3]

As a general comment, I feel the less repetition of "grails" in things
that evidently pertain to grails, the better. I also get annoyed by
that kind of thing.

John

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

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

I'm with you, when we upgrade to gradle 1.1 we will be able to fix this

-- 

Graeme Rocher

On Tuesday, July 24, 2012 at 4:26 PM, John Fletcher wrote:

As a general comment, I feel the less repetition of "grails" in things

that evidently pertain to grails, the better. I also get annoyed by

that kind of thing.

John

---------------------------------------------------------------------

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email