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
The Apache Jenkins build system has built Camel.trunk.notest (build #1773)
Status: Fixed
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1773/
to view the results.
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
Hi
After the upgrade to Scala 2.10 the build on the CI-Server failed as
apparently it's maven plugin requires minimum Maven 3.0.4+.
https://builds.apache.org/job/Camel.trunk.notest/1772/console
However we can't make use of Maven 3.0.4 because of the old issue we have
had with the camel-msv modul
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
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 Camel continuing to ship
with a web console. My personal opinio
It is certainly possible, but there are no plans for that at this time.
Contributions are welcome though, if somebody feels strongly about it.
You can also ask and get some help from the community.
Camel is essentially a java technology, runs on the jvm. That is why it
integrates well with lan
On Fri, Jan 25, 2013 at 11:58 AM, pratik_patel
wrote:
> Hi,
>
> Is there any plan to support Lua in Camel in near future?
>
Hi
I am not familiar with Lua.
Can you share more details what that is? A link to its web site would
be handy as well.
And what kind of support/integration are you looking
I think one of the most interesting part of hawtio is that the same console
can be used in OSGi or in a non-OSGi environment and that's is pluggable
with dynamic discovery. That's really what we needed for years, back to
the ServiceMix 4 early stage.
Having a single console that can adapt multiple
Hi Kai and Willem
I have it in my private git repo, but I shall extricate the relevant packages
from my project and put it on github over the weekend.
An additional issue might be that I used SBT (0.12.2) whilst your build
environment is Maven. Not too much effort to change that though.
Regards
I
Hi Claus
Yes it is generic Stomp. I did all the testing against Apollo though - will run
the tests against ActiveMQ later today and let you know.
Regards
Ian
On 25 Jan 2013, at 9:14 AM, "Claus Ibsen-2 [via Camel]"
wrote:
> On Thu, Jan 24, 2013 at 1:20 PM, iandebeer <[hidden email]> wrote:
> >
- Will check more in depth next week hawt.io and have a look to your
remarks.
- For sure, hawt.io should be the house about camel webconsole and I would
appreciate that everybody fully agree about that idea instead of
continuying to re-invent new webconsole every next major realease of Camel.
- Per
On 25 January 2013 08:07, Charles Moulliard wrote:
> +1 for the project plan and if you are interested I can play the role of
> Project Manager to coordinate all the different tasks, actions, define a
> plan and
> following
> manage it
>
> Concerning the webconsole, http://hawt.io project should b
+1 for the project plan and if you are interested I can play the role of
Project Manager to coordinate all the different tasks, actions, define a
plan and
following
manage it
Concerning the webconsole, http://hawt.io project should be the way to go
(or at least jolokia - http://jolokia.org/ ) even
22 matches
Mail list logo
