I have to admit one thing: all of those ideas (as summed up nicely by Ioannis) sound VERY tempting. They would solve some of the problems we're facing in production and would definitely help many people.
BUT I'm definitely with Guillaume. This feels like we're opening the gates to Hell introducing a LOT of possible problems which are anything than intuitive! Wouldn't it be easier providing the tooling providing the correct features.xml files manually? For example I could think of something like the mapping features but only for "compile time use" instead of runtime use. E.g. extending our Karaf Plugin to supporting the url mapping. This could produce the patched feature files with their own versions in quite a minimalistic style. Maybe we could even pack this into a simple command line tool also allowing end users to do this step before starting Karaf. Finally it's all about fixing problems devs introduce because they weren't thinking (or lacking the knowledge) while creating the feature files. Does this sound completely off the road? Would this make sense? Kind regards, Andreas On Tue, Feb 26, 2013 at 10:24 PM, Guillaume Nodet <[email protected]> wrote: > 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/ >
