While I don't have any problem at introducing a kind of mapping, I do fear the abuses it can lead to. I don't really want to add a feature to be able to fix broken things. Valid use cases, sure, broken features descriptors, no. So what I mean is that if we allow any kind of global mapping, we can easily end up screwing the features even more, i.e. if I override the spring stuff as mentionned below, i won't be able to deploy any feature that does need the 2.x release of spring (because of version ranges on the packages such as [2.5,3) for example).
On Tue, Feb 26, 2013 at 10:05 PM, Ioannis Canellos <[email protected]>wrote: > Some of the views expressed so far: > > i) Allow defining an alternate location for a feature repository. > ii) Allow overriding a feature repository or bundle url using a mapping. > iii) Using version feature version ranges to resolve the right version to > use. > > Some thoughts about each idea. > > i) I'd love to be able to do that, even though in most cases modifying the > feature repo in the system directory does work for me. > We could take this one step further an be able to modify the feature repo > itself, using the editor we have in trunk (mostly as a dev tool). > > ii) I like this idea too. This would solve the recent problem we had with > spring versions. We could just let the user define a mapping like > mvn:org.springframework/*/[3,4] = mvn:org.springframework/*/3.1.2.RELEASE > and it would be awesome. > > iii) This would definetely solve a lot of problems, without direct user > interaction. I think that we should maybe start with this point but maybe > also grant the user the power to do things like i) and ii). > > I hope I didn't miss anything. > > -- > *Ioannis Canellos* > * > > ** > Blog: http://iocanel.blogspot.com > ** > Twitter: iocanel > * > -- ------------------------ Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: [email protected] Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
