camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Johnson <brad.john...@mediadriver.com>
Subject Re: CamelBlueprintTestSupport doesn't like 6 directories deep
Date Tue, 06 Sep 2016 15:35:32 GMT
Wish I knew Gradle's better but unfortunately don't.


**If anyone else encountered this, the work-around is to use
"target"directory as the Gradle's buildDir; then the test passes in any
directory!**

So no matter what setting the buildDir will work whether you are 5 levels
deep or 15 levels deep?  If you look a the Maven bundle plugin it states
that the build dir defaults to project ${project.build.directory}.   Why
that would change based on what level deep the directory is I haven't a
clue.  But it does make some sense that explicitly specify the buildDir
would resolve issues.  It may be that something in the

Unfortunately my unfamiliarity with Gradle reduces me to hand waving but it
may help.


http://felix.apache.org/components/bundle-plugin/instructions-mojo.html

You can also override the properties configuration in the test itself and
pass them in and that should resolve any issue.  Also if you segregate your
blueprint.xml and create a blueprint-properties.xml in the
src/main/resources they both will load when deployed.  But this permits you
to create a blueprint-properties.xml in the src/test/resources that you can
use at test time instead of the standard properties. In your subclass of
the CamelBlueprintTestSupport you can then specify the following.  In this
case the blueprint-properties.xml is located in your srctest/resources and
will be found by CBTS without specify the exact location.  The same is true
of the OSGI-INF directory which resides in the src/main/resources
directory.  When the test is run both are available for loading (I don't
recall where or if they get moved into the target directory or not.  I
believe they are.)

private static final String TEST_BLUEPRINT_XML =
"blueprint-properties.xml,OSGI-INF/blueprint/blueprint.xml";
@Override protected String getBlueprintDescriptor() { return
TEST_BLUEPRINT_XML; }

On Mon, Sep 5, 2016 at 2:37 AM, sohrab <sohrab.hosseini@gmail.com> wrote:

> I have found a weird/funny bug with CamelBlueprintTestSupport, I thought I
> share. I briefly looked at the source code but cannot see any obvious
> culprit so I thought I post it here if anyone feels like a challenge.
>
> Basically when I git-clone a project in a directory that is at most 5
> levels
> deep from root directory, the blueprint test passes. But if it is cloned to
> a directory which is 6 levels or more, the blueprint fails to start. (As
> you
> can imagine, it took me ages to figure out this was the case!)
>
> I narrowed down the problem to blueprint config admin not being initialised
> properly. Then I looked at the source code for CamelBlueprintTestSupport
> and
> realised it uses hardcoded relative paths like "target/etc".
>
> https://github.com/apache/camel/blob/master/components/
> camel-test-blueprint/src/main/java/org/apache/camel/test/blueprint/
> CamelBlueprintTestSupport.java#L523
>
> Here is the thing: I am using Gradle; there is no "target" directory! It
> does get created as part of the blueprint test though.
>
> The $1M question is why is 6 directories deep is significant in all this?!
> It definitely is not the string length of the absolute path as I tried a
> really long path, but only 5 levels deep, and the blueprint started fine.
>
> *If anyone else encountered this, the work-around is to use "target"
> directory as the Gradle's buildDir; then the test passes in any directory!*
>
> I'll investigate it further once I get some free time but double you tee
> eff!
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/CamelBlueprintTestSupport-doesn-t-like-6-directories-
> deep-tp5787192.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message