The Apache Jenkins build system has built Camel.trunk.notest (build #1799)
Status: Failure
Check console output at https://builds.apache.org/job/Camel.trunk.notest/1799/
to view the results.
I think multiple DSL suppport is most important feature for Camel, as our
competitor just only support one or none of them.
We got the some complains from the user that why does the Java DSL work, but
the Spring DSL doesn't work. They treat it a bug not a small syntactic failure.
It could be
Looks like I have some problem uploading the artifacts during
release:perform. I may have to redo this release.
Thanks for the patience,
Hadrian
On 02/19/2013 02:53 PM, Christian Müller wrote:
Thanks for the update!
Sent from a mobile device
Am 19.02.2013 06:48 schrieb "Hadrian Zbarcea" :
T
I strongly disagree. On what are you basing your "MUST" statement?
There are 2 areas in which camel excels: one is the middleware
abstraction, via the api. The second is the runtime mediation. The dsl
has nothing to do with either, it's just syntactic sugar, eye candy. I
don't deny that it's h
Good to see a very active discussion...
But is there a reason I'm not familiar with that this MUST be done in Camel
3.0? I don't think so...
I would like to add this topic to the Camel road map page [1] for Camel 3.x
(after Camel 3.0) and postpone the discussion to a time where the
development for
Over 30 messages in the thread. Now I feel like real Internet Troll [1] :P
Anyway thank you all for expressing your views in the regards of
components maintenance. It's good to see how others perceive the
future of the components in Camel. Any further input is welcome.
[1] http://en.wikipedia.org
Am 20.02.2013 um 16:22 schrieb Henryk Konsek :
>> But aren't there situations today where people might not be able to update
>> camel?
>
> These situations are minor ones comparing to the size of
> incompatibility that will be caused by introducing components not
> supported by the committers
> But aren't there situations today where people might not be able to update
> camel?
These situations are minor ones comparing to the size of
incompatibility that will be caused by introducing components not
supported by the committers team.
> No need to stop working on select components and ei
> The quality would be in the responsibility of the owner.
Code ownership doesn't play well with the quality of the open source
code. Let's face it - the components without the organized care from
the committers team will be lousy. The existing components released
from the ASF umbrella will degrad
>
>
>> Maruan:
>> you nailed it. The idea of the marketplace is to give up responsibility.
>> Apache Camel is responsible for the
>> foundation (software, infrastructure, procedures). The component developer
>> has
>> responsibility for the component.
>
> If we follow this path, we will end u
Isn't this whole situation similar to the Apache Web Server project and their
plugins? How do they do it?
On Feb 20, 2013, at 9:16 AM, Christian Schneider
wrote:
> Am 20.02.2013 14:26, schrieb Raul Kripalani:
>> I'm thinking about the organisation strategy here. Below is a list of a few
>>
Am 20.02.2013 14:53, schrieb Henryk Konsek:
Christian:
1. Each component release needs a vote. So with the 100+ components we would
have 100 votes instead of one vote for a camel release.
CR-01 release of all components would be performed together with core.
Component releases higher than CR-01
hi - although I didn't think about all implications please find some comments
below.
As I'm new to Apache Camel I might not be in the position to provide all these
suggestions and ideas. If I unintentionally step on someones toes please
forgive me :-)
Maruan Sahyoun
Am 20.02.2013 um 14:26 sch
Am 20.02.2013 14:26, schrieb Raul Kripalani:
I'm thinking about the organisation strategy here. Below is a list of a few
practical issues off the top of my head. For the people supporting the the
marketplace idea, could you elaborate on how we'd handle these?
- Would marketplace components b
> Christian:
> 1. Each component release needs a vote. So with the 100+ components we would
> have 100 votes instead of one vote for a camel release.
CR-01 release of all components would be performed together with core.
Component releases higher than CR-01 would be performed seldom,
usually on ex
I'm thinking about the organisation strategy here. Below is a list of a few
practical issues off the top of my head. For the people supporting the the
marketplace idea, could you elaborate on how we'd handle these?
- Would marketplace components be sponsored/owned by committers only, or
anyo
I also think it would be a good idea to concentrate on core and a few
important components. The sheer number of components got a little out of
control recently.
So for example we could keep the 10 or 20 most important components in
camel and move the rest out to a marketplace.
Christian
Am 20
Maruan,
Actually I think you're spot on, and I shared some of these thoughts for
a good while. I believe it's just a matter of time for others to reach
the same conclusion.
My $0.02,
Hadrian
On 02/20/2013 05:37 AM, Maruan Sahyoun wrote:
well IMHO this would also address the release lifecycl
well IMHO this would also address the release lifecycle question. That part of
the discussion initiated the idea. If there are enough people around to
maintain the components that's great. On the other hand are there also enough
people around to move Camel 3.0 forward AND maintain all components
Hi,
I don't think a marketplace and surrendering responsibility of components
helps solve the problem we are discussing.
We don't have an ownership/responsibility/authorship issue: it's a release
lifecycle discussion. How do we deliver component fixes to the community
quickly? Surrendering them d
you nailed it. The idea of the marketplace is to give up responsibility. Apache
Camel is responsible for the foundation (software, infrastructure, procedures).
The component developer has responsibility for the component.
Maruan Sahyoun
Am 20.02.2013 um 10:19 schrieb Christian Schneider :
> T
The idea of a common process and rules but separate owners for the
components sounds good. We would have to discuss / agree on the details
of course. This would then of course also imply that the camel community
would not officially support the marketplace components. So rather each
component would
a discussion/decision how to handle components is independent of a stable and
thin core. I mentioned it only to have the 'layers' complete. The points you
are making are very valid and as has been proven by others they can be
addressed. What I wanted to introduce is the idea of not being respons
Hi Maruan,
I agree with the goals you defined.
A stable and thin core would be great. The problem is that core is not
really thin at the moment. So I think we need to do at least one release
with breaking changes before we can then have a stable and thin core.
The idea of a component marketp
Hi,
Apache Camel is the victim of it's own success here. It's easy to build new
components and people are encouraged to do so. This leads to the large amount
of components available and their number will grow.
IMHO the focus should be on
o a stable, thin core.
o a good component model
o some c
25 matches
Mail list logo
