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 opinion, but I don't agree. I don't
hi
On 06/08/15 12:11, Michael Dürig mdue...@apache.org wrote:
On 6.8.15 11:59 , Chetan Mehrotra wrote:
I understand the concern here Michael. But then I am not sure on the
best way forward. It has mostly jsp and couple of classes. The class
would need to be adapted to work with Oak and we
Thanks for writing it down! I will try the steps on my machine as soon
as possible.
2015-08-05 22:17 GMT+02:00 Davide Giannella dav...@apache.org:
Hello team,
to ease new-comers I put down a page on oak docs about how to use the
combination of git and git-svn for developing/contributing to
i am not too familiar with the sync mechanism... but looking just
quickly at the code it seems that it persists the sync of each user/group.
that looks reasonable to me (even if it comes with some Root.commit()
overhead) as it allows to specifically retry or revert the changes
made during
hi nicolas
i am not too familiar with the sync mechanism... but looking just
quickly at the code it seems that it persists the sync of each
user/group.
that looks reasonable to me (even if it comes with some Root.commit()
overhead) as it allows to specifically retry or revert the changes
made
Hi Chetan,
While I agree that this is a good show case I don't like the copy paste
approach. While this is simple and cheap now, we keep underestimating
the hidden costs of code duplications.
See e.g. the recent mess caused by the fact we copy pasted util.Text a
couple of years ago [1].
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.
-
On Thu, Aug 6, 2015 at 11:50 AM, Thomas Mueller muel...@adobe.com 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
On Thu, Aug 6, 2015 at 12:04 PM, Michael Dürig mdue...@apache.org 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
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 Maven
On 6.8.15 12:22 , Chetan Mehrotra wrote:
Is this an official part of Oak or rather an example?
For now its an example untill its stable and we have a consensus on
wether proposed approach should be the recommended approach for
configuring Oak in standalone cases.
if it's an example we can
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.
On 6.8.15 11:59 , Chetan Mehrotra wrote:
I understand the concern here Michael. But then I am not sure on the
best way forward. It has mostly jsp and couple of classes. The class
would need to be adapted to work with Oak and we would also need to
remove dependency on jackrabbit-core as it
Is this an official part of Oak or rather an example?
For now its an example untill its stable and we have a consensus on
wether proposed approach should be the recommended approach for
configuring Oak in standalone cases.
if it's an example we can put it to oak-example.
That should be fine.
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#317)
Status: Failure
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/317/ to view
the results.
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#318)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/318/ to view
the results.
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#315)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/315/ to view
the results.
At times we need to modify only single page on the site. And while
doing that many times we deploy the whole site. The effort can be
reduced slightly by using following approach
1. In oak-doc module make require changes in markdown files
2. Run `mvn site-deploy -Dscmpublish.skipCheckin=true`
3.
On 06/08/2015 12:14, Bertrand Delacretaz wrote:
On Thu, Aug 6, 2015 at 12:04 PM, Michael Dürig mdue...@apache.org 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
On 06/08/15 13:36, Davide Giannella dav...@apache.org 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
Hi Alex
See inline.
On Wed, Aug 5, 2015 at 7:57 PM, Alex Parvulescu
alex.parvule...@gmail.com wrote:
Hi,
see inline
On Wed, Aug 5, 2015 at 5:45 PM, Julian Sedding jsedd...@gmail.com wrote:
Hi Alex
Thanks for your comments.
On Wed, Aug 5, 2015 at 3:48 PM, Alex Parvulescu
On 6.8.15 1:17 , Davide Giannella wrote:
On 06/08/2015 10:17, Michael Dürig wrote:
Thanks Davide for the writeup. This pretty much matches the workflow
I've been using for years now and which works great.
On a side note: if you want to checkout a svn branch through git svn
you might first
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,
maintainability
On 06/08/2015 10:17, Michael Dürig wrote:
Thanks Davide for the writeup. This pretty much matches the workflow
I've been using for years now and which works great.
On a side note: if you want to checkout a svn branch through git svn
you might first have to fetch it:
git svn fetch
On Thu, Aug 6, 2015 at 12:25 PM, Thomas Mueller muel...@adobe.com 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
for ( int i = 0 ; i 1000 ; i++ ) {
BTW, just doing it a 100 times should do it
(ref:NodeDocument.NUM_REVS_THRESHOLD)
While this code creates a split candidate in the DocumentNodeStore,
NodeDocument.split() creates no update ops
Actual split docs are created in background
On Thu, 2015-08-06 at 19:36 +0530, Vikas Saurabh wrote:
Hi Robert,
I am running that operation manually, so it should trigger ...
Umm, I'm sure what you meant by manual? Do you mean you the updates
once and then check whether actual split happened in a different
execution which is launched
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
Hi Davide
Of course we need to measure the speed and improvements. I am not sure
how much time I will have to implement benchmarks for this, but will
try.
So far I have not tried the cached Tika full-text extraction, yet. I'm
curious how much gain it can provide though. This may make re-indexing
Hi Julian,
On Thu, Aug 6, 2015 at 3:14 PM, Julian Sedding jsedd...@gmail.com wrote:
Hi Alex
See inline.
On Wed, Aug 5, 2015 at 7:57 PM, Alex Parvulescu
alex.parvule...@gmail.com wrote:
Hi,
see inline
On Wed, Aug 5, 2015 at 5:45 PM, Julian Sedding jsedd...@gmail.com
wrote:
Hi
Hi Vikas,
On Thu, 2015-08-06 at 19:11 +0530, Vikas Saurabh wrote:
for ( int i = 0 ; i 1000 ; i++ ) {
BTW, just doing it a 100 times should do it
(ref:NodeDocument.NUM_REVS_THRESHOLD)
While this code creates a split candidate in the DocumentNodeStore,
[
https://issues.apache.org/jira/browse/JCR-3870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14660076#comment-14660076
]
Thomas Mueller commented on JCR-3870:
-
+1 Not only makes the code faster, but also
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 Robert,
I am running that operation manually, so it should trigger ...
Umm, I'm sure what you meant by manual? Do you mean you the updates
once and then check whether actual split happened in a different
execution which is launched manually?
Can you describe your current test setup a bit
On 5 August 2015 at 18:43, Bertrand Delacretaz bdelacre...@apache.org wrote:
And on top of that, as you say, when one needs to integrate
legacy/ugly code OSGi can be a lifesaver.
Actually, OSGi is a requirement if integrating oak-lucene with any
code that uses lucene, as oak-lucene is hard
On 6.8.15 10:51 , Angela Schreiber wrote:
hi
-1 for reverting the changes. i only applied them to the
trunk (and not to a released branch, which i never intended
to do) and i don't see any reason why extending the API should
not be possible there.
This is only about reverting so we can
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
Hi Chetan,
On Thu, Aug 6, 2015 at 11:00 AM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber anch...@adobe.com wrote:
i am fine...
quite frankly i am surprised to see that there is no 2.10
branch.
I think this was discussed earlier [1]. Looks
On Thu, Aug 6, 2015 at 10:51 AM, Francesco Mari
mari.france...@gmail.com 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
On Thu, Aug 6, 2015 at 10:51 AM, Angela Schreiber anch...@adobe.com wrote:
hi
-1 for reverting the changes. i only applied them to the
trunk (and not to a released branch, which i never intended
to do) and i don't see any reason why extending the API should
not be possible there.
the
Build Update for apache/jackrabbit-oak
-
Build: #6141
Status: Broken
Duration: 1211 seconds
Commit: 6ac19528643a3c70208c6e4aa8a4d26f0ca46c04 (1.0)
Author: Julian Reschke
Message: OAK-3189: backport MissingLastRevSeeker OOM prevention to 1.0 branch
git-svn-id:
Thanks Manfred for getting this in!
For completeness regarding credits (Manfred couldn't know): I created
the initial patch and developed some doubts over time. Tomek took care
of adapting the code to address those doubts and create a superior
feature (IMHO). I assisted at that stage with code
hi
ok i see... as long as my improvmeents stay (or get properly
reapplied) on jackrabbit trunk and get released with the
next (instable) 2.x.y, i am all fine and don't mind
about the details on how we get there... i just don't want
to run after a broken oak.
what we also might want to consider
- the @Before instantiates a DocumentNodeStore backed by my
implementation of the MultiplexingDocumentStore
And it's working with say MemoryDocumentStore? IIRC, the decision to
split is done on the basis of NodeDocument.getMemory() (and I think
certain other parameters too). BTW, I might be
Right, and that applies not only to Lucene, but any other dependency.
SpringBoot is a single class path technology. Perhaps attempting a
single class path goal for a product is always futile in Java, because
eventually you run into incompatibilities. Luckily for me, I don't need a
*different*
On Thu, Aug 6, 2015 at 2:21 PM, Angela Schreiber anch...@adobe.com wrote:
i am fine...
quite frankly i am surprised to see that there is no 2.10
branch.
I think this was discussed earlier [1]. Looks like we would have to
revisit that decision and continue with stable/unstable releases
Chetan
46 matches
Mail list logo
