Thanks a lot beforehand for the hint! I assume you mean the lines like:
// must do this ugly cast to avoid compiler error on AIX/HP-UX
ProcessorDefinition defn = (ProcessorDefinition) this;
which I carefully tried to skip by all the provided patches, however IMHO
*if* we reach the level of an app
On Thu, Jan 19, 2012 at 4:43 PM, Babak Vahdat
wrote:
> Hi,
>
> Through [1] & [2] the issues being mentioned by this thread have been
> already resolved. Before beginning of this activity
> I used to see 1991 compiler warnings, however right now only 310 are left,
> mostly because of the raw type r
Hi,
Through [1] & [2] the issues being mentioned by this thread have been
already resolved. Before beginning of this activity
I used to see 1991 compiler warnings, however right now only 310 are left,
mostly because of the raw type references to the
generic type ProcessorDefinition whose fixing wo
On 12 January 2012 15:57, Hadrian Zbarcea wrote:
> I realized and changed my comment. In my defense (I know I have none) both
> your names start with a 'B' are roughly the same lenght (5-6 chars) and you
> Babak threw so many small patches at us lately that you made my head spin.
> I'll get on the
I realized and changed my comment. In my defense (I know I have none)
both your names start with a 'B' are roughly the same lenght (5-6 chars)
and you Babak threw so many small patches at us lately that you made my
head spin. I'll get on the rawtypes patch now.
Bilgin, I don't know how I can c
Hi Hadrian,
as you've already realized the patch [1] was provided by Bilgin and not me
(you welcome :-)).
However I would have also something to be applied into the trunk as well [2]
just in case you've got some spare time for verification and applying it.
Thanks!
[1] http://svn.apache.org/view
Hi
FYI I've extended the scope of [1] to also include:
- Avoidance of the raw type declarations by the generified classes *as much
as possible*
This will be a *manual* Refactoring step as I'm not aware of any automated
way for doing it.
[1] https://issues.apache.org/jira/browse/CAMEL-4796
Baba
Hi,
FYI I've explicified the *exact* scope of [1] through it's Description
Field.
[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-tp5071594p5097317.html
Sent from the Camel Development mail
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
Hey Babak,
I will do it. I'm a bit busy at present because we are releasing Camel
2.9.0 and facing a few problems. Give me a few days...
Christian
Sent from a mobile device
Am 22.12.2011 09:33 schrieb "bvahdat" :
> Hi,
>
> As I have already attached the first patch for [1] that would be great if
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:
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
There are a bunch of tests that actually don't test anything or overlap
with other tests. It would be good to remove them.
Hadrian
On 12/19/2011 05:50 AM, bvahdat wrote:
Hi,
I created a ticket [1] for tracking this issue.
[1] https://issues.apache.org/jira/browse/CAMEL-4796
Babak
--
View
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
This is great initiative Babak, thanks.
I have also started some code cleanup activity on my own for the 528
critical violations reported on Camel Sonar, but didn't go too far for
now.
Bilgin
On 14 December 2011 19:36, bvahdat wrote:
> Hi Christian,
>
>> May you can start with this after we rel
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
I agree, this is something "un-sexy" stuff we have to look into. The better
someone take the stab on this.
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.
Best,
Christian
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 Babak
Nice you got attention on these details as well.
After the 2.9.0 release we could take a look what makes sense.
For example changing/adding serial version UUID would break backwards comp.
So IMHO only to be done on the 2.10 release. etc
On Tue, Dec 13, 2011 at 3:48 PM, bvahdat wrot
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
20 matches
Mail list logo
