Customizing plugin dependencies when using it

[Sandro Martini]

Hi all,
for a couple plugins I'm writing I see that they could have many
dependencies, so up to now I set only minimal dependencies in them
(like a basic profile usage), and plugin consumers won't have too much
dependencies ... ok.

But is it possible to give a plugin a configuration option (like a
profile name) when consuming it ?
In this way I could have by default a minimal (but common) set of
dependencies, and when needed I could use (from consumers point of
view) the plugin in a certain profile (for example profile: 'full')
... what do you think ?

Of course for this to work I should find a way inside plugin
definitions to enable some dependencies only when desired, and I don't
think this is possible up to now ... but in 2.4 ? :-) ...


Otherwise I could handle this by hand (different branches and
different release of the same plugin but of course this is not so
good) ...


Should I open an improvement issue in JIRA for this ?
Comments ?


Thanks for now.

Bye,
Sandro

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

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-2]

The only way I think this could be possible is if the dependencies of
the plugin are specified using a classifier, even then I'm not sure
how it work. Whatever potential solution would have to fit within
current dependency resolution methods (using Aether as the library)

On Thu, Jan 23, 2014 at 11:47 PM, Sandro Martini
<[hidden email]> wrote:

> Hi all,
> for a couple plugins I'm writing I see that they could have many
> dependencies, so up to now I set only minimal dependencies in them
> (like a basic profile usage), and plugin consumers won't have too much
> dependencies ... ok.
>
> But is it possible to give a plugin a configuration option (like a
> profile name) when consuming it ?
> In this way I could have by default a minimal (but common) set of
> dependencies, and when needed I could use (from consumers point of
> view) the plugin in a certain profile (for example profile: 'full')
> ... what do you think ?
>
> Of course for this to work I should find a way inside plugin
> definitions to enable some dependencies only when desired, and I don't
> think this is possible up to now ... but in 2.4 ? :-) ...
>
>
> Otherwise I could handle this by hand (different branches and
> different release of the same plugin but of course this is not so
> good) ...
>
>
> Should I open an improvement issue in JIRA for this ?
> Comments ?
>
>
> Thanks for now.
>
> Bye,
> Sandro
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource

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

    http://xircles.codehaus.org/manage_email

[Sandro Martini]

Hi Graema,
thanks for your comment ...

Otherwise we could try to implement it (but don't know exactly how :-)
) providing an optional map to any plugin, so plugin consumers could
specify additional parameters inside it, like

        compile(":myplugin:1.0.0") {
            // export = false
            pluginExtra = ["profile":"full", "other":"sample"] // by
default null
// or a minimal approach (for my use case could be enough), but a
single variable could be not so useful (generally speaking) ...
            profile = "full" // by default null so it's not necessary
to specify it
        }


And in my plugins (where needed) I could do something like:

    dependencies {

        // default, unchanged
        compile(":base-dependency:1.0.0")
        test(":base-test-dependency1:1.2.0")

        // profile "full"
        if (profile == "full") {
// or
        profile("full") {  // or similar, if/how possible in Groovy/Grails
                compile(":other-dependency1:1.0.0")
                compile(":other-dependency2:1.5.0")
                test(":other-test-dependency1:1.2.0")
         }

        // other profiles ...

    }


but probably even this need some work in Grails general plugin classes I think.
Sorry for all this detail, but it's mainly useful to me to think
if/how this could be written (of course not for you :-) ) ...

With plugins with many dependencies this could really be useful ...
What do you think ? JIRA as improvement for 2.4 or later ?

If you have some pointer I could try to take a look at Grails related
classes ...

Anyway thanks for your help.

Bye,
Sandro



2014/1/24 Graeme Rocher <[hidden email]>:

> The only way I think this could be possible is if the dependencies of
> the plugin are specified using a classifier, even then I'm not sure
> how it work. Whatever potential solution would have to fit within
> current dependency resolution methods (using Aether as the library)
>
> On Thu, Jan 23, 2014 at 11:47 PM, Sandro Martini
> <[hidden email]> wrote:
>> Hi all,
>> for a couple plugins I'm writing I see that they could have many
>> dependencies, so up to now I set only minimal dependencies in them
>> (like a basic profile usage), and plugin consumers won't have too much
>> dependencies ... ok.
>>
>> But is it possible to give a plugin a configuration option (like a
>> profile name) when consuming it ?
>> In this way I could have by default a minimal (but common) set of
>> dependencies, and when needed I could use (from consumers point of
>> view) the plugin in a certain profile (for example profile: 'full')
>> ... what do you think ?
>>
>> Of course for this to work I should find a way inside plugin
>> definitions to enable some dependencies only when desired, and I don't
>> think this is possible up to now ... but in 2.4 ? :-) ...
>>
>>
>> Otherwise I could handle this by hand (different branches and
>> different release of the same plugin but of course this is not so
>> good) ...
>>
>>
>> Should I open an improvement issue in JIRA for this ?
>> Comments ?
>>
>>
>> Thanks for now.
>>
>> Bye,
>> Sandro
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>
>
> --
> Graeme Rocher
> Grails Project Lead
> SpringSource
>
> ---------------------------------------------------------------------
> 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

[davide.cavestro]

I'd need something similar for the jaxrs plugin: we support both jersey and restlet implementations, but when the user choose one of them, the other dependency is not needed (i.e. it could be removed at least from runtime, and hence not included into the application war).
Maybe we could leverage the optional attribute supported by maven and also reflected within aether, but I think we may also need a way to obtain references to optional dependencies and then re-enable them... I think it could be feasible with some support from grails dependencies resolution api.

PS: I've written some days ago on the user mailing list but I got no response. This is why I also posted here.

[Graeme Rocher-2]

optional is already supported when using Aether

On Wed, Feb 12, 2014 at 8:54 AM, davide.cavestro
<[hidden email]> wrote:

> I'd need something similar for the jaxrs plugin: we support both jersey and
> restlet implementations, but when the user choose one of them, the other
> dependency is not needed (i.e. it could be removed at least from runtime,
> and hence not included into the application war).
> Maybe we could leverage the  optional
> <http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html>
> attribute supported by maven and also  reflected within aether
> <http://download.eclipse.org/aether/aether-core/0.9.0.M4/apidocs/org/eclipse/aether/graph/Dependency.html#isOptional()>
> , but I think we may also need a way to obtain references to optional
> dependencies and then re-enable them... I think it could be feasible with
> some support from grails dependencies resolution api.
>
> PS: I've  written
> <http://grails.1312388.n4.nabble.com/Is-there-any-way-to-declare-plugins-optional-deps-and-conditionally-enable-them-within-app-BuildConf-td4653842.html>
> some days ago on the user mailing list but I got no response. This is why I
> also posted here.
>
>
>
> --
> View this message in context: http://grails.1312388.n4.nabble.com/Customizing-plugin-dependencies-when-using-it-tp4653602p4654032.html
> Sent from the Grails - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
SpringSource

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

    http://xircles.codehaus.org/manage_email

[davide.cavestro]

Graeme Rocher-2 wrote

optional is already supported when using Aether

Could you please give me a hint on which event I could listen for in order to hook some additional logic to the default dependency resolution process (i.e. dynamically re-adding a dependency previously discarded as an optional  one).
At http://viaboxxsystems.de/hacking-around-grails-broken-snapshot-dependency-mechanism I've found an example using eventResolveDependenciesEnd  but I didn't find any source within the grails-core project mentioning that event.

[davide.cavestro]

@graeme
Could you please me a hint on how to intercept the dependency resolution phase and modify on the fly some well-known dependencies (i.e. toggling their optional flag in order to actually included them). Even having a way to re-add at build time such dependencies as not optional would be fine.
The problem is that since I'm not familiar with the internals of grails deps resolution I grope in the dark (i.e. I don't find an appropriate event to listen for).
Also a hint on what to search for would be fine. This enhancement would be very useful for grails-jaxrs plugin users. Otherwise we have to split the plugin in a core one and two other jaxrs implementation specific ones.