I already fixed the issue, and ran the prepare release process with JDK6.
The html document can be generated without any trouble.
Please hold you commit to camel-2.12.x until you see the new tag is created.
--
Willem Jiang
Red Hat, Inc.
Web: http://www.redhat.com
Blog: http://willemjiang.blogs
Hello Richard,
I've created a Jira https://issues.apache.org/jira/browse/CAMEL-7231 for
your request. I'll try to look into it later this week.
Kind regards,
Richard Kettelerij
http://richardlog.com
On Wed, Feb 19, 2014 at 4:37 PM, richardgroote wrote:
> Hello,
>
> The org.apache.camel.compon
Yes, working on it.
Hadrian
On 02/20/2014 12:33 PM, Claus Ibsen wrote:
Hi
As 2.11.4 passed. Should we not add some notes on the Camel web site
and announce this release?
The JARs has been synced to maven central.
I assume the ASF mirror sync is done also?
On Wed, Feb 19, 2014 at 4:22 PM, Hadri
Willem, if that problem was so important to you to block a release then
it needs to be fixed. Until it's fixed I will -1 a release. It either is
important or it isn't.
Hadrian
On 02/20/2014 12:26 PM, Willem Jiang wrote:
Hi Dan,
Thanks for the inputs.
The annotation is already RetentionPolic
Hi
As 2.11.4 passed. Should we not add some notes on the Camel web site
and announce this release?
The JARs has been synced to maven central.
I assume the ASF mirror sync is done also?
On Wed, Feb 19, 2014 at 4:22 PM, Hadrian Zbarcea wrote:
> The vote passes with:
> [10] +1 (joed, bvahdat, joed,
Hi Dan,
Thanks for the inputs.
The annotation is already RetentionPolicy.RUNTIME.
Current the html generator is based the APT processor, But it looks like
JDK6 has some trouble to load the APT processor when compile the code, I’m
not sure if I can fix it tomorrow.
At mean while, I suggest we ca
> Oh damn, I thought we just import OSGi API as a dependency :( . I'll
> roll back to previous version and think what we can do without OSGi
> API.
I decided to switch back [1] to the very first version of the OSGi
detection method - analyzing the name of the Camel Context. It is
primitive and sim
> Yes, otherwise non OSGI ppl have class not found exception when
> org.apache.camel.util is loaded.
> So it must be in that sub package if you use osgi imported coded.
Oh damn, I thought we just import OSGi API as a dependency :( . I'll
roll back to previous version and think what we can do witho
On Thu, Feb 20, 2014 at 3:57 PM, Henryk Konsek wrote:
>> -1 to this
>>
>> We cannot have osgi imports in the camel-core source code.
>> This is ONLY allowed in that special osgi sub package.
>
> You mean I can rely on OSGi API only in org.apache.camel.impl.osgi?
>
Yes, otherwise non OSGI ppl have
> -1 to this
>
> We cannot have osgi imports in the camel-core source code.
> This is ONLY allowed in that special osgi sub package.
You mean I can rely on OSGi API only in org.apache.camel.impl.osgi?
--
Henryk Konsek
http://henryk-konsek.blogspot.com
-1 to this
We cannot have osgi imports in the camel-core source code.
This is ONLY allowed in that special osgi sub package.
On Thu, Feb 20, 2014 at 3:39 PM, wrote:
> Repository: camel
> Updated Branches:
> refs/heads/master 9beec7470 -> a42a2ca95
>
>
> [CAMEL-7218] Rely on OSGi FrameworkUti
Hi Willem,
> I will dig the integration test fail issue.
The issue is that Camel Core activator doesn't provide static BundleContext.
Please check out my latest commit
(a42a2ca9542bfb83cf010168aeb8fd82f7b197bf). I changed the
implementation to use OSGi FrameworkUtil instead of classloading
magic
On Feb 20, 2014, at 1:45 AM, Jan Matèrne (jhm) wrote:
>> I'll give it another 12 hours and if nothing changes I will close
>> the vote and release 2.12.3. If within this time you convince another
>> PMC member to change his vote I will cancel this vote.
>
> I am also a fan a building against the
My point is this: if we say that Camel supports 1.6 then it should be
built with 1.6 with the expected results, including the html doc if we
claim that to be part of the release. Otherwise we support 1.6 only for
runtime, which is not what we say actually. I think this has to be
clarified befor
Hi Willem,
> -Class activatorClass =
> classLoader.loadClass("org.apache.camel.osgi.Activator");
> +Class activatorClass =
> classLoader.loadClass("org.apache.camel.impl.osgi.Activator");
Actually switching from org.apache.camel.osgi.Activator to
org.apache.camel.impl.os
AFAIK that vulnerability is inside the built javadoc-html.
Is that generated javadoc part of the release?
I checked
http://apache.openmirror.de/camel/apache-camel/2.12.2/apache-camel-2.12.2.zip
and didnt found any javadoc.
So that wouldnt force the use of Java7.
Jan
> -Ursprüngliche Na
16 matches
Mail list logo
