hi jukka
as stated in OAK-1434 i didn't get rid of the circular dependency that
your proposal would cause; namely because of the KernelNodeStore test
cases and on test fixture.
maybe you want to take a closer look to see if you want to resolve that
TODO as the blob base classes and interfaces are
https://issues.apache.org/jira/browse/OAK-1434
On 18/02/14 17:00, "Angela Schreiber" wrote:
>hi jukka
>
>that would be fine with me.
>so, i would suggest we adjust the various test setup before starting
>with the refactoring.
>
>i will create a jira issue that allows us to track the progress of
hi jukka
that would be fine with me.
so, i would suggest we adjust the various test setup before starting
with the refactoring.
i will create a jira issue that allows us to track the progress of this
dependency cleanup.
kind regards
angela
On 18/02/14 16:55, "Jukka Zitting" wrote:
>Hi,
>
>On
Hi,
On Tue, Feb 18, 2014 at 9:49 AM, Angela Schreiber wrote:
> in the regular code i got rid of the dependencies but there is
> still quite some tests left that currently have a dependency to
> oak-mk, namely the MicroKernelImpl. it would feel wrong to change that
> just for the sake of getting r
hi michael
>Additionally we should go through the TODO/FIXME annotations and
>
>- remove the ones that are obsolete,
>- update/clarify the ones that are out dated/unclear,
>- create issues for the ones we deem necessary and add the issue
>reference to the TODO/FIXME.
right now we have 473 TODO/FI
hi jukka
>On Tue, Feb 18, 2014 at 7:14 AM, Angela Schreiber
>wrote:
>> variant b:
>> only move the json and utility related code to oak-commons but create
>> a new dedicated module for the blob store related code. while this would
>> look more natural to me, i know that adding new module has been
Hi,
On Tue, Feb 18, 2014 at 7:14 AM, Angela Schreiber wrote:
> variant b:
> only move the json and utility related code to oak-commons but create
> a new dedicated module for the blob store related code. while this would
> look more natural to me, i know that adding new module has been quite
> co
hi michael
sounds good to me.
regards
angela
On 18/02/14 14:17, "Michael Dürig" wrote:
>
>
>On 18.2.14 12:03 , Angela Schreiber wrote:
>> so, unless there is strong opposition for doing a bit of cleanup (some
>> may think it's still to early), i would like us to come up with some
>> improvemen
On 18.2.14 12:03 , Angela Schreiber wrote:
so, unless there is strong opposition for doing a bit of cleanup (some
may think it's still to early), i would like us to come up with some
improvements and ideas in dedicated issues or discussions on the list.
Another point that came up over lunch i
On 18.2.14 12:03 , Angela Schreiber wrote:
so, unless there is strong opposition for doing a bit of cleanup (some
may think it's still to early), i would like us to come up with some
improvements and ideas in dedicated issues or discussions on the list.
+1
Additionally we should go through t
hi
i looked at the dependencies listed with the oak-core module
and was wondering that it depends on a specific mk implementation,
while i was assuming that oak-core should be independent of the
mk/node store implementation being used.
looking at it in more detail revealed that the dependency is
On 18.2.14 12:03 , Angela Schreiber wrote:
so, unless there is strong opposition for doing a bit of cleanup (some
may think it's still to early), i would like us to come up with some
improvements and ideas in dedicated issues or discussions on the list.
+1
Additionally we should go through
hi
since we will sooner or later will approach an official 1.0 release, i
would like us to invest a couple of hours thinking about maturing our
code base.
apart from providing missing functionality and working on scalability and
performance (which is mostly covered by JIRA issues), we may also w
13 matches
Mail list logo
