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 |
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 |
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 |
In reply to this post by Graeme Rocher-2
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. |
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 |
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. |
In reply to this post by Graeme Rocher-2
@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. |
Free forum by Nabble | Edit this page |