I second Andreas and Guillaume here, this is going to open the gates to Hell and I'm sure I don't want to go that road :)
The idea of creating a small set of tools to improve this sounds much more reasonable. And as Filippo already said, how do you want to make sure you have a valid artifact deployed in operations if someone mis-uses this, who has been in charge of breaking the operational system? regards, Achim 2013/2/27 Andreas Pieber <[email protected]> > 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/ > > > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
