I opened OAK-3745 and attached a patch to it. It's really trivial, but it
would be better if somebody would look over it.
2015-12-08 11:08 GMT+01:00 Francesco Mari :
> 2015-12-08 10:43 GMT+01:00 Michael Dürig :
>
>>
>>
>> On 8.12.15 10:38 , Francesco Mari wrote:
>>
>>> 2015-12-08 10:32 GMT+01:00
2015-12-08 10:43 GMT+01:00 Michael Dürig :
>
>
> On 8.12.15 10:38 , Francesco Mari wrote:
>
>> 2015-12-08 10:32 GMT+01:00 Michael Dürig :
>>
>> IMO SNFE should be exported so upstream projects can depend on it.
>>>
Otherwise there is no value in throwing a specific exception in the
> firs
On 8.12.15 10:38 , Francesco Mari wrote:
2015-12-08 10:32 GMT+01:00 Michael Dürig :
IMO SNFE should be exported so upstream projects can depend on it.
Otherwise there is no value in throwing a specific exception in the first
place.
My goal is to move the Segment Store into its own bundle w
not be trivial and could require API
changes/additions).
IMHO, that's how modularization can help drive good APIs. Together
with baselining + impprt/export packages, violations of module
boundaries become visible.
Regards
Julian
On Tue, Dec 8, 2015 at 10:32 AM, Michael Dürig wrote:
>>
2015-12-08 10:32 GMT+01:00 Michael Dürig :
> IMO SNFE should be exported so upstream projects can depend on it.
>>> Otherwise there is no value in throwing a specific exception in the first
>>> place.
>>>
>>>
>>> My goal is to move the Segment Store into its own bundle without having
>> circular d
IMO SNFE should be exported so upstream projects can depend on it.
Otherwise there is no value in throwing a specific exception in the first
place.
My goal is to move the Segment Store into its own bundle without having
circular dependencies between this new bundle and oak-core. I could have
tr
2015-12-07 18:09 GMT+01:00 Michael Dürig :
>
>
> On 7.12.15 5:01 , Francesco Mari wrote:
>
>> * org.apache.jackrabbit.oak.plugins.value.ValueImpl [0] : this looks
>>> like
>>> >something we can fix easily, just fix the Segment Property State impl to
>>> >catch potential SNFEs instead of the gene
On 7.12.15 5:01 , Francesco Mari wrote:
* org.apache.jackrabbit.oak.plugins.value.ValueImpl [0] : this looks like
>something we can fix easily, just fix the Segment Property State impl to
>catch potential SNFEs instead of the generic ValueImpl
>
>
This is OAK-3740. I don't know if this appro
Thanks for your review!
2015-12-07 15:34 GMT+01:00 Alex Parvulescu :
> thanks for the writeup, good stuff!
>
> I'd like to pick up some of the back references you mentioned for further
> discussion:
>
> * org.apache.jackrabbit.oak.plugins.value.ValueImpl [0] : this looks like
> something we can
thanks for the writeup, good stuff!
I'd like to pick up some of the back references you mentioned for further
discussion:
* org.apache.jackrabbit.oak.plugins.value.ValueImpl [0] : this looks like
something we can fix easily, just fix the Segment Property State impl to
catch potential SNFEs inst
Hi all,
I started looking into moving the Segment Store and other classes closely
related to its implementation to a new bundle, independent from oak-core. I
compiled a list of backwards and forward dependencies in [1].
By looking at this list, I immediately recognise two tasks. First, all the
ba
Hi,
On Mon, Aug 10, 2015 at 8:50 AM, Philipp Suter wrote:
> ...I don’t think that it makes sense to have multiple separated maven
> projects for OAK...
FWIW, note that in Sling we do have a few independent Maven project trees:
-The main pom builds the core modules and their integration tests
-
loads all dependencies within an
OSGi container. In the OAK case most likely oak-jcr or oak-core.
On 07/08/15 11:31, "Thomas Mueller" wrote:
>Hi,
>
>I have nothing against modularization, I'm just against "modularization =
>create many many Maven projects".
I think that brings a good example where separation of modules (Ant ones,
> no comments please [1]) is performed by allowing usage of lucene-core alone
> but in most cases you'll end up using some of the companion modules.
>
> Regards,
> Tommaso
>
> [1] : https://issues.
up using some of the companion modules.
Regards,
Tommaso
[1] : https://issues.apache.org/jira/browse/LUCENE-3167
2015-08-07 11:31 GMT+02:00 Thomas Mueller :
> Hi,
>
> I have nothing against modularization, I'm just against "modularization =
> create many many Maven projects
Hi,
I have nothing against modularization, I'm just against "modularization =
create many many Maven projects". I prefer modularization *within* one
project. Why can't we do that instead?
>Ideally you have a ³root² project, e.g.
>
>/oak
> /security
Ideally you have a “root” project, e.g.
/oak
/security
/api
/implementationA
/implementationB
/core
/persistence
/..
Apache Aries has for example a pretty nicely structured hierarchical Maven
set-up. You can still build all of it starting on top..
In the end smaller modules
Hi,
> we already have 2 modules for access control
That's fine... What I meant is, we shouldn't try to move oak-core
org.apache.jackrabbit.oak.security.** plus
org.apache.jackrabbit.oak.spi.security.** to new Maven projects. Or should
we?
> jcr (top-bread)
> core (meat with all the validation)
hi thomas
hey... we already have 2 modules for access control. one
being just an optional implementation (module) that could be
plugged additionally once we have support for composite
authorization setup.
as far as i understood every single proposal and approach
that was made over the last couple
On 06/08/15 13:36, "Davide Giannella" wrote:
>Grouping two emails together
>
>On 06/08/2015 12:04, Michael Dürig wrote:
>> I neither like Sling's "constantly moving towards smaller and more
>> specific modules" as too me this seems to be mostly driven by OSGi as
>> a technology and not by modula
On Thu, Aug 6, 2015 at 12:25 PM, Thomas Mueller wrote:
> Bertrand wrote:
>>...in Sling we are only testing very few combinations,
>>actually just one combination per release.
>
> Good to know! I still don't quite understand why you have many projects
> then... what is the driver to create smaller
On 06/08/2015 12:14, Bertrand Delacretaz wrote:
> On Thu, Aug 6, 2015 at 12:04 PM, Michael Dürig wrote:
>> ...This is not about having many Maven projects but reasonable
>> module boundaries. The definition of which is low cohesion between modules
>> and hight cohesion within them
> Which is e
Grouping two emails together
On 06/08/2015 12:04, Michael Dürig wrote:
> I neither like Sling's "constantly moving towards smaller and more
> specific modules" as too me this seems to be mostly driven by OSGi as
> a technology and not by modularisation as a way to balance complexity,
> maintainabi
Hi,
>
>OTOH if one module does storage and indexing and access control and
>monitoring for example it's too much IMO, that should ideally be four
>modules.
Again, what would be the benefit of having many Maven projects? Besides, I
don't think we could easily move all of access control to one Mave
On Thu, Aug 6, 2015 at 12:04 PM, Michael Dürig wrote:
> ...This is not about having many Maven projects but reasonable
> module boundaries. The definition of which is low cohesion between modules
> and hight cohesion within them
Which is exactly the reason for Sling moving to smaller modules
On Thu, Aug 6, 2015 at 11:50 AM, Thomas Mueller wrote:
> ...I very much prefer if things that belong together stay together, and are
> not taken appart into *-api, *-common, *-impl projects. Because taking
> things apart makes maintenance very hard
I agree, besides doing just one thing a modu
Hi,
>- Move NodeStore implementations into their own modules.
I think the time spent on that would be better used trying to improve
modularization *within* oak-core, and for example move the DocumentMK to
the test package, improve javadocs, get rid of unused methods and classes,
and so
On 6.8.15 11:50 , Thomas Mueller wrote:
seven years ago we are constantly moving towards smaller and more
>specific modules (OSGi bundles in that case), even though we already
>have many of them.
Having many many Maven projects makes it very hard to understand and
follow the code in my view. I
Hi,
In my view, "modularization" is not equal to "creating many Maven
projects".
>- Bundles that do one and only one thing are more cohesive in their
>implementation. Currently, oak-core does too many things and exposes a
>low degree of cohesion.
OK, this is your
Hi,
>From the peanuts gallery I'll just observe that since we started Sling
>seven years ago we are constantly moving towards smaller and more
>specific modules (OSGi bundles in that case), even though we already
>have many of them.
Having many many Maven projects makes it very hard to understand
On 6.8.15 10:51 , Francesco Mari wrote:
What is your take on modularisation?
I'd prefer to slowly move towards a more modularised Oak. One such an
approach could be:
- Move NodeStore implementations into their own modules.
- Leverage OSGi sub-systems to hide Oak's private parts (i.e. all
On Thu, Aug 6, 2015 at 10:51 AM, Francesco Mari
wrote:
> ...What is your take on modularisation?..
>From the peanuts gallery I'll just observe that since we started Sling
seven years ago we are constantly moving towards smaller and more
specific modules (OSGi bundles in that case), even though we
Hi,
In the past few days an offline conversation sparked about the
possibility of applying a certain degree of modularisation to
oak-core. I will try to summarise the main points of this
conversation.
Some team members expressed the will to extract some parts of oak-core
into their own modules. T
33 matches
Mail list logo
