Re: Karaf Cave usage

[Morgan Hautman]

To me it sounds like a nexus "pro" repo since they only have OBR in 
their "pro" version.


Is this correct?

Regards
Morgan

On 19/04/2015 20:04, Jean-Baptiste Onofré wrote:
No, Cave is on top of the local dev server. Or the CI can deploy on 
the Cave server.


The Karaf instance bootstrapped by the itests can use the OBR server.

Regards
JB

On 04/19/2015 07:57 PM, Ryan Moquin wrote:

Yes, sorry, I meant as an OBR server.  I wasn't meaning use cases for
Cave, I was just trying to understand how CI servers and Cave are
handled as part of the build and deploy process.  It seems that a rescan
would have to be invoked quite frequently to detect new artifacts
deployed to a Maven repo.

How about with local development?  If artifacts are installed using OBR,
do you have to run a local Cave server in order to install artifacts in
you local dev server?  Or what about in integration tests?

Sorry if these are stupid questions, want to make sure I understand the
best way to integrate it.  :)


On Sun, Apr 19, 2015, 1:47 PM Jean-Baptiste Onofré mailto:j...@nanthrax.net>> wrote:

I guess that you mean when Cave is used as an OBR server. In that 
case,
you have to update the OBR repository metadata by performing a 
new scan.


There are different use cases to Cave:
1/ you need an OBR server and you only have a Maven repo (in 
production)

2/ you don't have any existing Maven repo and you are looking for a
Maven repo to share between multiple Karaf instances (with Cellar 
for

instance)
3/ you want to proxy a external repo (OBR or Maven) internally

Regards
JB

On 04/19/2015 07:40 PM, Ryan Moquin wrote:
 > Hi, I've been looking at Apache Cave and how to best leverage
it.  I had
 > a few questions as a result.  My first one was about how to keep
Cave up
 > to date with changes to a proxied company maven repository, 
such as
 > artifactory.  For example, if your continuous integration 
server is

 > pushing new builds to you maven repo, do you then also have it
remotely
 > invoke a rescan of the proxied repository in the Cave server?
 >
 > What is the typical way that Cave is used in the development and
 > deployment process?
 >
 > Thanks!
 > Ryan
 >

--
Jean-Baptiste Onofré
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Achim Nierbeck]

Hi Ryan,

for the update of a karaf cluster solution I'd suggest to look into cellar.
And while at it, if you have a complex solution to update. A "feature"
oriented application with dynamic switches to enable certain features
might be the best solution. Especially if you just enable that feature on
certain nodes. Attach some monitors (like Decanter) to your
application and if everything works as expected enable the feature
throughout the cluster.

regards, Achim



2015-04-19 18:04 GMT+02:00 Ryan Moquin :

> Also, one reason I think the ability to hot update karaf in production is
> that if you have a lot of servers it can take a long time to vring each one
> down, reinstall a whole docker package and bring it back up.
>
> Also, one thing I never understood about the whole "updating a production
> server is risky and is safer to redeploy entirely" is that you can always
> get a good idea on the success of an update by performing it on test
> servers that are running the same version as production.
>
> On Sun, Apr 19, 2015, 3:50 AM Jean-Baptiste Onofré 
> wrote:
>
>> Hi Christian,
>>
>> We should extend the view to more than single artifacts provisioning.
>> Provisioning also covers both application and container configuration.
>> It's where we bring lot of value as all can be dynamic.
>>
>> More over, you are right about micro-service, but right now, IMHO, lot
>> of people doesn't do micro-services as they bring a lot of overhead on
>> top of the actual service in their application. Karaf and OSGi, if done
>> correctly, provides a more clean way and lightweight way to provide
>> micro-services.
>>
>> Regards
>> JB
>>
>> On 04/19/2015 08:12 AM, Christian Schneider wrote:
>> > I really like the deployment of bundles into a running instance at
>> > development time. For example it allows to debug through my bundle, do a
>> > fix and redeploy the single bundle while the debugger stays open. That
>> > really speeds up the development process.
>> >
>> > At production time though I never saw that for a single application that
>> > deployment at runtime was used. Typically a certain set of bundles is
>> > tested together and released together. So I think in this case docker is
>> > a nice fit as we can pack karaf together with this set of bundles into
>> > an image. This can then be deployed as a simple singular unit which is
>> > good for admins. Rolling back then is also easy as you can just install
>> > the previous image.
>> >
>> > There is one case where runtime deployment makes a lot of sense. This is
>> > the case of an integration server where you deploy lots of small
>> > integrations. Each of these has its own lifecycle and it would not make
>> > sense to build a container for each of them.
>> >
>> > Then there is a case in between represented by the micro services hype
>> > (not in the sense of OSGi Services). There you have an application that
>> > is built from individual modules that each have their own lifecycle and
>> > dependencies. For this case you could use one container and runtime
>> > deployment but you could also create one container for each. I recently
>> > helped to port an application from spring/tomcat to OSGi. The
>> > application was already design to have modules with different
>> > lifecycles. In tomcat this was represented as one war per module /
>> > "microservice". The problem in OSGi was that the application was not
>> > modularized in an OSGi way. So for example there was no semantic
>> > versioning. Some of the bundles had to be installed in one single
>> > version over all the modules. If versions were mixed the wiring of
>> > module A could change when a new version of module B was installed. For
>> > this case having separate containers can help.
>> >
>> > So the picture I painted shows that there is no one size fits all
>> > solution and I think docker can be a good match for some of the use
>> > cases in deployment.
>> >
>> > Christian
>> >
>> > Am 19.04.2015 um 02:44 schrieb Serge Huber:
>> >> James, I don't think JB cared. He was probably more than happy to have
>> >> a discussion than to have to simply walk through slides without any
>> >> feedback. At least that's how I prefer it.
>> >>
>> >> Personally I think that OSGi is really a great way to make sure that
>> >> people get into the good practice about thinking about the full
>> >> lifecycle of code, not just developing it and starting it, but also
>> >> shutting it down, and what happens when dependencies are not present
>> >> or shutdown.
>> >>
>> >> In that regard I've seen that in our team since we switched to OSGi,
>> >> although it took a little investment in terms of getting used to it,
>> >> people are a lot more productive because they can focus on the module
>> >> they are building without having to restart the whole container. This
>> >> is a huge improvement over Docker type of deployments where rebuilding
>> >> and restarting a container can take a lot longer to test a single
>> change.
>> >>
>> >> I

Re: Karaf and Docker

[Achim Nierbeck]

Hi Christian,

I agree concerning the microservice hype and that you have to differ
between development and runtime time.
OTH. I've already seen it working in production to replace a single bundle
due to bug-fixing a critical bug.
So I disagree about that you only deploy a single server setup and replace
that. It is actually much more complex and
therefore requires an appropriate deployment strategy.

regards, Achim

2015-04-19 8:12 GMT+02:00 Christian Schneider :

>  I really like the deployment of bundles into a running instance at
> development time. For example it allows to debug through my bundle, do a
> fix and redeploy the single bundle while the debugger stays open. That
> really speeds up the development process.
>
> At production time though I never saw that for a single application that
> deployment at runtime was used. Typically a certain set of bundles is
> tested together and released together. So I think in this case docker is a
> nice fit as we can pack karaf together with this set of bundles into an
> image. This can then be deployed as a simple singular unit which is good
> for admins. Rolling back then is also easy as you can just install the
> previous image.
>
> There is one case where runtime deployment makes a lot of sense. This is
> the case of an integration server where you deploy lots of small
> integrations. Each of these has its own lifecycle and it would not make
> sense to build a container for each of them.
>
> Then there is a case in between represented by the micro services hype
> (not in the sense of OSGi Services). There you have an application that is
> built from individual modules that each have their own lifecycle and
> dependencies. For this case you could use one container and runtime
> deployment but you could also create one container for each. I recently
> helped to port an application from spring/tomcat to OSGi. The application
> was already design to have modules with different lifecycles. In tomcat
> this was represented as one war per module / "microservice". The problem in
> OSGi was that the application was not modularized in an OSGi way. So for
> example there was no semantic versioning. Some of the bundles had to be
> installed in one single version over all the modules. If versions were
> mixed the wiring of module A could change when a new version of module B
> was installed. For this case having separate containers can help.
>
> So the picture I painted shows that there is no one size fits all solution
> and I think docker can be a good match for some of the use cases in
> deployment.
>
> Christian
>
> Am 19.04.2015 um 02:44 schrieb Serge Huber:
>
> James, I don't think JB cared. He was probably more than happy to have a
> discussion than to have to simply walk through slides without any feedback.
> At least that's how I prefer it.
>
>  Personally I think that OSGi is really a great way to make sure that
> people get into the good practice about thinking about the full lifecycle
> of code, not just developing it and starting it, but also shutting it down,
> and what happens when dependencies are not present or shutdown.
>
>  In that regard I've seen that in our team since we switched to OSGi,
> although it took a little investment in terms of getting used to it, people
> are a lot more productive because they can focus on the module they are
> building without having to restart the whole container. This is a huge
> improvement over Docker type of deployments where rebuilding and restarting
> a container can take a lot longer to test a single change.
>
>  I believe that OSGi is also more than proven since it has been around
> for a long time, and it is defined by a standard body that is quite
> significant. I just wish it would get adopted more, and hopefully Karaf
> will help with this effort.
>
>  Not to make me say that Docker or Spring Boot or the Play Framework
> don't have their merits, but I think that it is not enough to look at the
> time to get started, it is also important to look at the TMDT (an acronym I
> just made up : Total Maintenance and Deployment Time :)).
>
>  cheers,
>   Serge...
>
> - -- --- -=[ shuber at jahia dot com ]= --- -- -
> CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
> Acacias, Switzerland
> twitter: @sergehuber 
>
>  
> JahiaOne , our international user conference is
> back! June 10-12 in Paris - Grab your tickets now
> !
>
>  Jahia is a leading open source User eXperience Platform (UXP) vendor,
> relentlessly working at transforming a siloed industry into a user-driven
> one, beyond technology constraints - http://www.jahia.com
>
>
> On Sat, Apr 18, 2015 at 10:47 AM, James Carman  > wrote:
>
>> Serge,
>>
>>  We had some pretty good discussions during JB's talk (hope we didn't
>> hijack it too much, JB).  I don't think this topic really has anything to
>> do with Docker, ne

Re: Karaf feature installation issue.

[Jean-Baptiste Onofré]

Did you try a bundle:refresh ?

Maybe the hawtio feature installs a jline bundle and so "pollute" the 
resolution chain.


Regards
JB

On 04/19/2015 07:49 PM, Ryan Moquin wrote:

No, I just started Karaf 3.03, installed, uninstalled and then attempted
to reinstall Hawtio which gave me the error below.  I'm doing it all on
the same karaf version right after one another.  When the error occurs,
I then get jline dependency conflicts when I try to install my features
(which hadn't been installed since I started Karaf that time.)

Ryan


On Sun, Apr 19, 2015, 1:44 PM Jean-Baptiste Onofré mailto:j...@nanthrax.net>> wrote:

I bet that you tried the same version of hawtio but with different Karaf
version: so the jline version may differ.

Regards
JB

On 04/19/2015 05:56 PM, Ryan Moquin wrote:
 > I was going to but it felt like if hawtio installed initially then it
 > should be able to be installed again or it shouldn't prevent me from
 > being able to install my features.. I wouldn't think I should get
that
 > error with jline should I?  I thought one of the purposes of the
bundle
 > classloaders is so that bundles can use different versions of
dependent
 > bundles?  I'm also still not sure why this error wouldn't occur when
 > hawtio is initially installed?  Seems like the dependency resolution
 > changes because of the hawtio dependencies that are left over
from the
 > initial install?
 >
 >
 > On Sun, Apr 19, 2015, 3:52 AM Jean-Baptiste Onofré
mailto:j...@nanthrax.net>
 > >> wrote:
 >
 > Hi Ryan,
 >
 > just ask to Hawtio guys, as it seems there are a dependency
issue with
 > jline.
 >
 > Regards
 > JB
 >
 > On 04/19/2015 05:44 AM, Ryan Moquin wrote:
 >  > Hi,
 >  >
 >  > So I decided to experiment with installing, removing and
reinstalling
 >  > features.  I now remember the reason why I am unsure about
how to
 >  > upgrade a feature.  I seem to be able to install,
uninstall and then
 >  > reinstall my features (didn't play with it too much, just
tried
 > to see
 >  > if it looks like it worked) but things break if you do the
same thing
 >  > with Hawtio and I'm not really sure why.  So if you do the
following
 >  > from a fresh Karaf 3.0.3:
 >  >
 >  > karaf@root>feature:repo-add hawtio
 >  > Adding feature url
mvn:io.hawt/hawtio-karaf/LATEST/xml/features
 >  > karaf@root>feature:install hawtio-offline
 >  > karaf@root>feature:repo-remove -u hawtio-1.4.48
 >  > karaf@root>feature:repo-add hawtio
 >  > Adding feature url
mvn:io.hawt/hawtio-karaf/LATEST/xml/features
 >  > karaf@root>feature:install hawtio-offline
 >  >
 >  > then you get the error below.  At that point I can't even
install my
 >  > Karaf features the first time because of the jine
conflicts.  If
 > there
 >  > is truly a JLine conflict, why does hawtio install
correctly at all?
 >  >
 >  > 2015-04-18 23:28:14,527 | ERROR | l for user karaf | ShellUtil
 >  >   | 25 - org.apache.karaf.shell.console - 3.0.3 |
 > Exception
 >  > caught while executing command
 >  > java.lang.IllegalStateException: Can't install feature
 > hawtio-offline/0.0.0:
 >  > Could not start bundle
 > mvn:io.hawt/hawtio-karaf-terminal/1.4.48/war in
 >  > feature(s) hawtio-karaf-terminal-1.4.48: Uses constraint
violation.
 >  > Unable to resolve bundle revision
io.hawt.hawtio-karaf-terminal
 > [107.0]
 >  > because it is exposed to package 'jline' from bundle
revisions jline
 >  > [106.0] and jline [22.0] via two dependency chains.
 >  >
 >  > Chain 1:
 >  >io.hawt.hawtio-karaf-terminal [107.0]
 >  >  import:
 >  >
(&(osgi.wiring.package=jline)(version>=2.11.0)(!(version>=3.0.0)))
 >  >   |
 >  >  export: osgi.wiring.package=jline
 >  >jline [106.0]
 >  >
 >  > Chain 2:
 >  >io.hawt.hawtio-karaf-terminal [107.0]
 >  >  import:
 >  >
 >
  
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=4.0.0)))
 >  >   |
 >  >  export:
osgi.wiring.package=org.apache.karaf.shell.console;
 > uses:=jline
 >  >org.apache.karaf.shell.console [25.0]
 >  >  import:
 >  >
(&(osgi.wiring.package=jline)(version>=2.12.0)(!(version>=3.0.0)))
 >  >   |
 >  >  export: osgi.wiring.package=jline
 >  >jline [22.0]
 >  > at
 >  >
 >
  
org.a

Re: Karaf Cave usage

[Jean-Baptiste Onofré]

No, Cave is on top of the local dev server. Or the CI can deploy on the 
Cave server.


The Karaf instance bootstrapped by the itests can use the OBR server.

Regards
JB

On 04/19/2015 07:57 PM, Ryan Moquin wrote:

Yes, sorry, I meant as an OBR server.  I wasn't meaning use cases for
Cave, I was just trying to understand how CI servers and Cave are
handled as part of the build and deploy process.  It seems that a rescan
would have to be invoked quite frequently to detect new artifacts
deployed to a Maven repo.

How about with local development?  If artifacts are installed using OBR,
do you have to run a local Cave server in order to install artifacts in
you local dev server?  Or what about in integration tests?

Sorry if these are stupid questions, want to make sure I understand the
best way to integrate it.  :)


On Sun, Apr 19, 2015, 1:47 PM Jean-Baptiste Onofré mailto:j...@nanthrax.net>> wrote:

I guess that you mean when Cave is used as an OBR server. In that case,
you have to update the OBR repository metadata by performing a new scan.

There are different use cases to Cave:
1/ you need an OBR server and you only have a Maven repo (in production)
2/ you don't have any existing Maven repo and you are looking for a
Maven repo to share between multiple Karaf instances (with Cellar for
instance)
3/ you want to proxy a external repo (OBR or Maven) internally

Regards
JB

On 04/19/2015 07:40 PM, Ryan Moquin wrote:
 > Hi, I've been looking at Apache Cave and how to best leverage
it.  I had
 > a few questions as a result.  My first one was about how to keep
Cave up
 > to date with changes to a proxied company maven repository, such as
 > artifactory.  For example, if your continuous integration server is
 > pushing new builds to you maven repo, do you then also have it
remotely
 > invoke a rescan of the proxied repository in the Cave server?
 >
 > What is the typical way that Cave is used in the development and
 > deployment process?
 >
 > Thanks!
 > Ryan
 >

--
Jean-Baptiste Onofré
jbono...@apache.org 
http://blog.nanthrax.net
Talend - http://www.talend.com



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf Cave usage

[Ryan Moquin]

Yes, sorry, I meant as an OBR server.  I wasn't meaning use cases for Cave,
I was just trying to understand how CI servers and Cave are handled as part
of the build and deploy process.  It seems that a rescan would have to be
invoked quite frequently to detect new artifacts deployed to a Maven repo.

How about with local development?  If artifacts are installed using OBR, do
you have to run a local Cave server in order to install artifacts in you
local dev server?  Or what about in integration tests?

Sorry if these are stupid questions, want to make sure I understand the
best way to integrate it.  :)

On Sun, Apr 19, 2015, 1:47 PM Jean-Baptiste Onofré  wrote:

> I guess that you mean when Cave is used as an OBR server. In that case,
> you have to update the OBR repository metadata by performing a new scan.
>
> There are different use cases to Cave:
> 1/ you need an OBR server and you only have a Maven repo (in production)
> 2/ you don't have any existing Maven repo and you are looking for a
> Maven repo to share between multiple Karaf instances (with Cellar for
> instance)
> 3/ you want to proxy a external repo (OBR or Maven) internally
>
> Regards
> JB
>
> On 04/19/2015 07:40 PM, Ryan Moquin wrote:
> > Hi, I've been looking at Apache Cave and how to best leverage it.  I had
> > a few questions as a result.  My first one was about how to keep Cave up
> > to date with changes to a proxied company maven repository, such as
> > artifactory.  For example, if your continuous integration server is
> > pushing new builds to you maven repo, do you then also have it remotely
> > invoke a rescan of the proxied repository in the Cave server?
> >
> > What is the typical way that Cave is used in the development and
> > deployment process?
> >
> > Thanks!
> > Ryan
> >
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Karaf feature installation issue.

[Ryan Moquin]

No, I just started Karaf 3.03, installed, uninstalled and then attempted to
reinstall Hawtio which gave me the error below.  I'm doing it all on the
same karaf version right after one another.  When the error occurs, I then
get jline dependency conflicts when I try to install my features (which
hadn't been installed since I started Karaf that time.)

Ryan

On Sun, Apr 19, 2015, 1:44 PM Jean-Baptiste Onofré  wrote:

> I bet that you tried the same version of hawtio but with different Karaf
> version: so the jline version may differ.
>
> Regards
> JB
>
> On 04/19/2015 05:56 PM, Ryan Moquin wrote:
> > I was going to but it felt like if hawtio installed initially then it
> > should be able to be installed again or it shouldn't prevent me from
> > being able to install my features.. I wouldn't think I should get that
> > error with jline should I?  I thought one of the purposes of the bundle
> > classloaders is so that bundles can use different versions of dependent
> > bundles?  I'm also still not sure why this error wouldn't occur when
> > hawtio is initially installed?  Seems like the dependency resolution
> > changes because of the hawtio dependencies that are left over from the
> > initial install?
> >
> >
> > On Sun, Apr 19, 2015, 3:52 AM Jean-Baptiste Onofré  > > wrote:
> >
> > Hi Ryan,
> >
> > just ask to Hawtio guys, as it seems there are a dependency issue
> with
> > jline.
> >
> > Regards
> > JB
> >
> > On 04/19/2015 05:44 AM, Ryan Moquin wrote:
> >  > Hi,
> >  >
> >  > So I decided to experiment with installing, removing and
> reinstalling
> >  > features.  I now remember the reason why I am unsure about how to
> >  > upgrade a feature.  I seem to be able to install, uninstall and
> then
> >  > reinstall my features (didn't play with it too much, just tried
> > to see
> >  > if it looks like it worked) but things break if you do the same
> thing
> >  > with Hawtio and I'm not really sure why.  So if you do the
> following
> >  > from a fresh Karaf 3.0.3:
> >  >
> >  > karaf@root>feature:repo-add hawtio
> >  > Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
> >  > karaf@root>feature:install hawtio-offline
> >  > karaf@root>feature:repo-remove -u hawtio-1.4.48
> >  > karaf@root>feature:repo-add hawtio
> >  > Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
> >  > karaf@root>feature:install hawtio-offline
> >  >
> >  > then you get the error below.  At that point I can't even install
> my
> >  > Karaf features the first time because of the jine conflicts.  If
> > there
> >  > is truly a JLine conflict, why does hawtio install correctly at
> all?
> >  >
> >  > 2015-04-18 23:28:14,527 | ERROR | l for user karaf | ShellUtil
> >  >   | 25 - org.apache.karaf.shell.console - 3.0.3 |
> > Exception
> >  > caught while executing command
> >  > java.lang.IllegalStateException: Can't install feature
> > hawtio-offline/0.0.0:
> >  > Could not start bundle
> > mvn:io.hawt/hawtio-karaf-terminal/1.4.48/war in
> >  > feature(s) hawtio-karaf-terminal-1.4.48: Uses constraint
> violation.
> >  > Unable to resolve bundle revision io.hawt.hawtio-karaf-terminal
> > [107.0]
> >  > because it is exposed to package 'jline' from bundle revisions
> jline
> >  > [106.0] and jline [22.0] via two dependency chains.
> >  >
> >  > Chain 1:
> >  >io.hawt.hawtio-karaf-terminal [107.0]
> >  >  import:
> >  > (&(osgi.wiring.package=jline)(version>=2.11.0)(!(version>=3.0.0)))
> >  >   |
> >  >  export: osgi.wiring.package=jline
> >  >jline [106.0]
> >  >
> >  > Chain 2:
> >  >io.hawt.hawtio-karaf-terminal [107.0]
> >  >  import:
> >  >
> >
>  
> (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=4.0.0)))
> >  >   |
> >  >  export: osgi.wiring.package=org.apache.karaf.shell.console;
> > uses:=jline
> >  >org.apache.karaf.shell.console [25.0]
> >  >  import:
> >  > (&(osgi.wiring.package=jline)(version>=2.12.0)(!(version>=3.0.0)))
> >  >   |
> >  >  export: osgi.wiring.package=jline
> >  >jline [22.0]
> >  > at
> >  >
> >
>  
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:388)
> >  > at
> > Proxyaa4edd16_924a_4c58_9988_7a5a568d5be9.installFeature(Unknown
> Source)
> >  > at
> >  >
> >
>  
> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:67)
> >  > at
> >  >
> >
>  
> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:38)
> >  > at
> >  >
> >
>  
> org.apache.karaf.shell.console.AbstractAction.execute(AbstractAction.java:33)[25:org.apache.karaf.shell.consol

Re: Karaf Cave usage

[Jean-Baptiste Onofré]

I guess that you mean when Cave is used as an OBR server. In that case, 
you have to update the OBR repository metadata by performing a new scan.


There are different use cases to Cave:
1/ you need an OBR server and you only have a Maven repo (in production)
2/ you don't have any existing Maven repo and you are looking for a 
Maven repo to share between multiple Karaf instances (with Cellar for 
instance)

3/ you want to proxy a external repo (OBR or Maven) internally

Regards
JB

On 04/19/2015 07:40 PM, Ryan Moquin wrote:

Hi, I've been looking at Apache Cave and how to best leverage it.  I had
a few questions as a result.  My first one was about how to keep Cave up
to date with changes to a proxied company maven repository, such as
artifactory.  For example, if your continuous integration server is
pushing new builds to you maven repo, do you then also have it remotely
invoke a rescan of the proxied repository in the Cave server?

What is the typical way that Cave is used in the development and
deployment process?

Thanks!
Ryan



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf feature installation issue.

[Jean-Baptiste Onofré]

I bet that you tried the same version of hawtio but with different Karaf 
version: so the jline version may differ.


Regards
JB

On 04/19/2015 05:56 PM, Ryan Moquin wrote:

I was going to but it felt like if hawtio installed initially then it
should be able to be installed again or it shouldn't prevent me from
being able to install my features.. I wouldn't think I should get that
error with jline should I?  I thought one of the purposes of the bundle
classloaders is so that bundles can use different versions of dependent
bundles?  I'm also still not sure why this error wouldn't occur when
hawtio is initially installed?  Seems like the dependency resolution
changes because of the hawtio dependencies that are left over from the
initial install?


On Sun, Apr 19, 2015, 3:52 AM Jean-Baptiste Onofré mailto:j...@nanthrax.net>> wrote:

Hi Ryan,

just ask to Hawtio guys, as it seems there are a dependency issue with
jline.

Regards
JB

On 04/19/2015 05:44 AM, Ryan Moquin wrote:
 > Hi,
 >
 > So I decided to experiment with installing, removing and reinstalling
 > features.  I now remember the reason why I am unsure about how to
 > upgrade a feature.  I seem to be able to install, uninstall and then
 > reinstall my features (didn't play with it too much, just tried
to see
 > if it looks like it worked) but things break if you do the same thing
 > with Hawtio and I'm not really sure why.  So if you do the following
 > from a fresh Karaf 3.0.3:
 >
 > karaf@root>feature:repo-add hawtio
 > Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
 > karaf@root>feature:install hawtio-offline
 > karaf@root>feature:repo-remove -u hawtio-1.4.48
 > karaf@root>feature:repo-add hawtio
 > Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
 > karaf@root>feature:install hawtio-offline
 >
 > then you get the error below.  At that point I can't even install my
 > Karaf features the first time because of the jine conflicts.  If
there
 > is truly a JLine conflict, why does hawtio install correctly at all?
 >
 > 2015-04-18 23:28:14,527 | ERROR | l for user karaf | ShellUtil
 >   | 25 - org.apache.karaf.shell.console - 3.0.3 |
Exception
 > caught while executing command
 > java.lang.IllegalStateException: Can't install feature
hawtio-offline/0.0.0:
 > Could not start bundle
mvn:io.hawt/hawtio-karaf-terminal/1.4.48/war in
 > feature(s) hawtio-karaf-terminal-1.4.48: Uses constraint violation.
 > Unable to resolve bundle revision io.hawt.hawtio-karaf-terminal
[107.0]
 > because it is exposed to package 'jline' from bundle revisions jline
 > [106.0] and jline [22.0] via two dependency chains.
 >
 > Chain 1:
 >io.hawt.hawtio-karaf-terminal [107.0]
 >  import:
 > (&(osgi.wiring.package=jline)(version>=2.11.0)(!(version>=3.0.0)))
 >   |
 >  export: osgi.wiring.package=jline
 >jline [106.0]
 >
 > Chain 2:
 >io.hawt.hawtio-karaf-terminal [107.0]
 >  import:
 >

(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=4.0.0)))
 >   |
 >  export: osgi.wiring.package=org.apache.karaf.shell.console;
uses:=jline
 >org.apache.karaf.shell.console [25.0]
 >  import:
 > (&(osgi.wiring.package=jline)(version>=2.12.0)(!(version>=3.0.0)))
 >   |
 >  export: osgi.wiring.package=jline
 >jline [22.0]
 > at
 >

org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:388)
 > at
Proxyaa4edd16_924a_4c58_9988_7a5a568d5be9.installFeature(Unknown Source)
 > at
 >

org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:67)
 > at
 >

org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:38)
 > at
 >

org.apache.karaf.shell.console.AbstractAction.execute(AbstractAction.java:33)[25:org.apache.karaf.shell.console:3.0.3]
 > at
 >

org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:39)[25:org.apache.karaf.shell.console:3.0.3]
 > at
 >

org.apache.karaf.shell.commands.basic.AbstractCommand.execute(AbstractCommand.java:33)[25:org.apache.karaf.shell.console:3.0.3]
 > at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown
Source)[:]
 > at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown
Source)[:]
 > at
 >

org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[25:org.apache.karaf.shell.console:3.0.3]
 > at
 >

org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[25:org.apache.karaf.shell.console:3.0.3]
 > at
 >

org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[

Karaf Cave usage

[Ryan Moquin]

Hi, I've been looking at Apache Cave and how to best leverage it.  I had a
few questions as a result.  My first one was about how to keep Cave up to
date with changes to a proxied company maven repository, such as
artifactory.  For example, if your continuous integration server is pushing
new builds to you maven repo, do you then also have it remotely invoke a
rescan of the proxied repository in the Cave server?

What is the typical way that Cave is used in the development and deployment
process?

Thanks!
Ryan

Re: Karaf and Docker

[Ryan Moquin]

Also, one reason I think the ability to hot update karaf in production is
that if you have a lot of servers it can take a long time to vring each one
down, reinstall a whole docker package and bring it back up.

Also, one thing I never understood about the whole "updating a production
server is risky and is safer to redeploy entirely" is that you can always
get a good idea on the success of an update by performing it on test
servers that are running the same version as production.

On Sun, Apr 19, 2015, 3:50 AM Jean-Baptiste Onofré  wrote:

> Hi Christian,
>
> We should extend the view to more than single artifacts provisioning.
> Provisioning also covers both application and container configuration.
> It's where we bring lot of value as all can be dynamic.
>
> More over, you are right about micro-service, but right now, IMHO, lot
> of people doesn't do micro-services as they bring a lot of overhead on
> top of the actual service in their application. Karaf and OSGi, if done
> correctly, provides a more clean way and lightweight way to provide
> micro-services.
>
> Regards
> JB
>
> On 04/19/2015 08:12 AM, Christian Schneider wrote:
> > I really like the deployment of bundles into a running instance at
> > development time. For example it allows to debug through my bundle, do a
> > fix and redeploy the single bundle while the debugger stays open. That
> > really speeds up the development process.
> >
> > At production time though I never saw that for a single application that
> > deployment at runtime was used. Typically a certain set of bundles is
> > tested together and released together. So I think in this case docker is
> > a nice fit as we can pack karaf together with this set of bundles into
> > an image. This can then be deployed as a simple singular unit which is
> > good for admins. Rolling back then is also easy as you can just install
> > the previous image.
> >
> > There is one case where runtime deployment makes a lot of sense. This is
> > the case of an integration server where you deploy lots of small
> > integrations. Each of these has its own lifecycle and it would not make
> > sense to build a container for each of them.
> >
> > Then there is a case in between represented by the micro services hype
> > (not in the sense of OSGi Services). There you have an application that
> > is built from individual modules that each have their own lifecycle and
> > dependencies. For this case you could use one container and runtime
> > deployment but you could also create one container for each. I recently
> > helped to port an application from spring/tomcat to OSGi. The
> > application was already design to have modules with different
> > lifecycles. In tomcat this was represented as one war per module /
> > "microservice". The problem in OSGi was that the application was not
> > modularized in an OSGi way. So for example there was no semantic
> > versioning. Some of the bundles had to be installed in one single
> > version over all the modules. If versions were mixed the wiring of
> > module A could change when a new version of module B was installed. For
> > this case having separate containers can help.
> >
> > So the picture I painted shows that there is no one size fits all
> > solution and I think docker can be a good match for some of the use
> > cases in deployment.
> >
> > Christian
> >
> > Am 19.04.2015 um 02:44 schrieb Serge Huber:
> >> James, I don't think JB cared. He was probably more than happy to have
> >> a discussion than to have to simply walk through slides without any
> >> feedback. At least that's how I prefer it.
> >>
> >> Personally I think that OSGi is really a great way to make sure that
> >> people get into the good practice about thinking about the full
> >> lifecycle of code, not just developing it and starting it, but also
> >> shutting it down, and what happens when dependencies are not present
> >> or shutdown.
> >>
> >> In that regard I've seen that in our team since we switched to OSGi,
> >> although it took a little investment in terms of getting used to it,
> >> people are a lot more productive because they can focus on the module
> >> they are building without having to restart the whole container. This
> >> is a huge improvement over Docker type of deployments where rebuilding
> >> and restarting a container can take a lot longer to test a single
> change.
> >>
> >> I believe that OSGi is also more than proven since it has been around
> >> for a long time, and it is defined by a standard body that is quite
> >> significant. I just wish it would get adopted more, and hopefully
> >> Karaf will help with this effort.
> >>
> >> Not to make me say that Docker or Spring Boot or the Play Framework
> >> don't have their merits, but I think that it is not enough to look at
> >> the time to get started, it is also important to look at the TMDT (an
> >> acronym I just made up : Total Maintenance and Deployment Time :)).
> >>
> >> cheers,
> >>   Serge...
> >>
> >> - -- --- ---

Re: Karaf feature installation issue.

[Ryan Moquin]

I was going to but it felt like if hawtio installed initially then it
should be able to be installed again or it shouldn't prevent me from being
able to install my features.. I wouldn't think I should get that error with
jline should I?  I thought one of the purposes of the bundle classloaders
is so that bundles can use different versions of dependent bundles?  I'm
also still not sure why this error wouldn't occur when hawtio is initially
installed?  Seems like the dependency resolution changes because of the
hawtio dependencies that are left over from the initial install?

On Sun, Apr 19, 2015, 3:52 AM Jean-Baptiste Onofré  wrote:

> Hi Ryan,
>
> just ask to Hawtio guys, as it seems there are a dependency issue with
> jline.
>
> Regards
> JB
>
> On 04/19/2015 05:44 AM, Ryan Moquin wrote:
> > Hi,
> >
> > So I decided to experiment with installing, removing and reinstalling
> > features.  I now remember the reason why I am unsure about how to
> > upgrade a feature.  I seem to be able to install, uninstall and then
> > reinstall my features (didn't play with it too much, just tried to see
> > if it looks like it worked) but things break if you do the same thing
> > with Hawtio and I'm not really sure why.  So if you do the following
> > from a fresh Karaf 3.0.3:
> >
> > karaf@root>feature:repo-add hawtio
> > Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
> > karaf@root>feature:install hawtio-offline
> > karaf@root>feature:repo-remove -u hawtio-1.4.48
> > karaf@root>feature:repo-add hawtio
> > Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
> > karaf@root>feature:install hawtio-offline
> >
> > then you get the error below.  At that point I can't even install my
> > Karaf features the first time because of the jine conflicts.  If there
> > is truly a JLine conflict, why does hawtio install correctly at all?
> >
> > 2015-04-18 23:28:14,527 | ERROR | l for user karaf | ShellUtil
> >   | 25 - org.apache.karaf.shell.console - 3.0.3 | Exception
> > caught while executing command
> > java.lang.IllegalStateException: Can't install feature
> hawtio-offline/0.0.0:
> > Could not start bundle mvn:io.hawt/hawtio-karaf-terminal/1.4.48/war in
> > feature(s) hawtio-karaf-terminal-1.4.48: Uses constraint violation.
> > Unable to resolve bundle revision io.hawt.hawtio-karaf-terminal [107.0]
> > because it is exposed to package 'jline' from bundle revisions jline
> > [106.0] and jline [22.0] via two dependency chains.
> >
> > Chain 1:
> >io.hawt.hawtio-karaf-terminal [107.0]
> >  import:
> > (&(osgi.wiring.package=jline)(version>=2.11.0)(!(version>=3.0.0)))
> >   |
> >  export: osgi.wiring.package=jline
> >jline [106.0]
> >
> > Chain 2:
> >io.hawt.hawtio-karaf-terminal [107.0]
> >  import:
> >
> (&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=4.0.0)))
> >   |
> >  export: osgi.wiring.package=org.apache.karaf.shell.console;
> uses:=jline
> >org.apache.karaf.shell.console [25.0]
> >  import:
> > (&(osgi.wiring.package=jline)(version>=2.12.0)(!(version>=3.0.0)))
> >   |
> >  export: osgi.wiring.package=jline
> >jline [22.0]
> > at
> >
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:388)
> > at Proxyaa4edd16_924a_4c58_9988_7a5a568d5be9.installFeature(Unknown
> Source)
> > at
> >
> org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:67)
> > at
> >
> org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:38)
> > at
> >
> org.apache.karaf.shell.console.AbstractAction.execute(AbstractAction.java:33)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:39)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.karaf.shell.commands.basic.AbstractCommand.execute(AbstractCommand.java:33)[25:org.apache.karaf.shell.console:3.0.3]
> > at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown Source)[:]
> > at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown Source)[:]
> > at
> >
> org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[25:org.apache.karaf.shell.console:3.0.3]
> > at
> >
> org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
> > at
> >

Re: Karaf feature installation issue.

[Jean-Baptiste Onofré]

Hi Ryan,

just ask to Hawtio guys, as it seems there are a dependency issue with 
jline.


Regards
JB

On 04/19/2015 05:44 AM, Ryan Moquin wrote:

Hi,

So I decided to experiment with installing, removing and reinstalling
features.  I now remember the reason why I am unsure about how to
upgrade a feature.  I seem to be able to install, uninstall and then
reinstall my features (didn't play with it too much, just tried to see
if it looks like it worked) but things break if you do the same thing
with Hawtio and I'm not really sure why.  So if you do the following
from a fresh Karaf 3.0.3:

karaf@root>feature:repo-add hawtio
Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
karaf@root>feature:install hawtio-offline
karaf@root>feature:repo-remove -u hawtio-1.4.48
karaf@root>feature:repo-add hawtio
Adding feature url mvn:io.hawt/hawtio-karaf/LATEST/xml/features
karaf@root>feature:install hawtio-offline

then you get the error below.  At that point I can't even install my
Karaf features the first time because of the jine conflicts.  If there
is truly a JLine conflict, why does hawtio install correctly at all?

2015-04-18 23:28:14,527 | ERROR | l for user karaf | ShellUtil
  | 25 - org.apache.karaf.shell.console - 3.0.3 | Exception
caught while executing command
java.lang.IllegalStateException: Can't install feature hawtio-offline/0.0.0:
Could not start bundle mvn:io.hawt/hawtio-karaf-terminal/1.4.48/war in
feature(s) hawtio-karaf-terminal-1.4.48: Uses constraint violation.
Unable to resolve bundle revision io.hawt.hawtio-karaf-terminal [107.0]
because it is exposed to package 'jline' from bundle revisions jline
[106.0] and jline [22.0] via two dependency chains.

Chain 1:
   io.hawt.hawtio-karaf-terminal [107.0]
 import:
(&(osgi.wiring.package=jline)(version>=2.11.0)(!(version>=3.0.0)))
  |
 export: osgi.wiring.package=jline
   jline [106.0]

Chain 2:
   io.hawt.hawtio-karaf-terminal [107.0]
 import:
(&(osgi.wiring.package=org.apache.karaf.shell.console)(version>=3.0.0)(!(version>=4.0.0)))
  |
 export: osgi.wiring.package=org.apache.karaf.shell.console; uses:=jline
   org.apache.karaf.shell.console [25.0]
 import:
(&(osgi.wiring.package=jline)(version>=2.12.0)(!(version>=3.0.0)))
  |
 export: osgi.wiring.package=jline
   jline [22.0]
at
org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(FeaturesServiceImpl.java:388)
at Proxyaa4edd16_924a_4c58_9988_7a5a568d5be9.installFeature(Unknown Source)
at
org.apache.karaf.features.command.InstallFeatureCommand.doExecute(InstallFeatureCommand.java:67)
at
org.apache.karaf.features.command.FeaturesCommandSupport.doExecute(FeaturesCommandSupport.java:38)
at
org.apache.karaf.shell.console.AbstractAction.execute(AbstractAction.java:33)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.karaf.shell.console.OsgiCommandSupport.execute(OsgiCommandSupport.java:39)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.karaf.shell.commands.basic.AbstractCommand.execute(AbstractCommand.java:33)[25:org.apache.karaf.shell.console:3.0.3]
at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown Source)[:]
at Proxy61b43e2d_4b68_41fc_9baa_2a6881f18400.execute(Unknown Source)[:]
at
org.apache.felix.gogo.runtime.CommandProxy.execute(CommandProxy.java:78)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:477)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:403)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Pipe.run(Pipe.java:108)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:183)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.Closure.execute(Closure.java:120)[25:org.apache.karaf.shell.console:3.0.3]
at
org.apache.felix.gogo.runtime.CommandSessionImpl.execute(CommandSessionImpl.java:92)
at
org.apache.karaf.shell.console.impl.jline.ConsoleImpl.run(ConsoleImpl.java:208)
at
org.apache.karaf.shell.console.impl.jline.LocalConsoleManager$2$1$1.run(LocalConsoleManager.java:109)
at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_40]
at
org.apache.karaf.jaas.modules.JaasHelper.doAs(JaasHelper.java:57)[26:org.apache.karaf.jaas.modules:3.0.3]
at
org.apache.karaf.shell.console.impl.jline.LocalConsoleManager$2$1.run(LocalConsoleManager.java:102)[25:org.apache.karaf.shell.console:3.0.3]
2015-04-18 23:33:03,172 | WARN  | l for user karaf |
FeatureValidationUtil| 20 - org.a


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Jean-Baptiste Onofré]

Hi Christian,

We should extend the view to more than single artifacts provisioning. 
Provisioning also covers both application and container configuration.

It's where we bring lot of value as all can be dynamic.

More over, you are right about micro-service, but right now, IMHO, lot 
of people doesn't do micro-services as they bring a lot of overhead on 
top of the actual service in their application. Karaf and OSGi, if done 
correctly, provides a more clean way and lightweight way to provide 
micro-services.


Regards
JB

On 04/19/2015 08:12 AM, Christian Schneider wrote:

I really like the deployment of bundles into a running instance at
development time. For example it allows to debug through my bundle, do a
fix and redeploy the single bundle while the debugger stays open. That
really speeds up the development process.

At production time though I never saw that for a single application that
deployment at runtime was used. Typically a certain set of bundles is
tested together and released together. So I think in this case docker is
a nice fit as we can pack karaf together with this set of bundles into
an image. This can then be deployed as a simple singular unit which is
good for admins. Rolling back then is also easy as you can just install
the previous image.

There is one case where runtime deployment makes a lot of sense. This is
the case of an integration server where you deploy lots of small
integrations. Each of these has its own lifecycle and it would not make
sense to build a container for each of them.

Then there is a case in between represented by the micro services hype
(not in the sense of OSGi Services). There you have an application that
is built from individual modules that each have their own lifecycle and
dependencies. For this case you could use one container and runtime
deployment but you could also create one container for each. I recently
helped to port an application from spring/tomcat to OSGi. The
application was already design to have modules with different
lifecycles. In tomcat this was represented as one war per module /
"microservice". The problem in OSGi was that the application was not
modularized in an OSGi way. So for example there was no semantic
versioning. Some of the bundles had to be installed in one single
version over all the modules. If versions were mixed the wiring of
module A could change when a new version of module B was installed. For
this case having separate containers can help.

So the picture I painted shows that there is no one size fits all
solution and I think docker can be a good match for some of the use
cases in deployment.

Christian

Am 19.04.2015 um 02:44 schrieb Serge Huber:

James, I don't think JB cared. He was probably more than happy to have
a discussion than to have to simply walk through slides without any
feedback. At least that's how I prefer it.

Personally I think that OSGi is really a great way to make sure that
people get into the good practice about thinking about the full
lifecycle of code, not just developing it and starting it, but also
shutting it down, and what happens when dependencies are not present
or shutdown.

In that regard I've seen that in our team since we switched to OSGi,
although it took a little investment in terms of getting used to it,
people are a lot more productive because they can focus on the module
they are building without having to restart the whole container. This
is a huge improvement over Docker type of deployments where rebuilding
and restarting a container can take a lot longer to test a single change.

I believe that OSGi is also more than proven since it has been around
for a long time, and it is defined by a standard body that is quite
significant. I just wish it would get adopted more, and hopefully
Karaf will help with this effort.

Not to make me say that Docker or Spring Boot or the Play Framework
don't have their merits, but I think that it is not enough to look at
the time to get started, it is also important to look at the TMDT (an
acronym I just made up : Total Maintenance and Deployment Time :)).

cheers,
  Serge...

- -- --- -=[ shuber at jahia dot com ]= --- -- -
CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227
Acacias, Switzerland
twitter: @sergehuber 


JahiaOne , our international user conference
is back! June 10-12 in Paris - Grab your tickets now
!

Jahia is a leading open source User eXperience Platform (UXP) vendor,
relentlessly working at transforming a siloed industry into a
user-driven one, beyond technology constraints - http://www.jahia.com



On Sat, Apr 18, 2015 at 10:47 AM, James Carman
mailto:ja...@carmanconsulting.com>> wrote:

Serge,

We had some pretty good discussions during JB's talk (hope we
didn't hijack it too much, JB).  I don't think this topic really
has anything to do with Dock