I'm agree with Guillaume, CXF could be the default implementation but not be mandatory.
Le 19/01/2018 à 16:54, Guillaume Nodet a écrit : > 2018-01-19 13:45 GMT+01:00 Daniel Kulp <[email protected]>: > >> >>> On Jan 19, 2018, at 4:00 AM, Guillaume Nodet <[email protected]> wrote: >>> >>> * investigate the use of JaxRS 2.0 api instead of the CXF dependency (to >>> be more flexible and also because it would create yet another circular >>> dependency) >> I’m not sure I get this….. Even if you use the JAX-RS 2.0 API, you still >> need an implementation in order for the API’s to work. I hope the chosen. >> Implementation would remain CXF. >> > 1./ unless there's a compelling reason to tie the implementation to CXF, > I'd rather use the standard API instead > 2./ this does create a circular dependency, as karaf will depend on CXF and > CXF on Karaf. I know this is not a problem when releasing because we > always reference an older version of the other project, but still, if this > can be avoided I think it would be better > 3./ i'd like CXF to be the default and i don't have any reason to switch to > a different provider, but that does not mean everyone should be forced to > use it, as they may have reasons to use a different provider (which could > also be a non technical reason) > > I don't see any difference between choosing a jaxrs provider and choosing a > servlet provider or a transaction manager. We do usually leave room for > choice, I'd like to keep it that way, if that's technically possible. > > >> >> Dan >> >> >> >>> 2018-01-18 10:37 GMT+01:00 Jean-Baptiste Onofré <[email protected]>: >>> >>>> Hi, >>>> >>>> Some days ago, we discussed about Decanter 2.0.0 and using "external" >>>> instances of used engines, like Elasticsearch or Kibana. >>>> >>>> Basically, the main reason is that some engines are not easy to embed in >>>> Karaf. It's the case of Kibana as it uses node.js. >>>> >>>> However, one of the big advantage of embedded instance of Elasticsearch >> or >>>> Kibana is that it's very easy to install and use: it's just a >>>> feature:install command to perform. >>>> >>>> So, I would like to provide both advantages: easy to install and use >> with >>>> external instances ;) >>>> >>>> A first approach would be to create a "exec" bundle starting the >> instance. >>>> But we gonna face the "classic" issues depending of the environment. >>>> >>>> Maybe some of you remember the karaf-docker PoC I did month ago: >>>> >>>> https://github.com/jbonofre/karaf-docker >>>> >>>> This is a simple feature that allows you to manipulate docker images: >>>> bootstrapping, starting/running, ... >>>> >>>> I think it would help a lot in Decanter or Cellar: we can just provide >>>> Karaf Docker commands to bootstrap Elasticsearch, Kibana, OrientDB, ... >>>> As a best effort, we will try to provide embedded instance as possible, >>>> but it won't be the preferred approach. >>>> >>>> As karaf-docker is small project and just basically use docker, I think >> it >>>> doesn't require to be a Karaf subproject. >>>> As we have the karaf scheduler (using Quartz internally), I would like >> to >>>> propose to add docker in Karaf container in a dedicated module. >>>> >>>> It means that users will be able to do feature:install docker to have >> the >>>> docker commands. >>>> I would like also to add a command and configuration to have "ready to >> go >>>> images". Something that will allow users to do: >>>> >>>> docker:run elasticsearch >>>> >>>> then, elasticsearch will use a ready to go dockerfile. >>>> >>>> It would be possible to do: >>>> >>>> docker:run mvn:org.apache.karaf.decanter.docker/elasticsearch/6.1.0/ >> docker >>>> Where we can host ready to use "official" dockerfile. >>>> >>>> Thoughts ? >>>> >>>> Regards >>>> JB >>>> -- >>>> Jean-Baptiste Onofré >>>> [email protected] >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>> >>> >>> -- >>> ------------------------ >>> Guillaume Nodet >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> >
