You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Jukka Zitting <ju...@gmail.com> on 2012/11/16 09:13:11 UTC
MongoMK build updates
Hi,
As you may have noticed from the past few commits, I'm working on
better integrating the MongoMK to our normal build. The idea is to
always build the MongoMK components so we wouldn't need the extra
-Pmongomk profile anymore. To do this I'm instructing the test cases
that depend on a MongoDB instance being available to be automatically
skipped (instead of failing the build) when such an instance is not
found.
See below for relevant details I added to the README.
BR,
Jukka Zitting
----
MongoDB integration
-------------------
Parts of the Oak build expects a MongoDB instance to be available for
testing. By default a MongoDB instance running on localhost is expected,
and the relevant tests are simply skipped if such an instance is not found.
You can also configure the build to use custom MongoDB settings with the
following properties (shown with their default values):
-Dmongo.host=127.0.0.1
-Dmongo.port=27017
-Dmongo.db=MongoMKDB
-Dmongo.db2=MongoMKDB2
Note that the configured test databases will be *dropped* by the test cases.
Re: MongoMK build updates
Posted by Michael Dürig <md...@apache.org>.
On 16.11.12 8:13, Jukka Zitting wrote:
> Hi,
>
> As you may have noticed from the past few commits, I'm working on
> better integrating the MongoMK to our normal build. The idea is to
> always build the MongoMK components so we wouldn't need the extra
> -Pmongomk profile anymore. To do this I'm instructing the test cases
> that depend on a MongoDB instance being available to be automatically
> skipped (instead of failing the build) when such an instance is not
> found.
Thanks Jukka for taking care of this. It is important to have tighter
integration of MongoMK into the build. Thinking of CI we should also
have the option to force the build to fail if no Mongo DB is available.
Otherwise a DB outage would cause all subsequent builds to pass.
Michael
>
> See below for relevant details I added to the README.
>
> BR,
>
> Jukka Zitting
>
> ----
>
> MongoDB integration
> -------------------
>
> Parts of the Oak build expects a MongoDB instance to be available for
> testing. By default a MongoDB instance running on localhost is expected,
> and the relevant tests are simply skipped if such an instance is not found.
> You can also configure the build to use custom MongoDB settings with the
> following properties (shown with their default values):
>
> -Dmongo.host=127.0.0.1
> -Dmongo.port=27017
> -Dmongo.db=MongoMKDB
> -Dmongo.db2=MongoMKDB2
>
> Note that the configured test databases will be *dropped* by the test cases.
>
Re: MongoMK build updates
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Nov 16, 2012 at 10:13 AM, Jukka Zitting <ju...@gmail.com> wrote:
> As you may have noticed from the past few commits, I'm working on
> better integrating the MongoMK to our normal build.
As a second step I've migrated the MongoMK integration test setup from
oak-mongomk-test to oak-it-mk where they are run along with tests on
the other MK implementation whenever a MongoDB instance is available
for testing.
As a part of that migration I unified the test setups so that also the
integration tests use the "MongoMKDB" database as a default instead of
the "mk-tf" database it was using previously. This way the
documentation in the README covers all the active test cases.
BR,
Jukka Zitting
Re: MongoMK build updates
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Nov 16, 2012 at 11:14 AM, Mete Atamel <ma...@adobe.com> wrote:
> As guessed, the build slow down was due to dropping the DB before and
> after each test. I changed the tests to drop collections instead (see
> diff.txt) and the build and tests run in 1 minute. Dropping collections is
> effectively same as dropping DB as far as tests are concerned, so I think
> we should go with this change to have a speedy build. Could someone apply
> this change for me please? Thanks.
Good point, done in revision 1410265.
I switched the cleanup to drop the entire DB instead of just the
selected collections to avoid hardcoding too much details in the
abstract base class. To combine these approaches I adjusted your patch
slightly so that the cleanup automatically drops all non-system
collections from the test database.
BR,
Jukka Zitting
Re: MongoMK build updates
Posted by Mete Atamel <ma...@adobe.com>.
As guessed, the build slow down was due to dropping the DB before and
after each test. I changed the tests to drop collections instead (see
diff.txt) and the build and tests run in 1 minute. Dropping collections is
effectively same as dropping DB as far as tests are concerned, so I think
we should go with this change to have a speedy build. Could someone apply
this change for me please? Thanks.
-Mete
On 11/16/12 9:51 AM, "Mete Atamel" <ma...@adobe.com> wrote:
>Hi Jukka,
>
>Thanks for setting this up. One minor issue though. The MongoMK build used
>to take around 2 minutes (see withoutJukkasChanges.txt) but with your
>changes from yesterday, it takes around 8.5 minutes (see
>withJukkasChanges.txt). Tests take much longer. This is probably due to
>how databases/collections are created/dropped in MongoMK tests, maybe it's
>being done too many times or something similar. I'll take a look.
>
>-Mete
>
>On 11/16/12 9:13 AM, "Jukka Zitting" <ju...@gmail.com> wrote:
>
>>Hi,
>>
>>As you may have noticed from the past few commits, I'm working on
>>better integrating the MongoMK to our normal build. The idea is to
>>always build the MongoMK components so we wouldn't need the extra
>>-Pmongomk profile anymore. To do this I'm instructing the test cases
>>that depend on a MongoDB instance being available to be automatically
>>skipped (instead of failing the build) when such an instance is not
>>found.
>>
>>See below for relevant details I added to the README.
>>
>>BR,
>>
>>Jukka Zitting
>>
>>----
>>
>>MongoDB integration
>>-------------------
>>
>>Parts of the Oak build expects a MongoDB instance to be available for
>>testing. By default a MongoDB instance running on localhost is expected,
>>and the relevant tests are simply skipped if such an instance is not
>>found.
>>You can also configure the build to use custom MongoDB settings with the
>>following properties (shown with their default values):
>>
>> -Dmongo.host=127.0.0.1
>> -Dmongo.port=27017
>> -Dmongo.db=MongoMKDB
>> -Dmongo.db2=MongoMKDB2
>>
>>Note that the configured test databases will be *dropped* by the test
>>cases.
>
Re: MongoMK build updates
Posted by Mete Atamel <ma...@adobe.com>.
Hi Jukka,
Thanks for setting this up. One minor issue though. The MongoMK build used
to take around 2 minutes (see withoutJukkasChanges.txt) but with your
changes from yesterday, it takes around 8.5 minutes (see
withJukkasChanges.txt). Tests take much longer. This is probably due to
how databases/collections are created/dropped in MongoMK tests, maybe it's
being done too many times or something similar. I'll take a look.
-Mete
On 11/16/12 9:13 AM, "Jukka Zitting" <ju...@gmail.com> wrote:
>Hi,
>
>As you may have noticed from the past few commits, I'm working on
>better integrating the MongoMK to our normal build. The idea is to
>always build the MongoMK components so we wouldn't need the extra
>-Pmongomk profile anymore. To do this I'm instructing the test cases
>that depend on a MongoDB instance being available to be automatically
>skipped (instead of failing the build) when such an instance is not
>found.
>
>See below for relevant details I added to the README.
>
>BR,
>
>Jukka Zitting
>
>----
>
>MongoDB integration
>-------------------
>
>Parts of the Oak build expects a MongoDB instance to be available for
>testing. By default a MongoDB instance running on localhost is expected,
>and the relevant tests are simply skipped if such an instance is not
>found.
>You can also configure the build to use custom MongoDB settings with the
>following properties (shown with their default values):
>
> -Dmongo.host=127.0.0.1
> -Dmongo.port=27017
> -Dmongo.db=MongoMKDB
> -Dmongo.db2=MongoMKDB2
>
>Note that the configured test databases will be *dropped* by the test
>cases.