Fixed the msv issue and hit another one. Looks like the
apache-cxf-2.6.6-features.xml [1] is invalid: ${cxf.james.mim4j.version}
is not resolved :(.
This looks like the only issue that remains to workaround. I'll try to
build the releases over the weekend.
Cheers,
Hadrian
[1]
http://repo1.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello *,
in order to continue my work on the LDAP component
(https://issues.apache.org/jira/browse/CAMEL-5817), I need a permission
to edit the wiki and an svn account. My JIRA/Confluence account is
leonid.kof
My ICLA is already received by the ASF,
> Hiram:
> How about if we can get at least 3 committers to agree to help maintain the
> component then it should get accepted.
Maybe instead we could establish a kind of "Scala team" among the
Camel committers? These volunteers could declare that they would
handle Scala-related escalations in th
Hiram, that would be greet indeed.
Fwiw, my comment didn't refer to scala per se, but any component that we
don't have the ability to support ourselves. With java at least I
believe there are quite a few of us who could jump in and fix things,
with scala it's less the case. And socially, what
Tests are failing for me in full builds. I am working on it and will
release asap.
Cheers,
Hadrian
On 02/08/2013 04:21 AM, Claus Ibsen wrote:
On Tue, Feb 5, 2013 at 4:26 AM, Hadrian Zbarcea wrote:
For some reason still not clear to me, my mail client didn't get the
original thread started by
How about if we can get at least 3 committers to agree to help maintain the
component then it should get accepted. I think we should make efforts to
grow the camel community past just Java components if possible.
On Thu, Feb 7, 2013 at 7:51 PM, Willem jiang wrote:
> Putting the components int
GitHub user splatch opened a pull request:
https://github.com/apache/camel/pull/9
CAMEL-6052 Remove dependency on com.sun.script and bump the jython version.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/splatch/camel CAMEL-605
Hi
Looking at the public ClassResolver API (among others) it provides 4 methods
taking over the concrete to be loaded Class type:
http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ClassResolver.html#resolveClass%28java.lang.String,%20java.lang.Class%29
http://camel.apa
On Tue, Feb 5, 2013 at 4:26 AM, Hadrian Zbarcea wrote:
> For some reason still not clear to me, my mail client didn't get the
> original thread started by Claus. That points to consensus that it's time
> for a 2.10.4. I started a full build overnight and I am planning to build
> the 2.10.4 release
> Hadrian:
> We know however from past experience that the community's ability to
> support scala based code was not at par with the rest of the code base.
This is changing. Scala is getting more popular among Java people. And
this trend is visible almost within our community. Year ago I wouldn't
> +1
> Its good to see camel-extra being released.
Until Camel Extra releases are fully synchronized with ASF Camel, we
shall not rest :) .
--
Henryk Konsek
http://henryk-konsek.blogspot.com
On Wed, Jan 23, 2013 at 1:35 PM, Henryk Konsek wrote:
> Hi,
>
> I've just created maintenance branch for Camel Extra 2.10.x. I've also
> merged OSGI imports fix [2] from trunk into it.
>
> I'd like to start process of releasing Camel Extra 2.10.1.
>
> Anybody wants to object?
>
+1
Its good to see
Hi Willem
This is not a good way to cache with strong references and unlimited cache.
We need to use the LRUSoftCache from Camel itself to ensure a upper
cache limit and also using weak references to the class types so we do
not have classloader leaks in dynamic containers.
-1 to this commit. Th
13 matches
Mail list logo
