karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Idea: Allow users to patch feature files
Date Wed, 27 Feb 2013 20:56:45 GMT
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 <anpieber@gmail.com>

> 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 <gnodet@gmail.com>
> 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 <iocanel@gmail.com
> > >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: gnodet@redhat.com
> > 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/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message