Re: Getting ready for Apache Camel 2.18 Release

[Andrea Cosentino]

The docs now are completed. The last four languages were added.
 --
Andrea Cosentino 
--
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1...@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Sunday, August 28, 2016 11:29 AM, Claus Ibsen  wrote:
Hi

Hope everybody had good summer vacation. I had my vacation in parts
and have next week as PTO.

We should get started to close down on the upcoming Camel 2.18 release.


There is some outstanding work (in no particular order)

1)
Finish the spring boot stuff with the starter components.
Nicola comes back from PTO and will work on this.

2)
rest-dsl to support calling REST services. I am working on this and
have some outstanding work still around binding and other
improvements.

3)
Tidy up the log4j v2 upgrade. Some of the examples do not start with
the jetty plugin.

4)
Migrate the last wiki pages to adoc files. There is not so many pages
left and you can find a report when running camel-catalog build that
output what is missing.

This will help us with a base-line for maintaining the documentation
going forward in the source code adoc files instead of wiki, and we
can then generate a new website and documentation for the following
release (2.19 or 3.0) etc. But this is a discussion we should IMHO
take post 2.18.

5)
camel-test-karaf module. This module is in the works but could use
some review and finishing so its easier to use for end users.

Notice the existing camel-test-blueprint is still favored for doing
unit tests which you can run fast and easily debug. The new
camel-test-karaf is for running integration tests in a running karaf
instance.

6)
We should look at the JIRA tickets that are assigned to 2.18.0 and try
to fix / implement them, or move them to 2.18.1 or 2.19.0 for next
releases.

7)
Keep an eye on the CI server to make sure the tests are green.
https://builds.apache.org/view/A-D/view/Camel/


If all goes well then hopefully in 2-3 weeks we are ready to cut the 2.18.0 RC.




-- 
Claus Ibsen
-
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

[GitHub] camel pull request #1164: CAMEL-10222: New spring-boot BOM

[nicolaferraro]

GitHub user nicolaferraro opened a pull request:

https://github.com/apache/camel/pull/1164

CAMEL-10222: New spring-boot BOM

I tried to run the integration tests (including the unit test part of each 
module) using the starters only, but I found out that a mixture of spring-boot 
dependencies and camel dependencies produce wrong classpaths, i.e. classpaths 
that include different versions of jetty-core and jetty-util-xxx (9.3 and 9.2). 
the same happens with submodules of activemq, hibernate, jackson and others.

Using Jetty 9.3 (the version supported by spring-boot) instead of the 9.2 
has some advantages in that users can possibly use other sb-compatible 
libraries in their applications.
The camel-jetty9 component had two issues with Jetty 9.3 (broken HTTPS 
support and a changed method signature). I solved both.

Being able to always use Netty 4.15 (same for sb and camel) would be also 
great. Unfortunately some modules (the one dependent on asynchttpclient) still 
need to work with Netty 4.0.x.
Netty will not be part of the BOM.

This means that, in order to use a component, people just need to add the 
starter to the application's pom, but if they include more starters, in some 
(hopefully rare) circumstances, the application will not work (just because two 
different versions of the same class cannot be present in a standard java 
classpath).

I evaluated different options before creating the final BOM:

1)
A BOM with lower precedence over the spring-boot BOM (this bom would simply 
be included by the users AFTER the spring-boot BOM declaration in their 
applications)

Drawbacks:
- Some modules require specific versions of some libraries. Eg. Spring-boot 
uses the cassandra v2 driver, while our component requires version 3. Cannot 
override it with a BOM with lower precedence.
- In general, there's no way to force a specific camel version for a 
particular library if spring-boot provides its own in the BOM (another example 
is activeMQ)

2)
A BOM with higher precedence over the spring-boot one

Drawbacks:
- Problems with gson and other libraries. Some of our modules use different 
versions of gson, so it should simply be excluded from the BOM and included in 
each starter
- If spring-boot adds eg. google guava in the future we will have more 
issues

3)
A brand new BOM, that includes all SAFE dependencies of the spring-boot BOM 
and then all safe dependencies of Camel parent.

Drawbacks:
- The user must use the org.apache.camel:camel-spring-boot-dependencies 
instead of the org.springframework.boot:spring-boot-dependencies
- Switching to a different version of spring-boot may be difficult (but 
many components would not work out of the box)

Advantages:
- Possibility to change any user dependency in the future (to fix issues)
- Possibility to choose camel versions over spring-boot versions and 
vice-versa
- Auto-generated from a reduced set of rules


I implemented the 3rd choice.
I also provided a separate camel-starter-parent to be able to change the 
libraries included in the starters without affecting the user BOM.

To create the full BOM I created a generator: a simple maven plugin that 
produces a flattened pom.xml file from information contained in a generator 
project, using inclusion/exclusion rules.
I had to put a small set (~20) of version numbers in a separate 
(camel-spring-boot-dm/pom.xml) file. The versions belonging to camel-parent 
should be aligned when the corresponding entry is changed.

I changed the integration tests to use the new structure:
- No module is failing when included in a spring-boot application (at 
least... before the rebase :D)
- Some modules (<20 / 220) are failing when running the unit tests from the 
integration framework. Many problems are simply related to the testing tool 
(it's difficult to make it stable). I'll investigate and correct real issues, 
if any.


I fixed many problems either by changing the starter's pom or changing the 
BOM, so now we have a more powerful tool for choosing the right libraries to 
include in the user apps.
Also, non-spring-boot users (eg. Karaf) are not impacted by the changes.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nicolaferraro/camel CAMEL-10222-P2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/camel/pull/1164.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1164


commit 9914a683e0cd894b10c02250e33364681fc41753
Author: Nicola Ferraro 
Date:   2016-09-01T10:41:55Z

CAMEL-10222: Fixed some poms up to HBase

commit f5060038ae0167da3e87599c9fc6b01e1449cb7e
Author: Nicola Ferraro 
Date:   2

Re: building camel code (init eclipse workspace)

[fabryprog]

Thanks a lot claus!!!



--
View this message in context: 
http://camel.465427.n5.nabble.com/building-camel-code-init-eclipse-workspace-tp5787394p5787425.html
Sent from the Camel Development mailing list archive at Nabble.com.

Re: Getting ready for Apache Camel 2.18 Release

[Quinn Stevenson]

Thanks for taking a look at the PR Thomas - I really appreciate the feedback.

1) The parent pom was wrong because I created this PR before the change from 
2.18-SNAPSHOT to 2.18.0-SNAPSHOT took place - it’s been out there a while
2) My bad on the READMEmd - you can probably tell where I copied the example 
from to get started :-).  I’ll get working on that to clean it up
3)  I really struggled with this - what example to use.  I thought a little 
about replacing JMS with something else, but I wasn’t quite sure what to use.  
It gets a little more complicated because of the two JVMs (one for Karaf and 
one for the bootstrap code).  Anyway, if you have a “good” test route and what 
you’d like to see happen for testing, I’d really like to see it and I’ll try 
and use that instead.
4)  I’m not sure where I came up with the name of the example - but you’re 
right - I’ll change it to example-camel-test-karaf
5) I’ll get back in and figure out why the integration test is failing now - I 
was certain they were working at one time.  Anyway, the unit tests pass - but 
they generate a bunch of scary messages in the log files.  I didn’t see this 
stuff when I was using the class I derived CamelKarafTestSupport from.  If you 
have any ideas on how to clean those up, I’d really like to hear them.

I’ve got one other bug to fix, then I’ll get back on this one.  

If you wouldn’t mind “watching” the JIRA for this 
(https://issues.apache.org/jira/browse/CAMEL-6132 
), we can communicate there 
(rather than spam the DEV list).

Thanks Again


> On Sep 8, 2016, at 11:09 AM, Walzer, Thomas  
> wrote:
> 
> Hi, Quinn,
> 
> I took a look at PR987:
> 
> 1) the parent pom should be something like 2.18.0 not 2.18 (maybe the PR was 
> around too long, so the parent changed).
> 2) The readme really needs some love. It mentions spring when there is really 
> blueprint; jms, when there is none, etc.
> 3) for me an example replacing/redefining jms: or activemq: by seda: would 
> really make a difference. Like having a jms-definitions-bp.xml and then 
> replacing it by seda-definitions-bp.xml, or something like that. I know 
> that´s not the point of your sample but the timer-example seems a bit basic. 
> 4) maybe …-test-karaf would be a better name?
> 5) my unit tests and itests do not run through. If they would I could provide 
> more fleshy feedback.
> 
> If I can help, let me know.
> 
> Cheers, Thomas.
> 
> ---
> T E S T S
> ---
> Running org.apache.camel.BlueprintBeanPropertiesOverrideFromFileTest
> Unable to start bundle: org.apache.felix.gogo.runtime [64]
> org.osgi.framework.BundleException: Unable to start bundle
>   at org.apache.felix.connect.PojoSRBundle.start(PojoSRBundle.java:163)
>   at org.apache.felix.connect.PojoSR.startBundles(PojoSR.java:304)
>   at org.apache.felix.connect.PojoSR.(PojoSR.java:248)
>   at org.apache.felix.connect.PojoSR.(PojoSR.java:129)
>   at 
> org.apache.felix.connect.PojoServiceRegistryFactoryImpl.newPojoServiceRegistry(PojoServiceRegistryFactoryImpl.java:52)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.createBundleContext(CamelBlueprintHelper.java:173)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintHelper.createBundleContext(CamelBlueprintHelper.java:119)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.createBundleContext(CamelBlueprintTestSupport.java:127)
>   at 
> org.apache.camel.test.blueprint.CamelBlueprintTestSupport.setUp(CamelBlueprintTestSupport.java:241)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(Paren

[GitHub] camel pull request #1163: CAMEL-10298: Remove readLockTimeout check from rea...

[yuruki]

Github user yuruki closed the pull request at:

https://github.com/apache/camel/pull/1163


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Camel.trunk.notest - Build # 2869 - Fixed

[Apache Jenkins Server]

The Apache Jenkins build system has built Camel.trunk.notest (build #2869)

Status: Fixed

Check console output at https://builds.apache.org/job/Camel.trunk.notest/2869/ 
to view the results.