GitHub user bvahdat opened a pull request:
https://github.com/apache/camel/pull/2501
better make use of Enum#name and Enum#valueof APIs
@punkhorn would you please take a look at this change? thanks.
You can merge this pull request into a Git repository by running:
$ git pull
Hi Christian,
Great & thanks for you support :-)
Don't get into hurry & let's first bring the 2.9.0 final release out the
door (with or without the OSGi features-fix stuff).
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Trunk-Code-Cleanup-tp5071594p5094179.ht
Hi,
As I have already attached the first patch for [1] that would be great if a
commiter would assist me on
this ticket for applying the gradual patches into the trunk one after the
other.
As soon as this first patch is applied I will update my workspace and dig
into the "next round".
[1] https:
Hi Aliosha,
I assume you're in the wrong forum and should better make use of [1] to
solve your problem as
you make use of ServiceMix ESB & JBI-Container as such and the issue you're
encountering has
nothing to do with Apache Camel. Maybe [2] can also better clarify the
comparision between
ServiceM
Hadrian,
Currently there's 8348 *Test.java classes on the trunk, so that finding all
those empty or overlapping tests would be (at least to me) really a tough
challenging task, so that I propose to keep with the context of this
clean-up activity as radical as possible.
Babak
--
View this message
Hi,
I created a ticket [1] for tracking this issue.
[1] https://issues.apache.org/jira/browse/CAMEL-4796
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/DISCUSS-Trunk-Code-Cleanup-tp5071594p5085730.html
Sent from the Camel Development mailing list archive at Nabble.com
Hadrian,
Let me try to explain what the problem I claim to be there:
We assume that the vote will pass and you will promote/copy the staging repo
content to the central repo and announce the release officially on the Wiki
& maybe even on the User-Forum, right?
Now as an example through the revis
Hi,
In the context of the tickets below (Fix Version 2.9.0 in JIRA), I see
changes made on the trunk which are to be already included by the 2.9.0
final release (but all are *after* the release today @ 15.12.11 05:12 by
Hadrian, see [1]).
https://issues.apache.org/jira/browse/CAMEL-4777
https://
Hi Christian,
> May you can start with this after we released Camel 2.9.0 and split the
> work into multiple, not so huge patches, e.g. one issue per point on your
> list.
Yeah, exactly. Instead of attaching a single huge diff on the ticket I
intend to do it gradually (for example one patch for e
Hi Claus,
Thanks for your feedback.
>> For example changing/adding serial version UUID would break backwards
>> comp. So IMHO only to be done on the 2.10 release. etc
I did already agree with your proposal by my original post:
>> BTW, my intention is *not* to force this into the 2.9.0 final rel
Hi again,
I already messed it up with the provided links in the botom of my previous
post, so here a second try:
Hi Devs,
As Claus has already once stated [1] thanks to my own professionalism I
intend to take over the trunk code-clean-up activity :-)
This task (at least to the main extend) can
[DISCUSS] Trunk-Cleanup
Hi Devs,
As Claus has already once stated [1] thanks to my own professionalism I
intend to take over the trunk code-clean-up activity :-)
This task (at least to the main extend) can be of course achieved in an
(almost) automated manner (*even* eclipse can do that!), which
Hi Claus,
> Thanks Dan.
> The svn ignore is not back to normal for IDEA users.
just because of my curiosity. Does it work now for you or do you still have
the same problem?
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/The-big-svn-ignore-commit-tp5044135p5067974.h
Just as an idea:
Could [1] be also relevant for this issue as well? I hit a bunch of "h3"
html tags just before those lines with:
Error formatting macro: snippet: java.lang.IndexOutOfBoundsException: Index:
20, Size: 20
[1] https://studio.plugins.atlassian.com/browse/NUMHEAD-26
Babak
--
View t
Claus,
Not sure if [1] is really related but just for any case. However I see your
point: it used to work before that script run so that you expect it to still
work *even* after that run.
My apologies beforehand as I was the guilty one who started discussing [2]
this.
[1] http://youtrack.jetbrai
Your second script-run beforehand today seems still to be O.K. on
eclipse/subclipse for me (0 outgoing-changes), hope it'll be the same for
the IDEA users as well.
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/The-big-svn-ignore-commit-tp5044135p5049254.html
Sent from
Hi Christian,
I assume in Apache Camel we deal with URIs in general and not URLs in
particular, so that the following line of code
new URI("jetty:http://camel.com:1099/service";);
doesn't throw any URISyntaxException on my box. As the scheme is "jetty" &
the scheme-specific part of it is
Hi,
For me the issue on eclipse was actually already resolved through your
svn:ignore commit on the trunk even before this commit, see [1].
Completely another point:
IMHO I assume because of the same regular expression inspiration by svn, we
used to have the issue [2] caused by maven. I think the
FYI, with the revisions that Willem & Claus [1] have already commited the
issue seems to be resolved, so that while synchronizing with the trunk
(subclipse in eclipse) happily I see 0 outgoing-changes.
But maybe you still want to double check it.
[1] http://svn.apache.org/viewvc?view=revision&rev
@Dan,
did you have a chance to give that CXF script a try?
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/The-svn-ignore-property-isn-t-settled-down-on-trunk-tp5035110p5041830.html
Sent from the Camel Development mailing list archive at Nabble.com.
Hi Willem,
Thanks a lot for that quick fix.
IMHO the best would be if we could consistently overcontrol the ignore list
as the following so that the rules apply for *all* of us no matter what the
client we use:
- for svn dummies (like me) through the svn:ignore property of each given
folder belo
Hi Devs,
That would be great if some committer would update the svn:ignore property
on the trunk (as an example camel-jclouds/target folder is considered as an
outgoing-change on my IDE, or .classpath & .project by some other camel
components).
IMHO this would make life easier for the commiters (
Hi Bilgin,
had a chance to look at your camel-cmis component (BTW another nice code of
yours). I'm a newbie to JSR-283 and don't know much about it's API, however
probably I'm going to be involved in a Sharepoint-Integration project and
that would be really cool if I could just kick the Sharepoint
O.K. I reflected my findings [1] regarding the manual issue I mentioned by
this thread today and would appreciate any feedback/thoughts...
[1] https://issues.apache.org/jira/browse/CAMEL-3774
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Release-Camel-2-8-3-the-s
O.K. just realized that the issue is already known:
https://issues.apache.org/jira/browse/CAMEL-4284
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Release-Camel-2-8-3-the-second-try-tp5002990p5016078.html
Sent from the Camel Development mailing list archive at Nab
Hi,
downloading from a swiss mirror also worked for me, however looking at the
html:
doc/manual/camel-manual-2.8.3.html
the content is:
Download of http://camel.apache.org/book-in-one-page.html
failed
The ending tag is missing and I'm not sure if this body content was
really "on purpose". S
Great! now the referee on the Wiki [1] is also up-to-date as well.
[1] https://cwiki.apache.org/confluence/display/CAMEL/Building (@ the line
"You can also find some helpful notes on usage here." )
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-failure-on-tru
Hi Jon,
Thanks a lot for your commitment on this and bringing that behaviour back
into the play.
Other than this I've got another concern which I would really appreciate if
you could take a look at:
As you can see in [1] the links on your old blog entry seem to point to
out-dated eclipse templat
Hi
looking at the build of this morning [1] the test failure issue is now
fixed, however like Willem I think the pre-existing fail-fast behaviour
should be brought back as it used to be there. This however would require
another JIRA-Ticket than [2] having the corresponding description / goal.
[1]
So that by [1] I simply mimicked the same changes done on unit-tests by [2]
[1] https://issues.apache.org/jira/browse/CAMEL-4700
[2] https://issues.apache.org/jira/browse/CAMEL-4689
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-sax
Hi Willem,
completely agree on your proposal, and looking at the changes on the
existing unit-tests by [1], that's [2] & [3] that "fail-fast" behaviour
seems to be gone away.
[1] http://svn.apache.org/viewvc?rev=1202819&view=rev
[2]
http://svn.apache.org/viewvc/camel/trunk/camel-core/src/test/jav
Hi,
https://issues.apache.org/jira/browse/CAMEL-4700
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/Unit-test-failure-on-trunk-in-camel-saxon-tp5009713p5010536.html
Sent from the Camel Development mailing list archive at Nabble.com.
So here is my word Claus asked for (I know it's too early, sorry for that):
I gave a spin test with just only one of the apps of mine, and here my 2
cents:
CamelTestSupport's context, template, consumer, etc. fields are *not* static
anymore through the revision [1]. So using them in a static cont
Hi Claus,
I also mentioned the issue here:
http://camel.465427.n5.nabble.com/svn-commit-r1170542-in-camel-trunk-camel-core-src-main-java-org-apache-camel-api-camel-core-src-main-tp4802422p4802513.html
But for some reasons not clear to me, my mail didn't get accepted on the
mailing list...
Regar
How stupid of me! Just realized that you've already kicked off a full test
run by today...
Sorry!
--
View this message in context:
http://camel.465427.n5.nabble.com/Compilation-error-on-trunk-on-windows-on-Apache-Jenkins-tp4791051p4798522.html
Sent from the Camel Development mailing list archive
Hi Claus,
Unfortunately your last full test on windows missed the bug fix below which
caused some tests on "camel-jms" & "camel-stream" to fail:
http://svn.apache.org/viewvc?view=revision&revision=1169732
IMHO the newly introduced "retry up to 5 times logic" in
TestSupport.deleteDirectory() doe
Hi Claus,
Having the following setup on my windows box, I couldn't reproduce the
compliation error:
c:\dev\workspace\camel>mvn --version
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: c:\dev\apache-maven-3.0.3\bin\..
Java version: 1.6.0_26, vendor: Sun Microsystems Inc.
Java
Hi All,
the use-case Claus gave as an example in his last post indeed happened today
morning with my client to whom I've provided the application (running stable
since July 27th with camel 2.8.0 in the production).
I wanted to give a try to the snapshot build of today morning at [1], and
followin
Like the one here:
http://svn.apache.org/viewvc?view=revision&revision=1159323
@Christian please don't blame me posting here as I simply couldn't stop
myself commenting on this.
--
View this message in context:
http://camel.465427.n5.nabble.com/HEADS-UP-Adjustments-to-ExecutorServiceManager-on-t
Hi Claus,
Sorry for my late response Am currently pretty busy
Created the ticket and provided a patch for it. Actually I went one step
forward regarding this issue to resolve it on other test cases as well. So
please verify/check the delivered patch if it makes sense to you in all
cases:
https
Hi Claus,
IMHO and with ALL my respect, I would never use the hard-coded
unix-line-delimiter "\n", but would ALWAYS use the
System.getProperty("line.separator"), so that I'm on the safe side no matter
on which platform I'm running. That's "\r\n" on windows, "\n" on unix and
"\r" on mac.
The probl
There's only 2404 warnings left See the first 100 here:
http://camel.465427.n5.nabble.com/file/n4600069/warnings.jpeg warnings.jpeg
.
Just wonder if IDEA doesn't warn about these stuff, for example the raw type
declaration of a given generic type
Regards, Babak
--
View this message in context
Got it!
The problem with the TypeConverter by me was just a side effect of the
following fix:
https://issues.apache.org/jira/browse/CAMEL-3974
So that the webservice-reply was simply not propagated into the exchange's
out, The following diff says it all:
http://camel.465427.n5.nabble.com/file/n
[-1]
as the TypeConverter/@Converter stuff doesn't work, even in a NON-OSGI
environment, at least for me, see my comments here:
http://camel.465427.n5.nabble.com/Some-indication-on-when-2-8-0-could-be-released-td4585340.html
Just upgrading the maven dependency in my multi-module project from 2.7
44 matches
Mail list logo
