Grails Plugins & Maven Repos

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Grails Plugins & Maven Repos

Graeme Rocher-3
Hi all,

I've pushed to the master branch on Git some changes which make Grails uses Ivy to resolve plugins. You can declaratively specify plugins in BuildConfig.groovy:

plugins {
     runtime ":feeds:1.5"
}

Installing plugins via install-plugin is still supported and plugins found in the metadata just become runtime scoped plugins.

 have yet to implement the semantics of the different scopes (runtime, test, provided etc.) for plugins. This will come shortly, the main thing is that resolution is done by ivy. One upshot of using ivy is that plugins published to a maven repository using the maven publisher plugin (http://grails.org/plugin/maven-publisher) can now be resolved by Grails so folks with maven repositories don't need to setup a different repository to host Grails plugins.

One downside of the new system is that I had to completely drop support for resolving plugins against secured SVN repositories because ivy doesn't support this out of the box. Although it could be added with IvySvn (http://code.google.com/p/ivysvn/). Thoughts welcome there.

I've pushed some updated documentation describing the new implementation: http://github.com/grails/grails-doc/commit/f4902649ec763ddc19a3b0b07c1ad35f29bb83e1

Thoughts appreciated.

Cheers
Graeme


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Plugins & Maven Repos

pledbrook
> I've pushed to the master branch on Git some changes which make Grails uses Ivy to resolve plugins. You can declaratively specify plugins in BuildConfig.groovy:
>
> plugins {
>     runtime ":feeds:1.5"
> }
>
> Installing plugins via install-plugin is still supported and plugins found in the metadata just become runtime scoped plugins.

Yay! Next step, binary plugins :)

I've had a quick look and have a few questions/suggestions:

1. What does the 'exported' property do? I don't really understand its
behaviour from the user guide.

2. How does the plugin() method work and where do you use it? I assume
inside the "dependencies" closure, but I'm not 100% sure. Does using
the method automatically override the plugin's existing dependencies?
If so, how does the exclude work?

3. The examples could do with tabs being replaced with spaces.

4. The guide says you can set the group ID in Config.groovy - do you
mean BuildConfig.groovy?

5. That same section is title "Projects" but should probably be
"Applications" to distinguish it from "Plugins".

6. Why "latest.integration", instead of just "latest"? This is partly
to do with me being a lazy typist, but I'm wondering what the
"integration" signifies.

I'm afraid I probably won't be testing it out for some time, so I
can't offer more substantive feedback yet.

Cheers,

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Plugins & Maven Repos

Graeme Rocher-3

On 25 Feb 2010, at 09:18, Peter Ledbrook wrote:

>> I've pushed to the master branch on Git some changes which make Grails uses Ivy to resolve plugins. You can declaratively specify plugins in BuildConfig.groovy:
>>
>> plugins {
>>     runtime ":feeds:1.5"
>> }
>>
>> Installing plugins via install-plugin is still supported and plugins found in the metadata just become runtime scoped plugins.
>
> Yay! Next step, binary plugins :)
>
> I've had a quick look and have a few questions/suggestions:
>
> 1. What does the 'exported' property do? I don't really understand its
> behaviour from the user guide.

Exported is when you have a plugin that depends on jar A, but jar A shouldn't be "exported" to the application when its installed. In otherwords jar A is a dependency of the plugin only during development and not when the plugin is installed.
>
> 2. How does the plugin() method work and where do you use it? I assume
> inside the "dependencies" closure, but I'm not 100% sure. Does using
> the method automatically override the plugin's existing dependencies?
> If so, how does the exclude work?

Well the way the DSL is written it could be used inside or inside the dependencies block, but that is just semantics. This feature actually already exists in Grails 1.2 though, basically how it works is that you can either override or exclude any plugins dependencies. Eg.

plugin("hibernate") {
     excludes "hibernate-ehcache"
}
>
> 3. The examples could do with tabs being replaced with spaces.

Ok.

>
> 4. The guide says you can set the group ID in Config.groovy - do you
> mean BuildConfig.groovy?

Umm, I'll double check, but you're right it should go in BuildConfig.groovy and we should probably add settings in there too change the project name and version.

>
> 5. That same section is title "Projects" but should probably be
> "Applications" to distinguish it from "Plugins".

Good point.
>
> 6. Why "latest.integration", instead of just "latest"? This is partly
> to do with me being a lazy typist, but I'm wondering what the
> "integration" signifies.

This is just Ivy's terminology. When using Ivy you use "latest.integration", don't ask me why. However we could automatically change "latest" to "latest.integration" before passing to ivy

Cheers
Graeme

>
> I'm afraid I probably won't be testing it out for some time, so I
> can't offer more substantive feedback yet.
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Grails Plugins & Maven Repos

John Hurst-2
> 6. Why "latest.integration", instead of just "latest"? This is partly
> to do with me being a lazy typist, but I'm wondering what the
> "integration" signifies.

This is just Ivy's terminology. When using Ivy you use "latest.integration", don't ask me why. However we could automatically change "latest" to "latest.integration" before passing to ivy


Ivy supports a "status" for a publication. Standard statuses include "integration", "milestone" and "release". An integration build is much like a "snapshot build" in Maven terminology -- it's an untagged trunk or head build, made available for testing against. A release build is a final build, associated with a tag in the repo.

See http://ant.apache.org/ivy/history/latest-milestone/terminology.html#status.

Please be careful about overriding the meaning of the status.

Also, with regard to:

plugins {
    runtime ":feeds:1.5"
}

This syntax is pseudo-maven syntax for a module.

Please consider also supporting the Ivy-standard shorthand form for a module:

plugins {
    runtime "#feeds;1.5"
}

See http://ant.apache.org/ivy/history/latest-milestone/textual.html.

Note that Groovy's @Grab() feature supports both the Maven-style and the Ivy-style for module shorthands.

Regards

John Hurst
Wellington, New Zealand


On Thu, Feb 25, 2010 at 9:50 PM, Graeme Rocher <[hidden email]> wrote:

On 25 Feb 2010, at 09:18, Peter Ledbrook wrote:

>> I've pushed to the master branch on Git some changes which make Grails uses Ivy to resolve plugins. You can declaratively specify plugins in BuildConfig.groovy:
>>
>> plugins {
>>     runtime ":feeds:1.5"
>> }
>>
>> Installing plugins via install-plugin is still supported and plugins found in the metadata just become runtime scoped plugins.
>
> Yay! Next step, binary plugins :)
>
> I've had a quick look and have a few questions/suggestions:
>
> 1. What does the 'exported' property do? I don't really understand its
> behaviour from the user guide.

Exported is when you have a plugin that depends on jar A, but jar A shouldn't be "exported" to the application when its installed. In otherwords jar A is a dependency of the plugin only during development and not when the plugin is installed.
>
> 2. How does the plugin() method work and where do you use it? I assume
> inside the "dependencies" closure, but I'm not 100% sure. Does using
> the method automatically override the plugin's existing dependencies?
> If so, how does the exclude work?

Well the way the DSL is written it could be used inside or inside the dependencies block, but that is just semantics. This feature actually already exists in Grails 1.2 though, basically how it works is that you can either override or exclude any plugins dependencies. Eg.

plugin("hibernate") {
    excludes "hibernate-ehcache"
}
>
> 3. The examples could do with tabs being replaced with spaces.

Ok.

>
> 4. The guide says you can set the group ID in Config.groovy - do you
> mean BuildConfig.groovy?

Umm, I'll double check, but you're right it should go in BuildConfig.groovy and we should probably add settings in there too change the project name and version.

>
> 5. That same section is title "Projects" but should probably be
> "Applications" to distinguish it from "Plugins".

Good point.
>
> 6. Why "latest.integration", instead of just "latest"? This is partly
> to do with me being a lazy typist, but I'm wondering what the
> "integration" signifies.

This is just Ivy's terminology. When using Ivy you use "latest.integration", don't ask me why. However we could automatically change "latest" to "latest.integration" before passing to ivy

Cheers
Graeme

>
> I'm afraid I probably won't be testing it out for some time, so I
> can't offer more substantive feedback yet.
>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> 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





--
Life is interfering with my game
Reply | Threaded
Open this post in threaded view
|

Re: Grails Plugins & Maven Repos

pledbrook
In reply to this post by Graeme Rocher-3
>> 1. What does the 'exported' property do? I don't really understand its
>> behaviour from the user guide.
>
> Exported is when you have a plugin that depends on jar A, but jar A shouldn't be "exported" to the application when its installed. In otherwords jar A is a dependency of the plugin only during development and not when the plugin is installed.

OK, that's pretty much what I figured. But why not use the "provided"
configuration? Or a synonym if you don't like the name? That's the
usual approach to this problem.

>> 2. How does the plugin() method work and where do you use it? I assume
>> inside the "dependencies" closure, but I'm not 100% sure. Does using
>> the method automatically override the plugin's existing dependencies?
>> If so, how does the exclude work?
>
> Well the way the DSL is written it could be used inside or inside the dependencies block, but that is just semantics. This feature actually already exists in Grails 1.2 though, basically how it works is that you can either override or exclude any plugins dependencies. Eg.
>
> plugin("hibernate") {
>     excludes "hibernate-ehcache"
> }

OK, but what happens in the case of the first example in the guide?

  plugin("hibernate") {
      compile( 'org.hibernate:hibernate-core:3.3.1.GA') {
          excludes 'ehcache', 'xml-apis', 'commons-logging'
      }
      compile 'org.hibernate:hibernate-annotations:3.4.0.GA',
          'org.hibernate:hibernate-commons-annotations:3.3.0.ga'
      runtime 'javassist:javassist:3.4.GA'
  }

Does this simply add the dependencies, overriding any existing ones
with the same groupId/artifactId/version? Or simply by specifying a
"compile" entry, do you block the existing dependencies specified by
the plugin?

>> 6. Why "latest.integration", instead of just "latest"? This is partly
>> to do with me being a lazy typist, but I'm wondering what the
>> "integration" signifies.
>
> This is just Ivy's terminology. When using Ivy you use "latest.integration", don't ask me why. However we could automatically change "latest" to "latest.integration" before passing to ivy

Based on what John said, perhaps we should have "latest.snapshot" and
"latest.release", with support for the native Ivy status values too.
We've used "snapshot" so far and a switch to "integration" seems
confusing.

Cheers,

Peter

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Grails Plugins & Maven Repos

Graeme Rocher-3

On 25 Feb 2010, at 10:21, Peter Ledbrook wrote:

>>> 1. What does the 'exported' property do? I don't really understand its
>>> behaviour from the user guide.
>>
>> Exported is when you have a plugin that depends on jar A, but jar A shouldn't be "exported" to the application when its installed. In otherwords jar A is a dependency of the plugin only during development and not when the plugin is installed.
>
> OK, that's pretty much what I figured. But why not use the "provided"
> configuration? Or a synonym if you don't like the name? That's the
> usual approach to this problem.

Provided has a different meaning in that it it means its provided by the container, and a plugin might supply a provided dependency. We could of course create a new configuration name instead of using "exported" as is defined now.

>
>>> 2. How does the plugin() method work and where do you use it? I assume
>>> inside the "dependencies" closure, but I'm not 100% sure. Does using
>>> the method automatically override the plugin's existing dependencies?
>>> If so, how does the exclude work?
>>
>> Well the way the DSL is written it could be used inside or inside the dependencies block, but that is just semantics. This feature actually already exists in Grails 1.2 though, basically how it works is that you can either override or exclude any plugins dependencies. Eg.
>>
>> plugin("hibernate") {
>>     excludes "hibernate-ehcache"
>> }
>
> OK, but what happens in the case of the first example in the guide?
>
>  plugin("hibernate") {
>      compile( 'org.hibernate:hibernate-core:3.3.1.GA') {
>          excludes 'ehcache', 'xml-apis', 'commons-logging'
>      }
>      compile 'org.hibernate:hibernate-annotations:3.4.0.GA',
>          'org.hibernate:hibernate-commons-annotations:3.3.0.ga'
>      runtime 'javassist:javassist:3.4.GA'
>  }
>
> Does this simply add the dependencies, overriding any existing ones
> with the same groupId/artifactId/version? Or simply by specifying a
> "compile" entry, do you block the existing dependencies specified by
> the plugin?

It doesn't block, it merely overrides.

>
>>> 6. Why "latest.integration", instead of just "latest"? This is partly
>>> to do with me being a lazy typist, but I'm wondering what the
>>> "integration" signifies.
>>
>> This is just Ivy's terminology. When using Ivy you use "latest.integration", don't ask me why. However we could automatically change "latest" to "latest.integration" before passing to ivy
>
> Based on what John said, perhaps we should have "latest.snapshot" and
> "latest.release", with support for the native Ivy status values too.
> We've used "snapshot" so far and a switch to "integration" seems
> confusing.

Well "latest.integration" is just one example I used in the docs but you can use any of Ivy's status values including "release", "milestone" and so on. We're not, as John suggested, "overriding the meaning" of Ivy statuses at the moment we are just passing them on as is to the Ivy layer.

Cheers

>
> Cheers,
>
> Peter
>
> ---------------------------------------------------------------------
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Grails Plugins & Maven Repos

pledbrook
>> OK, that's pretty much what I figured. But why not use the "provided"
>> configuration? Or a synonym if you don't like the name? That's the
>> usual approach to this problem.
>
> Provided has a different meaning in that it it means its provided by the container, and a plugin might supply a provided dependency. We could of course create a new configuration name instead of using "exported" as is defined now.

Yes and no :) I've been using "provided" as a "required for
compilation but not runtime" configuration, because that's exactly
what it does. It just so happens it was mainly introduced to Maven
because of the servlet stuff.

I've been using it heavily because the Grails AST transformations drag
in a lot of dependencies during compilation, but I've already
complained about that before ;)

Anyway, I'd be fine with a different name than "provided" if you want.
I don't suppose anyone else has an opinion?

>> Based on what John said, perhaps we should have "latest.snapshot" and
>> "latest.release", with support for the native Ivy status values too.
>> We've used "snapshot" so far and a switch to "integration" seems
>> confusing.
>
> Well "latest.integration" is just one example I used in the docs but you can use any of Ivy's status values including "release", "milestone" and so on. We're not, as John suggested, "overriding the meaning" of Ivy statuses at the moment we are just passing them on as is to the Ivy layer.

Fair enough, but I would reiterate that I think it would be less
confusing to support and document a "latest.snapshot" status for
non-Ivy aficionados.

Cheers,

Peter

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

    http://xircles.codehaus.org/manage_email