In regards to camelwatch,
I am having the same issue as James building camelwatch due to the new
dependency on the jmxc library.
It seems as though in a recent update, sksamual has added a new dependency
on https://github.com/sksamuel/jmxc. When I try to build jmxc library I
get some scala
On 25 January 2013 22:23, Raul Kripalani wrote:
> So if the reason for trashing the console out of the Camel code base is the
> proven lack of development focus on it, I wonder if it'd make sense to
> contact the person behind the camelwatch project to ask if he'd be willing
> to contribute it to
+1 for removing it completely.
As Hadrian said, we (the Camel project itself) should focus on the server
side technology that we do so well.
Other projects like Karaf WebConsole, Hawt.io, Camelwatch, ... are better
places to provide this kind of management functionality via a
gui/console/... Afte
+1 to remove the web console for Camel 3.0 (option #2)
On 2013-01-25 8:14 PM, "Hadrian Zbarcea" wrote:
> I'd keep this thread short and focus on achieving consensus (if possible)
> on what to do with the existing console. So far it looks to me like there
> is (almost(*)) consensus on not having t
I am also +1 to remove it.
Christian
Am 26.01.2013 00:43, schrieb Hadrian Zbarcea:
I'd keep this thread short and focus on achieving consensus (if
possible) on what to do with the existing console. So far it looks to
me like there is (almost(*)) consensus on not having the console part
of the
On Fri, Jan 25, 2013 at 5:57 PM, Hadrian Zbarcea wrote:
> In the context of a few web based consoles available for Camel, including
> the Karaf console and the recently announced hawt.io, the question of if
> Camel needs its own console popped up.
>
> My understanding is the some are in favor or C
Either or, I prefer 2 but sandbox might be a good idea.
On Jan 25, 2013, at 16:43, Hadrian Zbarcea wrote:
> I'd keep this thread short and focus on achieving consensus (if possible) on
> what to do with the existing console. So far it looks to me like there is
> (almost(*)) consensus on not ha
I'd keep this thread short and focus on achieving consensus (if
possible) on what to do with the existing console. So far it looks to me
like there is (almost(*)) consensus on not having the console part of
the camel distro.
The contenders are:
1. James proposal to move it to the sandbox (as a
I think even both may be possible. We could have plugins for apache
projects that are written inside the projects or outside. Depending on
the interest of a project to build such a plugin and the feasibility to
develop it independent of the project release cycle.
The core part of my idea is th
On the other hand, if the plugin is developped outside the Camel project,
it could be written to support multiple camel versions at the same time,
especially older versions. Which might be harder (though not impossible)
if hosted inside camel project itself.
On Fri, Jan 25, 2013 at 11:36 PM, Chr
I think it makes sense to trash the current console at some point.
On the other hand I think we need a good replacement. As the camel
management APIs evolve over time I think it makes sense to develop the
camel specific parts of a management console in the camel project.
What I would like to
So if the reason for trashing the console out of the Camel code base is the
proven lack of development focus on it, I wonder if it'd make sense to
contact the person behind the camelwatch project to ask if he'd be willing
to contribute it to ASF.
Fair enough it's not the slickest UI, but maybe he'
I have to agree with the idea of removing it completely. There are a couple
good consoles out there that are better than what we have and maintained by
people/communities that are better equipped to maintain ui things. I'd say
let the users find the one that fits their needs best.
Dan
O
I don't hink Hadrian said that a console has no value, just that the one
Camel has is not the best one and that it may be moved away and encourage
people to try and use other consoles.
On Fri, Jan 25, 2013 at 6:06 PM, Charles Moulliard wrote:
> Hi Hadrian,
>
> Camel is not only a serve side tec
Hi Hadrian,
Camel is not only a serve side technology and the added value of a web
console makes a lot sense regarding endpoint definition/declaration, routes
created / camelContext and certainly for tons of others reasons that I
could not explain here. You cannot imagine How helpful it is when we
I'm in favour of removing the console completely, for the reasons you' d
outlined.
On 25 Jan 2013, at 16:57, Hadrian Zbarcea wrote:
> In the context of a few web based consoles available for Camel, including the
> Karaf console and the recently announced hawt.io, the question of if Camel
> ne
I'd be in favour of moving it to a sandbox so folks can tinker with it
if they want.
On 25 January 2013 16:57, Hadrian Zbarcea wrote:
> In the context of a few web based consoles available for Camel, including
> the Karaf console and the recently announced hawt.io, the question of if
> Camel need
17 matches
Mail list logo
