Search performance issue

[Cédric Damioli]

Hi all,

In my repository, I have a Node named 'content' under which I have an 
arbitrary number of Node. Under each of these Nodes, I have one Node 
named 'fr'.


My exemple query is simple: I want to get all "fr" Nodes.

1) I executed the following query : "//content/*/fr". The result is ok 
but the execution took more than 80s (the whole repository has more than 
100 000 Nodes and more than 1 000 000 properties)
2) I executed the query "//content/*" followed by a small Java loop for 
getting the "fr" subNode of each result. The whole thing took only a 
couple of seconds.


Is it the normal behaviour ? Does the query have to end with "/*" to be 
correctly handled by Jackrabbit ?


Regards,

--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: Search performance issue

[Cédric Damioli]

Marcel Reutegger a écrit :

Cédric Damioli wrote:
In my repository, I have a Node named 'content' under which I have an 
arbitrary number of Node. Under each of these Nodes, I have one Node 
named 'fr'.


My exemple query is simple: I want to get all "fr" Nodes.

1) I executed the following query : "//content/*/fr". The result is 
ok but the execution took more than 80s (the whole repository has 
more than 100 000 Nodes and more than 1 000 000 properties)

>
2) I executed the query "//content/*" followed by a small Java loop 
for getting the "fr" subNode of each result. The whole thing took 
only a couple of seconds.


I assume the result set is quite large, therefore you should disable 
document ordering on result nodes in the search configuration. per 
default result nodes are ordered in document order, which is an 
operation that is performed without information from the search index. 
That is, all information must be loaded through the persistence 
manager to arrange the result nodes in document order.


adding the following parameter in SearchIndex tag in workspace.xml 
will do the trick:

  

for more details on index configuration see also:
http://svn.apache.org/viewcvs.cgi/jackrabbit/trunk/jackrabbit/src/main/config/repository.xml?view=markup 



as a quick workaround you can also append an order by clause to the 
query, this will also avoid document order on the result nodes:

//content/*/fr order by jcr:score

If you already disabled document order then 80 seconds is IMO not 
acceptable. In that case could you please file a jira issue.


IIUC, the document order flag does not affect the query execution time 
(ie Query.execute()), but only the first NodeIterator.nextNode() call. 
Or am I wrong on this ?
In my case, I only consider the execution time, so the 
respectDocumentOrder has no incidence (I have tested with or without it 
and results are the same).

So in this case, 80 seconds is indeed not acceptable.

I'll file a new new issus as soon as I have finished my benchmarks, to 
be able to give some real statistics.


Regards,

--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: query feature extensions

[Cédric Damioli]

Marcel Reutegger a écrit :
Jackrabbit currently supports a limited set of XPath features, 
basically the mandatory feature set as specified by jsr-170 plus some 
extended capability where predicates can stated.


I would like to invite everyone (or at least whoever is interested...) 
to put together a list of 3 query features that are missing the most 
in jsr-170/jackrabbit regarding XPath support. Of course you may post 
a longer list but I'm primarily interested in getting a feeling where 
the priorities are.


e.g. here is my list:

1) child axis support in predicates. See also:
http://issues.apache.org/jira/browse/JCR-247

2) fn:name() and some of the functions for substring matching
This allows more sophisticated matching of node names. currently only 
'*' and exact name are possible.


3) union operator
searching only under certain nodes excluding the jcr:system node is 
currently not possible. Using union operator would allow this.


regards
 marcel


My two first points would be same as yours :

1) Add more axis support (child axis and maybe ascendant axis, to be 
able to construct queries such as "//element(*, whatever)/..")

2) To be able to query Nodes names.

And I would add :

3) To be able to order on Node names (eg "//* order by fn:name()"), and 
also to be able to choose the case sensibility of a query ordering (eg 
"//* order by @whatever case insensitive")


Regards,

--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: query feature extensions

[Cédric Damioli]

Jukka Zitting a écrit :


Hi,

On 4/3/06, Marcel Reutegger <[EMAIL PROTECTED]> wrote:
 


I would like to invite everyone (or at least whoever is interested...)
to put together a list of 3 query features that are missing the most in
jsr-170/jackrabbit regarding XPath support.
   



1) Placeholders in queries:

   //element(*,nt:file)[EMAIL PROTECTED]:created>?]

2) Support for predicates in location steps:

   //element(*,nt:file)[EMAIL PROTECTED]:created>'...']/jcr:[EMAIL 
PROTECTED]:lastModified<'...']
 


This one already works, don't it ?
I run many queries like this one in my app.
I don't know if it belongs to JCR 1.0, but Jackrabbit handles it correctly.


3) Support for child axis in predicates:

   //element(*,nt:file)[EMAIL PROTECTED]:created>'...' and
jcr:[EMAIL PROTECTED]:lastModified<'...']]

 

Re: Repository inconsistent with xmlpersistentmanager

[Cédric Damioli]

Stefan Guggisberg a écrit :

hi raphaël

On 5/19/06, Raphaël Franchet <[EMAIL PROTECTED]> wrote:

Hello,

I'm using JR 1.0 with the xmlPersistanceManager.


the XMLPersistenceManager is not recommended to be used
in a production environment. its major flaw , apart from being dead 
slow ;),

is that it is 'non-transactional', i.e. if your jvm process suffers a
sudden death
(power outage, kill, etc) you'll very likely end up with an
inconsistent repository
state (like the one you described).

by using jackrabbit's default configuration (i.e. 
DerbyPersistenceManager)

you avoid such issues.



Hi Marcel,

We know that "now" the XMLPM is not the recommanded one, but as early 
adopters of Jackrabbit, more than one year ago, there was only XMLPM and 
ObjectPM :-)


We now have an inconsistent repository. What would you suggest ? 
Migration to a new PM (if it is possible) ? Debugging of our current 
repository ?


BTW, what would you recommend as a new PM : DerbyPM or BerkeleyDBPM ?

Regards,
Cédric




My application has many nodes (about 20 GB of data) and I've got a huge
problem : my repository is going inconsistent.

Using the API normally, I obtain some time the following problem :
On the file system, node 'A' references a child node 'B' (in his xml
persistent state) but node 'B' does not exist (there is no corresponding
xml file).
The API is telling me that node A has no child, but if I try to add B it
fails (telling that it can't find the already referenced B).

The problem appeared once yesterday, so we restored a daily backup (that
is clean on this node) but after a day of use the same problem is coming
up (several times on the same repository)

The only particularity I've noticed on the problematic node, is that it
is removed and re-added in the same session, quite often.
The application is used by many people at a time that may be accessing
the same nodes.

Any experience or idea ?
(considering I don't believe this is an astral conjunction)

Regards,

--

Raphaël FRANCHET
Chef de projet
Solutions & Technologies
ANYWARE TECHNOLOGIES
Tel: +33 (0)5 61 00 73 47
Fax : +33 (0)5 61 00 51 46
www.anyware-tech.com




--
Cédric Damioli
Chef de projets systèmes d'informations
Solutions CMS
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: New feature: Clustering

[Cédric Damioli]

Dominique Pfister a écrit :

Hi,

I just committed some files to implement a first approach to
clustering in jackrabbit. Inside this approach, all repositories in
the cluster share the persistence layer (e.g. a derby database started
standalone). When a repository commits some changes, it will write a
log record to a shared "journal" directory. Another repository
watching that directory will eventually read this record, invalidate
its internal caches and fire corresponding events.

More than clustering, does this approach also enable a new PM-based 
implementation of the Model 3 deployment, ie a remote, shareable PM, 
accessible from various Jackrabbit instances ? I know this is not the 
purpose of a PM, but with this proposed architecture, results are 
functionnally the same, aren't they ?
I also guess that this approach will be way faster than the RMI one, 
even if it's not its primary goal.


Regards,

--
Cédric Damioli
Directeur de projets
Solutions CMS
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: Contents of jcr-server ?

[Cédric Damioli]

Sorry for cross-posting, but I realized that I may have more answers 
here than on the users ML.


Regards,
Cédric

Cédric Damioli a écrit :

Hi all,

Can someone tell me what are the purposes of the different parts of 
jcr-server ? I searched ML and wiki, but didn't found anything...


There are 4 folders :
- client, which I suppose to be a generic Java WebDAV client
- webdav, which I suppose to be the generic parts of a Java WebDAV 
server, but not a server itself
- server, which seems to actually contains the WebDAV server, but it 
also seems there are two different implementations. Is it true ? And 
why ?

- webapp, which is the servlet part of the above server

I'm wondering whether this WebDAV stuff is provided to access a JCR 
Repository through a WebDAV layer (the client is a WebDAV one), or to 
implement the model 3 deployment over WebDAV (the client is a JCR 
one), or to have a full Java WebDAV server (a Slide successor).


I also may be totally wrong about this.

If someone has pointers on relevant docs, wiki, ..., I would appreciate.
Of course, I would be happy to contribute back all the answers to a 
wiki or something like that, to make the stuff more clear to other 
users ?


Regards,




--
Cédric Damioli
Directeur de projets
Solutions CMS
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: Contents of jcr-server ?

[Cédric Damioli]

Hi angela,

Many thanks for all these pointers.
About the 'jcr-remoting-over-webdav' part, I understant that the 
JCRWebdavServer stands as the server side, but do you know if someone 
ever worked on the JCR client part, to build the whole chain :

JCR API -> WebDav request -> network -> JCRWebdavServer -> JCR Repository

AFAIU, the above chain miss only the first part, ie a JCR implementation 
based on Webdav requests. Or am I wrong ?


I'm actually want to set up all possible 'jcr-remoting-over-whatever' 
stuff, so that I am able to perform benchmarks, compare functionalities 
and so on, ...

Of course if I ever manage to get some figures, I'll post them here.

Regards,
Cédric


Angela Schreiber a écrit :

hi cedric

there used to be a index.jsp, that roughly summarizes
the contents of the jcr-server.

http://svn.apache.org/repos/asf/jackrabbit/trunk/jcr-server/webapp/src/webapp/index.jsp 



and there were various threads regarding the aim and
the status of the jcr-server in the dev list.

e.g.
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6516/focus=6528 



peter darton once wrote a HOWTO. apparently it never made it into the
docu:

http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03759.html 


and corrigenda:
http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg03762.html 



>> I'm wondering whether this WebDAV stuff is provided to access a JCR
>> Repository through a WebDAV layer (the client is a WebDAV one), or to
>> implement the model 3 deployment over WebDAV (the client is a JCR
>> one), or to have a full Java WebDAV server (a Slide successor).

its a chimaera

http://issues.apache.org/jira/browse/JCR-417

points to the issue, that should improve this situation. particularly
separating the webdav-only part from the 'jcr-remoting-over-webdav'.
that fact, that the jcr-server contains 2 implementations with
completely different aims, apparently causes quite some confusion.

regarding 'full webdav server':

- we made some efforts to make the 'simple' server compliant to
  RFC2518. i don't know, if its a 'full' webdav server, since
  at Day we used to built thin webdav-views on top of our repository
  and not focusing too much on the Webdav itself ;)

- maybe the following post may give you some hints about
  the basics, that lead to the webdav-library present in
  jackrabbit (and your question regarding 'slide'):

http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/6516/focus=6528 



regards
angela




--
Cédric Damioli
Directeur de projets
Solutions CMS
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: can I reindex a whole repository?

[Cédric Damioli]

Tobias Bocanegra a écrit :

yes,
- stop the repository
- delete the search indexes in the workspace directories
- start the repository

the search handler will then traverse the repository and reindex all 
items.

regards, toby
One could imagine a programatical way of doing this. This is currently 
not allowed by API but this could be an interesting admin feature, 
allowing the following steps :


- Stop the repository
- Restarts the repository in "admin mode" (ie access only allowed to admin)
- re-indexing : one could imagine 
repo.get*SearchManager(wspName).destroyAndRecreateQueryHandler(), or 
repo.destroyAndRecreateSearchManagers()

- Stop the repository
- Start it in real mode

What do you think about that ?

Regards,

--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 73 47
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: [jira] Commented: (JCR-134) Unreferenced VersionHistory should be deleted automatically.

[Cédric Damioli]

Paul J DeCoursey a écrit :

Cédric Damioli (JIRA) wrote:
[ 
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457455 
] Cédric Damioli commented on JCR-134:



The VH need only to be kept when there are remaining Version attached 
to it.
In many apps, it would be great to get rid of empty VH (ie no more 
Version, and no more Node referencing it).
  
This doesn't seem right to me.  Kind of defeats the purpose of 
Versioning if we start removing deleted items, deleted is just another 
state in the history that should be tracked and preserved.



Deleting Versions means actually deleting these history states.
Its no more than an administrative task, which in some cases may be very 
useful, eg. to maintain the repository as small as possible, or to keep 
only important versions (up to the app, of course).
The point of this JCR-134 issue is only that when there is no more 
Version in the VH (they have all been deleted) and no more Node in any 
workspace referencing this VH, there should be a way to also delete the 
VH, which can't be useful anymore.


Regards,
Cédric

Strange behaviour with multi-Session

[Cédric Damioli]

Hi all,

I'm experimenting a strange (looks random) behaviour on a production 
server (jackrabbit-1.0) : I start an "admin" Session at my webapp 
startup time.

This admin Session does not write anything (never any pending changes).
Many times later (say a few hours or days), I start another Session, add 
a Node, save changes and logout.
Then I tried to access this new Node with the admin Session and it fails 
with an ItemNotFoundException.

If I try with any new Session, it reads the Node correctly.

So I wondered if I had to make a adminSession.refresh(true) before all. 
But the implementation of SessionImpl.refresh(true) simply does nothing.


If I try to set up a quick test to reproduce the case, it always works fine.

Has anybody experimented such behaviour ? Any idea ?

Regards,

--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 73 47
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Spec compliance regarding child node types of nt:frozenNode

[Cédric Damioli]

Hi all,

When checking in a versionable Node "A", with a child "B" 
(OnParentVersion=COPY) of whatever nodetype, the corresponding 
nt:frozenNode has a child node "B" of type "nt:frozenNode" and not of 
its initial nodetype.
From the JCR spec, section 8.2.11.1 : "On checkin of N, C and all its 
descendent items, down to the leaves of the subtree, will be copied to 
the version storage as a child subtree of VN."
By "copy" I also understood the copy of the nodetypes of the child nodes 
of the versionable node.
I'm wondering if the currently implemented behaviour is compliant with 
the spec ? Or am I missing something ?


Regards,

--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 73 47
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: Raw mode

[Cédric Damioli]

Nice idea, from my POV.
This could also solve the problem of restoring a version history backup, 
or all "protected" values related problems.


But of course, it would go against the initial JSR-170 spec.

This point actually highlights the lack of administrative API in JR, 
doesn't it ?

It may be the right time to think to such an API ?
WDYT ?

Regards,

Cédric

Jukka Zitting a écrit :

Hi,

Every now and then I see people running into issues with the current
limitations in modifying node types in Jackrabbit. The recent JCR-954
issue also highlighted a similar problem with referential integrity
checks. For various reasons the strict integrity checks in Jackrabbit
end up hurting valid use cases.

The proper solution to the problem would be to actually implement the
missing node type modification support and to optimize the use cases
in JCR-954, but it seems to me that we are at least a year if not more
away from such solutions.

Thus I would like to float the idea of a "raw mode" in Jackrabbit. The
"raw mode" would be a session-level attribute, enabled during login,
that would disable all node type and reference checks for that
session. The mode would only be available to administrator users,
perhaps even only when no other sessions are accessing the repository.

BR,

Jukka Zitting



--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 73 47
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com

Re: Jackrabbit 1.5 release plan

[Cédric Damioli]

Hi,

Is there a chance to see JCR-134 included in the release ?
My collegue Sébastien provided a patch. Have you got time to review it ?
It's important for us and our customers, as repositories keep growing 
even when workspaces and nodes are cleaned, and after years in 
production, it may happen that hard disks get full !


Thanks in advance,

Best regards,
Cédric

Jukka Zitting a écrit :

Hi,

On Tue, Oct 28, 2008 at 9:27 AM, Jukka Zitting <[EMAIL PROTECTED]> wrote:
  

There are still some loose ends with the following three issues that I
want resolved before we do the release.

 [JCR-1775] Transaction-safe versioning
 [JCR-1813] Invalid journal records during XATransactions
 [JCR-1825] DBDataStore doesn't support concurrent reads

I'm currently working on JCR-1775, and both JCR-1813 and JCR-1825 have
patches attached, so I believe we should be able to resolve them all
already today. I'll then do a third preview build in preparation for
the official release candidate and vote.



I got those issues fixed as planned, but unfortunately I didn't have
time to push forward with the preview build. Now with the ApacheCon
and other business behind I'm ready to take up where I left.

I've updated the 1.5 branch with recent smaller improvements and
changes in trunk (I'm leaving the more complex post-branch changes for
1.6) and plan to build the next preview build later today.

BR,

Jukka Zitting
  



--
Cédric Damioli
Ametys technical manager
CMS solutions
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 73 47
Mob : +33 (0)6 87 03 61 63
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
http://www.ametys.fr / http://www.ametys.org

Ce message et toutes les pièces jointes (le "Message") sont confidentiels et 
établis à l'intention exclusive de ses destinataires.
Toute modification, édition, utilisation ou diffusion non autorisée est 
interdite.
Anyware Technologies et sa maison mère Wavecom déclinent toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation. 

Re: Jackrabbit 1.6 release plan

[Cédric Damioli]

Hi Jukka,

Could JCR-134 be part of the 1.6 release ?
We provided a patch several months ago, but AFAIK nobody reviewed it.

This patch is really helpful, as it allows repositories not to grow 
unnecessarily over time [1]

There's also a few threads on mailing-lists asking for this feature [2]

The patch in the JIRA is quite old (was made for 1.4.x), so please tell 
us if we must post another one.


Regards,
Cédric

[1] http://issues.apache.org/jira/browse/JCR-134
[2] http://markmail.org/thread/l5rd5em3xxbg44jx

Jukka Zitting a écrit :

Hi,

On Tue, Apr 21, 2009 at 5:10 PM, Jukka Zitting  wrote:
  

As noted in various recent threads, we're getting closer to branching
and releasing Jackrabbit 1.6. There are no major blockers to 1.6 so we
should be able to move fairly quickly with the release.



The 1.x branch is in a pretty good state so I'm planning to cut the
1.6.0 release sometime next week.

BR,

Jukka Zitting
  



--
Cédric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 73 47
Mob : +33 (0)6 87 03 61 63
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
http://www.ametys.fr / http://www.ametys.org

Ce message et toutes les pièces jointes (le "Message") sont confidentiels et 
établis à l'intention exclusive de ses destinataires.
Toute modification, édition, utilisation ou diffusion non autorisée est 
interdite.
Anyware Technologies et sa maison mère Wavecom déclinent toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation. 

Getting real query results size instead of -1

[Cédric Damioli]

Hi team,

I'm migrating an app from JR 1.6.4 to 2.2.7.
My unit tests don't pass anymore, because of the well-known behaviour of 
QueryResult.getSize() returning -1 in many cases.
Moreover, I have a query returning no results 
(result.getNodes().hasNext() returns false), but the getSize() still 
returns -1 !
I know there's some workaround ("order by @jcr:score descending"), but 
it seems quite a hack to me.


Diving into the code, I looked at QueryResultImpl#getResult(long) and 
was wondering why the numResults (which at the end is the value returned 
by getSize()) is given the value of result.getSize() (which often 
returns -1) and not the value of resultNodes.size() (though only 
relevant when all results have been fetched, which is often the case 
with a default fetch size of Integer.MAX_VALUE !).


I am not sure to fully understand that piece of code, so don't hesitate 
to tell me that I'm totally wrong :)


Best regards,

--
Cédric Damioli
CMS Ametys
ANYWARE SERVICES
http://www.anyware-services.com
http://www.ametys.org

Ce message et toutes les pièces jointes (le "Message") sont confidentiels et 
établis à l'intention exclusive de ses destinataires.
Toute modification, édition, utilisation ou diffusion non autorisée est 
interdite.
Anyware Services décline toute responsabilité au titre de ce Message s'il a été 
altéré, déformé, falsifié ou édité, diffusé sans autorisation.

Re: Jackrabbit 2.5.1 and 2.4.3 release plans

[Cédric Damioli]

Hi,

I submitted yesterday a patch for fixing a query bug 
(https://issues.apache.org/jira/browse/JCR-3401)

Could someone review it before cutting releases ? At least for the 2.4.3 ?

Thanks in advance,

Regards,
Cédric

Le 02/08/2012 16:47, Jukka Zitting a écrit :

Hi,

The upcoming Oak 0.4 release will need a release from Jackrabbit trunk
and I think there are a couple of other downstream projects who'd
benefit from having a fresh, unstable Jackrabbit 2.5.x release. Thus I
propose that we cut the Jackrabbit 2.5.1 release candidate shortly,
ideally already tomorrow.

There's also some demand for a new 2.4.x release with some of the
recent bug fixes, so I think we should target at cutting the 2.4.3
release candidate sometime in the next week or two. If you have any
particular fixes you'd like to see included, please note so in Jira.

BR,

Jukka Zitting

Bug in DescendantSelfAxisQuery since Lucene 3.0 update

[Cédric Damioli]

Hi team,

I've noticed an annoying bug in Lucene queries when combining a 
DescendantSelfAxisQuery with another Query. This can lead to wrong query 
results.
I've opened https://issues.apache.org/jira/browse/JCR-3401 and provided 
a test case and a patch fixing this bug.


Could someone review it and apply it if it is ok ? It affects all 
versions since 2.3 and lead to many production bugs.


Regards,

--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Collating ordered query results

[Cédric Damioli]

Hi team,

As a French native, I often have to manipulate text containing accents.

So that when I execute some Xpath query like "//text order by @title", I 
may get a text titled "Aéroport" ordered after a text titled "Avion", 
which is not correct.


My first idea was to create a special function allowing to write 
something like "//text order by fn:normalize(@title)" or something like 
that. This function would consider "Aéroport" as "Aeroport", leading to 
the expected result.
Then I discover than, at least for Xpath, the grammar (inherited from 
XPath 2.0) permit a more standard "//text order by @title collation 
'XXX'" which may also be implemented in Jackrabbit with a little more 
work but won't be natural in SQL


So my first question is : does someone already thought about collations 
? Possibly with an already working solution ?
Second question : which of my two solutions fit the best in Jackrabbit 
(or possibly a third one) ?
And finally third question : if I implement such a collation algorithm, 
would someone be interested to have it in the Jackrabbit core ?


Best regards,

--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: Collating ordered query results

[Cédric Damioli]

Hi guys,

Following on this, I've submitted a patch here : 
https://issues.apache.org/jira/browse/JCR-3443
I propose a new XPath function fn:normalize which works perfectly in my 
case.


I'm now awaiting your comments to know what to do with it :)

Best regards,
Cédric

Le 09/10/2012 23:00, Cédric Damioli a écrit :

Hi team,

As a French native, I often have to manipulate text containing accents.

So that when I execute some Xpath query like "//text order by @title", 
I may get a text titled "Aéroport" ordered after a text titled 
"Avion", which is not correct.


My first idea was to create a special function allowing to write 
something like "//text order by fn:normalize(@title)" or something 
like that. This function would consider "Aéroport" as "Aeroport", 
leading to the expected result.
Then I discover than, at least for Xpath, the grammar (inherited from 
XPath 2.0) permit a more standard "//text order by @title collation 
'XXX'" which may also be implemented in Jackrabbit with a little more 
work but won't be natural in SQL


So my first question is : does someone already thought about 
collations ? Possibly with an already working solution ?
Second question : which of my two solutions fit the best in Jackrabbit 
(or possibly a third one) ?
And finally third question : if I implement such a collation 
algorithm, would someone be interested to have it in the Jackrabbit 
core ?


Best regards,


--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: Jackrabbit 2.5.3 and 2.6.0 release plan (Was: Roadmap for Jackrabbit 2.x and 3.0)

[Cédric Damioli]

Hi Jukka and team,

I've opened 3 issues [1] [2] [3] (one bug, 2 improvements) with 
associated patches and would like to see them included in the upcoming 
release if possible. Could someone review the patches ?


Best regards,
Cédric

[1] https://issues.apache.org/jira/browse/JCR-3485
[2] https://issues.apache.org/jira/browse/JCR-3443
[3] https://issues.apache.org/jira/browse/JCR-3402


Le 17/01/2013 13:32, Jukka Zitting a écrit :

Hi,

On Thu, Jan 17, 2013 at 1:00 PM, Jukka Zitting  wrote:

On Tue, Oct 23, 2012 at 5:03 PM, Jukka Zitting  wrote:

* Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0
version sometime around the end of this year. As usual, we'll have a
2.6 maintenance branch for upcoming 2.6.x patch releases.

We missed the end of the year already, but let's try to get this out
pretty soon. I'll follow up with in a separate thread.

I think current trunk is already pretty stable, but to avoid any
surprised I'd still want to cut one more 2.5.x release before going
for 2.6.0.

Thus I suggest the following schecule:

* Monday, Jan 21st: Cut the 2.5.3 release candidate and create the 2.6 branch.
* Monday, Jan 28th: Cut the 2.6.0 release candidate from the 2.6 branch.

Assuming the votes pass, the releases will be out by the end of the
respective weeks. I volunteer to cut these releases, especially since
I'll also need to update the release scripts and documentation to
reflect the new svnpubsub-based release publishing mechanism.

If you have any features or improvements that you'd still want to see
included in time for 2.6, please tag them accordingly in Jira.

BR,

Jukka Zitting

--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: New Jackrabbit committer: Cédric Damioli

[Cédric Damioli]

Hi team,

I'm very proud to be part of this community.
Thanks to all.

Regards,
Cédric

Le 21/02/2013 08:59, Jukka Zitting a écrit :

Hi Cédric,

On Wed, Feb 20, 2013 at 4:44 PM, Michael Dürig  wrote:

Please welcome Cédric Damioli as a new committer and PMC member of
the Apache Jackrabbit project.

Welcome, and thanks for all your contributions!

BR,

Jukka Zitting

Re: [VOTE] Release Apache Jackrabbit 2.7.0

[Cédric Damioli]

Hi,

   [X] +1 Release this package as Apache Jackrabbit 2.7.0

Note that I first executed the check-release.sh with maven 2.2.1 on the 
path, and it failed (on my Windows/Cygwin box).

With maven 3.0.3, it's ok.

Regards,
Cédric

Le 06/05/2013 15:01, Jukka Zitting a écrit :

Hi,

A candidate for the Jackrabbit 2.7.0 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/2.7.0/

The release candidate is a zip archive of the sources in:

 https://svn.apache.org/repos/asf/jackrabbit/tags/2.7.0/

The SHA1 checksum of the archive is 831007469ea8a4324a981daf9ac43390b62e25c3.

A staged Maven repository is available for review at:

 https://repository.apache.org/content/repositories/orgapachejackrabbit-006/

The command for running automated checks against this release candidate is:

 $ sh check-release.sh 2.7.0 831007469ea8a4324a981daf9ac43390b62e25c3

Please vote on releasing this package as Apache Jackrabbit 2.7.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit 2.7.0
 [ ] -1 Do not release this package because...

My vote is +1

BR,

Jukka Zitting

--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: preparing 2.6.1

[Cédric Damioli]

Hi Julian,

I'd like to see [1] backported in 2.6.1, but I'm wondering if this has 
been enough tested  in 2.7, if at all.

Or do you think it's too much for just a patch release ?

Regards,
Cédric

[1] https://issues.apache.org/jira/browse/JCR-3402

Le 07/05/2013 14:08, Julian Reschke a écrit :

Hi everybody,

With 2.4.4 on its way, I plan to start the release process for 2.6.1 
soonish.


The changes from 2.6 are listed over here: 
<https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324035&styleName=Text&projectId=10591&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED|7a7ef725f07040a77243e520ec8e8c5a1f74f2a5|lout>


If somebody feels that something is missing over there, that something 
else needs to be backported, and can think of another problem for not 
cutting a release right now, please speak up.


Best regards, Julian


--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: [VOTE] Release Apache Jackrabbit 2.4.4

[Cédric Damioli]

Hi,

The check-release script fails with following trace :

[INFO] 5. Compare svn tag with src zip contents
[INFO]
[INFO]Exporting 
https://svn.apache.org/repos/asf/jackrabbit/tags/2.4.4...

[INFO]Unzipping jackrabbit-2.4.4-src.zip...
[INFO]Comparing sources...
[INFO]
diff -b -r 
./target/jackrabbit-2.4.4/svn/jackrabbit-2.4.4/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalVersionManagerBase.java 
./target/jackrabbit-2.4.4/zip/jackrabbit-2.4.4/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalVersionManagerBase.java

701a702,708
>
> if (history == null) {
> String message = "Node " + node.getNodeId() + " has no 
version history";

> log.error(message);
> throw new VersionException(message);
> }
>
723a731,735
> if (pred == null) {
> String message = "Could not instantiate 
InternalVersion for nodeId " + value.getNodeId() + " (VHR + " + 
history.getId() + ", node " + node.getNodeId() + ")";

> log.error(message);
> throw new VersionException(message);
> }
729a742,748
>
> if (best == null) {
> String message = "Could not find 'best' predecessor node 
for " + node.getNodeId();

> log.error(message);
> throw new VersionException(message);
> }
>
[ERROR]   NOT OK: Tagged sources are different from those in the archive


I should have done something wrong but cannot see what ...

Regards,
Cédric

Le 06/05/2013 20:21, Julian Reschke a écrit :

A candidate for the Jackrabbit 2.4.4 release is available at:

   https://dist.apache.org/repos/dist/dev/jackrabbit/2.4.4/

The release candidate is a zip archive of the sources in:

http://svn.apache.org/repos/asf/jackrabbit/tags/2.4.4/

The SHA1 checksum of the archive is 
608ae0c4b61362e72cf95f41bd4bf9732a74a7c1.


A staged Maven repository is available for review at:


https://repository.apache.org/content/repositories/orgapachejackrabbit-010/ 



The command for running automated checks against this release 
candidate is:


$ sh check-release.sh 2.4.4 608ae0c4b61362e72cf95f41bd4bf9732a74a7c1

Please vote on releasing this package as Apache Jackrabbit 2.4.4.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit 2.4.4
[ ] -1 Do not release this package because...

--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: preparing 2.6.1

[Cédric Damioli]

Le 07/05/2013 15:43, Jukka Zitting a écrit :

Hi,

In general a big +1 to cutting 2.6.1. There are already 34 issues with
changes waiting to be released from the 2.6 branch. That's quite a lot
for a patch release, so the sooner we cut the release the better.

On Tue, May 7, 2013 at 3:31 PM, Julian Reschke  wrote:

On 2013-05-07 15:22, Cédric Damioli wrote:

I'd like to see [1] backported in 2.6.1, but I'm wondering if this has
been enough tested  in 2.7, if at all.
Or do you think it's too much for just a patch release ?

No opinion on that. Jukka maybe?

2.6.1 already contains quite a few non-bugfix changes with non-trivial
risk for regressions (looks like we should be a bit more conservative
here), so I'd be a bit hesitant to add too many new changes there.

How about we cut 2.6.1 now and follow up with 2.6.2 like a week after
that? That way we can limit the number of changes in individual patch
releases and allow people to more easily backtrack if problems do come
up.

I'm fine with that. We may even wait a little more than only one week :)

Regards,
Cédric

Re: [VOTE] Release Apache Jackrabbit 2.4.4

[Cédric Damioli]

Oops... sorry, I've missed that !

So here is my

[x] +1 Release this package as Apache Jackrabbit 2.4.4

Regards,
Cédric

Le 07/05/2013 17:54, Julian Reschke a écrit :

On 2013-05-07 17:36, Cédric Damioli wrote:

Hi,

The check-release script fails with following trace :

[INFO] 5. Compare svn tag with src zip contents
[INFO]
[INFO]Exporting
https://svn.apache.org/repos/asf/jackrabbit/tags/2.4.4...
[INFO]Unzipping jackrabbit-2.4.4-src.zip...
[INFO]Comparing sources...
[INFO]
diff -b -r
./target/jackrabbit-2.4.4/svn/jackrabbit-2.4.4/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalVersionManagerBase.java 

./target/jackrabbit-2.4.4/zip/jackrabbit-2.4.4/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalVersionManagerBase.java 


...


Yes, that's the corruption of the EU mirror of the Apache SVN (a 
commit is missing). See Jukka's comment:



Re: The svn tag issue; There's been some problems with svn.eu also
before, so nowadays I'm using an "140.211.11.4 svn.apache.org" entry
in my /etc/hosts file (it's C:\Windows\System32\drivers\etc\hosts on
Windows) to override the GeoDNS configuration of svn.apache.org. That
should help work around the issue noted by Alex until INFRA can fix
the problem.


Best regards, Julian



--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: preparing 2.6.1

[Cédric Damioli]

Le 07/05/2013 15:43, Jukka Zitting a écrit :

Hi,

In general a big +1 to cutting 2.6.1. There are already 34 issues with
changes waiting to be released from the 2.6 branch. That's quite a lot
for a patch release, so the sooner we cut the release the better.

On Tue, May 7, 2013 at 3:31 PM, Julian Reschke  wrote:

On 2013-05-07 15:22, Cédric Damioli wrote:

I'd like to see [1] backported in 2.6.1, but I'm wondering if this has
been enough tested  in 2.7, if at all.
Or do you think it's too much for just a patch release ?

No opinion on that. Jukka maybe?

2.6.1 already contains quite a few non-bugfix changes with non-trivial
risk for regressions (looks like we should be a bit more conservative
here), so I'd be a bit hesitant to add too many new changes there.

How about we cut 2.6.1 now and follow up with 2.6.2 like a week after
that? That way we can limit the number of changes in individual patch
releases and allow people to more easily backtrack if problems do come
up.

I'm fine with that. We may even wait a little more than only one week :)

Regards,
Cédric

Re: [VOTE] Release Apache Jackrabbit 2.6.2

[Cédric Damioli]

[INFO] 


[INFO] ALL CHECKS OK
[INFO] 



[X] +1 Release this package as Apache Jackrabbit 2.6.2


Regards,
Cédric

Le 21/05/2013 17:13, Jukka Zitting a écrit :

Hi,

A candidate for the Jackrabbit 2.6.2 release is available at:

 https://dist.apache.org/repos/dist/dev/jackrabbit/2.6.2/

The release candidate is a zip archive of the sources in:

 https://svn.apache.org/repos/asf/jackrabbit/tags/2.6.2/

The SHA1 checksum of the archive is 6a8807d36eb633130ca64960c7c11cf2fe841920.

A staged Maven repository is available for review at:

 https://repository.apache.org/content/repositories/orgapachejackrabbit-023/

The command for running automated checks against this release candidate is:

 $ sh check-release.sh 2.6.2 6a8807d36eb633130ca64960c7c11cf2fe841920

Please vote on releasing this package as Apache Jackrabbit 2.6.2.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

 [ ] +1 Release this package as Apache Jackrabbit 2.6.2
 [ ] -1 Do not release this package because...

My vote is +1

BR,

Jukka Zitting

--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com

Re: [IP CLEARANCE][VOTE] FileVault Contribution

[Cédric Damioli]

+1

Thanks !

Regards,
Cédric

Le 06/08/2013 02:40, Tobias Bocanegra a écrit :

Jackrabbit has received a donation of Adobe's FileVault that we'd like
to have as part of the contribs. the process is tracked under JCR-3612
and the signed source code is available here:

tar: 
people.apache.org:/home/tripod/contrib/filevault/filvault-asf-contrib-2013-07-08.tgz
sha1: 7bb22077a9ef44a1413d3f226cdc72a33995baf1

The IP Clearance document:
http://incubator.apache.org/ip-clearance/jackrabbit-filevault.html

A more detailed description of this contribution can be found in the JIRA issue:
https://issues.apache.org/jira/browse/JCR-3612

Note that we intend to place the code below
https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk
see JCR-3615 for more details.

Please vote to approve this contribution.  Lazy consensus applies: if
no -1 votes are cast

within the next 72 hours, the vote passes.

[ ] +1 Accept FileVault into Apache Jackrabbit
[ ] -1 Reject the contribution because...

regards, toby

--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Upgrade to Lucene 4 ?

[Cédric Damioli]

Hi,

I'm thinking about the potential migration of Jackrabbit to Lucene 4.

This represents quite a huge work, as many Lucene core API have 
completely changed between 3.x and 4.x
A quick test by replacing Lucene 3.x by Lucene 4.x shows almost 1000 
compilation problems.


So before beginning this, I was first wondering if it is even worth 
doing it.
The main benefits are obviously Lucene 4 new features and performance 
optimizations.
The main drawback is IMHO that for a given application, a Jackrabbit 
migration would also involve the migration of all Lucene-related code if 
any. Existing repositories should also be reindexed during migration.


So what do people think about this ?

And of course, if it seems a good idea, is there some committers around 
here volunteering to help me to do the job ? ;)


Best regards,

--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: Upgrade to Lucene 4 ?

[Cédric Damioli]

Hi,

Ok I see. Thanks for your feedback.
I most likely won't dive alone in this task, given that there's some 
really tricky parts.
On the other hand, Oak is currently not production-ready, so I have to 
stick to JR 2.x for now.


I'll probably look at a way to isolate Jackrabbit+Lucene in a separate 
ClassLoader to be able to run Lucene 4 code in the same application. 
BTW, did someone already achieve this (apart from OSGI-based solutions) ?


Regards,
Cédric


Le 09/10/2013 09:07, Marcel Reutegger a écrit :

Hi Cédric,

most of the development effort currently goes into Apache
Oak, which will replace Jackrabbit 2.x at some point. This means
Jackrabbit 2.x is pretty much in maintenance mode.

I don't want to discourage you from doing this, but I will probably
not have the time to help on this...

Regards
  Marcel


-Original Message-
From: Cédric Damioli [mailto:cdami...@apache.org]
Sent: Montag, 7. Oktober 2013 17:59
To: dev@jackrabbit.apache.org
Subject: Upgrade to Lucene 4 ?

Hi,

I'm thinking about the potential migration of Jackrabbit to Lucene 4.

This represents quite a huge work, as many Lucene core API have
completely changed between 3.x and 4.x
A quick test by replacing Lucene 3.x by Lucene 4.x shows almost 1000
compilation problems.

So before beginning this, I was first wondering if it is even worth
doing it.
The main benefits are obviously Lucene 4 new features and performance
optimizations.
The main drawback is IMHO that for a given application, a Jackrabbit
migration would also involve the migration of all Lucene-related code if
any. Existing repositories should also be reindexed during migration.

So what do people think about this ?

And of course, if it seems a good idea, is there some committers around
here volunteering to help me to do the job ? ;)

Best regards,

Re: Upgrade to Lucene 4 ?

[Cédric Damioli]

It's not an option for my current problems, where I should integrate 
already-partially-existing Lucene 4 code (especially using the facet and 
spatial modules) into a Jackrabbit-based product.


In a first approach I thought migrating Jackrabbit to Lucene 4. I've 
even thought about integrating faceting directly in Jackrabbit via the 
Lucene  facet module.
But since the migration is not an option neither, I'll dive into 
ClassLoader isolation. It's quite funny as well :)


Regards,
Cédric

Le 09/10/2013 12:20, Torgeir Veimo a écrit :

How about using an external elasticsearch or solr instance instead of
lucene for your indexing needs?

On 9 October 2013 18:21, Cédric Damioli  wrote:

Hi,

Ok I see. Thanks for your feedback.
I most likely won't dive alone in this task, given that there's some really
tricky parts.
On the other hand, Oak is currently not production-ready, so I have to stick
to JR 2.x for now.

I'll probably look at a way to isolate Jackrabbit+Lucene in a separate
ClassLoader to be able to run Lucene 4 code in the same application. BTW,
did someone already achieve this (apart from OSGI-based solutions) ?

Regards,
Cédric


Le 09/10/2013 09:07, Marcel Reutegger a écrit :


Hi Cédric,

most of the development effort currently goes into Apache
Oak, which will replace Jackrabbit 2.x at some point. This means
Jackrabbit 2.x is pretty much in maintenance mode.

I don't want to discourage you from doing this, but I will probably
not have the time to help on this...

Regards
   Marcel


-Original Message-
From: Cédric Damioli [mailto:cdami...@apache.org]
Sent: Montag, 7. Oktober 2013 17:59
To: dev@jackrabbit.apache.org
Subject: Upgrade to Lucene 4 ?

Hi,

I'm thinking about the potential migration of Jackrabbit to Lucene 4.

This represents quite a huge work, as many Lucene core API have
completely changed between 3.x and 4.x
A quick test by replacing Lucene 3.x by Lucene 4.x shows almost 1000
compilation problems.

So before beginning this, I was first wondering if it is even worth
doing it.
The main benefits are obviously Lucene 4 new features and performance
optimizations.
The main drawback is IMHO that for a given application, a Jackrabbit
migration would also involve the migration of all Lucene-related code if
any. Existing repositories should also be reindexed during migration.

So what do people think about this ?

And of course, if it seems a good idea, is there some committers around
here volunteering to help me to do the job ? ;)

Best regards,




--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: [VOTE] Release Apache Jackrabbit 2.6.4

[Cédric Damioli]

[INFO] 


[INFO] ALL CHECKS OK
[INFO] 





 [X] +1 Release this package as Apache Jackrabbit 2.6.4




Regards,
Cédric

Re: [VOTE] Release Apache Jackrabbit 2.4.5

[Cédric Damioli]

Hi Jukka,

The check-release.sh fails with the following message:

[INFO] 5. Compare svn tag with src zip contents
[INFO]
[INFO]Exporting 
https://svn.apache.org/repos/asf/jackrabbit/tags/2.4.5...

[INFO]Unzipping jackrabbit-2.4.5-src.zip...
[INFO]Comparing sources...
[INFO]
diff -b -r 
./target/jackrabbit-2.4.5/svn/jackrabbit-2.4.5/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalVersionManagerBase.java 
./target/jackrabbit-2.4.5/zip/jackrabbit-2.4.5/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/version/InternalVersionManagerBase.java

701a702,708
>
> if (history == null) {
> String message = "Node " + node.getNodeId() + " has no 
version history";

> log.error(message);
> throw new VersionException(message);
> }
>
723a731,735
> if (pred == null) {
> String message = "Could not instantiate 
InternalVersion for nodeId " + value.getNodeId() + " (VHR + " + 
history.getId() + ", node " + node.getNodeId() + ")";

> log.error(message);
> throw new VersionException(message);
> }
729a742,748
>
> if (best == null) {
> String message = "Could not find 'best' predecessor node 
for " + node.getNodeId();

> log.error(message);
> throw new VersionException(message);
> }
>
[ERROR]   NOT OK: Tagged sources are different from those in the archive

Any idea ?

Regards,
Cédric

Re: [VOTE] Release Apache Jackrabbit 2.10.2

[Cédric Damioli]

[INFO] 


[INFO] ALL CHECKS OK
[INFO] 




[X] +1 Release this package as Apache Jackrabbit 2.10.2
[ ] -1 Do not release this package because...


Cédric

Re: [VOTE] Release Apache Jackrabbit 2.10.3

[Cédric Damioli]

[INFO] 


[INFO] ALL CHECKS OK
[INFO] 



Le 09/05/2016 10:06, Amit Jain a écrit :


[X] +1 Release this package as Apache Jackrabbit 2.10.3

Re: September report: draft for review

[Cédric Damioli]

Le 11/09/2017 à 15:54, Michael Dürig a écrit :


Hi,

I've assembled a preliminary board report for September:

https://wiki.apache.org/jackrabbit/Board%20Report%20September%202017

Please have a look at let me know of any omissions or corrections. I 
plan to submit it next Wednesday morning CET.


Michael



+1

--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: [VOTE] Release Apache Jackrabbit 2.16.0

[Cédric Damioli]

Hi,

I just notice that since revision 23033, the check-release.sh now rely 
on the "compgen" command, which is a builtin bash command but not 
available in basic sh.
Is it intentional ? In which case we should force the use of bash in the 
script header.


BTW, what is the good JIRA project to create such an issue related to 
the release process ?


Regards,
Cédric


Le 21/11/2017 à 07:23, Julian Reschke a écrit :

A candidate for the Jackrabbit 2.16.0 release is available at:

    https://dist.apache.org/repos/dist/dev/jackrabbit/2.16.0/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.16.0/

The SHA1 checksum of the archive is 
a29fa617e671fbb91cf8a649c342e5a9f9859f39.


A staged Maven repository is available for review at:

    https://repository.apache.org/

The command for running automated checks against this release 
candidate is:


    $ sh check-release.sh 2.16.0 a29fa617e671fbb91cf8a649c342e5a9f9859f39

Please vote on releasing this package as Apache Jackrabbit 2.16.0.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

    [ ] +1 Release this package as Apache Jackrabbit 2.16.0
    [ ] -1 Do not release this package because...

Best regards, Julian


--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: [VOTE] Release Apache Jackrabbit 2.16.0

[Cédric Damioli]

[INFO] 


[INFO] ALL CHECKS OK
[INFO] 




    [X] +1 Release this package as Apache Jackrabbit 2.16.0
    [ ] -1 Do not release this package because...



Cédric

Re: March report: draft for review

[Cédric Damioli]

+1

Le 13/03/2018 à 14:21, Michael Dürig a écrit :

Hi,

I've assembled a preliminary board report for March:

https://wiki.apache.org/jackrabbit/Board%20Report%20March%202018

Please have a look at let me know of any omissions or corrections. I
plan to submit it next Wednesday morning CET.

Michael


--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: Jackrabbit Lucene Upgrade ?

[Cédric Damioli]

I remember having tried to modify Jackrabbit core to update Lucene version.
I eventually gave up due to complexity of the work.
Jackrabbit's SearchIndex class is *very* imbricated with Lucene 3.6 code

As a workaround, I shadowed the Lucene's 3.6 lib by changing its package 
name, so that it may get along with a more recent version.
And then after a while, I moved toward a Solr server, and then had not 
the need of shadowing anymore, so I put back the original 3.6 lib.


My 2 cents,
Cédric

Le 12/05/2020 à 14:03, Torgeir Veimo a écrit :

I understand what you'd like to do, but there's a reason it hasn't
happened yet. It was requested many years ago, and it's not easy.

On Tue, 12 May 2020 at 21:28, KÖLL Claus  wrote:

Hi !

If i understand you right i have not the problem to use 2 different versions of 
lucene in the same project.
My goal is to update the lucene library in jackrabbit itself.

This means also maybe a migration path or a rebuild (that would be ok for me 
personally) to a newer lucene index inside the the jackrabbit repository.

greets
claus





--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: AW: Jackrabbit Lucene Upgrade ?

[Cédric Damioli]

No, I gave up making Jackrabbit compatible with a newer Lucene version.
But then, I had to be able to work with a modern Lucene in the rest of 
my app.


I simply renamed all lucene packages in something like 
"org.apache.jackrabbit.org.apache.lucene", modified all related 
Jackrabbit classed and all worked like a charm.
And then I could have an official Lucene 4+ for my application, not 
conflicting with Jackrabbit's bundled Lucene 3.6
Of course, this operation should be repeated each time you want to 
upgrade to a newer Jackrabbit version, and Jackrabbit itself continue to 
be compatible with Lucene 3.6 only.


I also tried to play with classloading isolation, so that I could have 
Lucene 3.6 next to Lucene 4+, the first only used by Jackrabbit and the 
more recent for other classes. It was fun to develop and actually 
worked, but we eventually migrate our code to use an external Solr 
server so don't need to upgrade Lucene anymore.


Cédric

Le 13/05/2020 à 07:34, KÖLL Claus a écrit :

Hi Cédric


As a workaround, I shadowed the Lucene's 3.6 lib by changing its package
name, so that it may get along with a more recent version.
And then after a while, I moved toward a Solr server, and then had not
the need of shadowing anymore, so I put back the original 3.6 lib.

Can you explain a little bit more your way. What do you mean with shadowed the 
Lucene's 3.6 lib ?
Do you have integrated Solr into jackrabbit-core ?

thanks many !

Claus


--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: [VOTE] Release Apache Jackrabbit 2.20.1

[Cédric Damioli]

Any hint of why I keep having

[INFO] 2. Check for the presence of the staged release candidate
[INFO]
check-release.sh: 120: compgen: not found
[ERROR]   NOT FOUND: jackrabbit-2.20.1-src.zip

when trying to check the release ?

Of course, it is a fresh checkout and jackrabbit-2.20.1-src.zip is 
actually really present.


Cédric

Le 03/06/2020 à 09:16, Julian Reschke a écrit :

A candidate for the Jackrabbit 2.20.1 release is available at:

    https://dist.apache.org/repos/dist/dev/jackrabbit/2.20.1/

The release candidate is a zip archive of the sources in:

https://svn.apache.org/repos/asf/jackrabbit/tags/jackrabbit-2.20.1/

The SHA1 checksum of the archive is 
3a4cd37494d98c5cf86429752c9cc1a65e9bf881.


A staged Maven repository is available for review at:

    https://repository.apache.org/

The command for running automated checks against this release 
candidate is:


    # run in SVN checkout of 
https://dist.apache.org/repos/dist/dev/jackrabbit/

    $ sh check-release.sh 2.20.1 3a4cd37494d98c5cf86429752c9cc1a65e9bf881

Please vote on releasing this package as Apache Jackrabbit 2.20.1.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

    [ ] +1 Release this package as Apache Jackrabbit 2.20.1
    [ ] -1 Do not release this package because...

Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit 2.20.1

[Cédric Damioli]

Le 04/06/2020 à 17:02, Julian Reschke a écrit :

On 04.06.2020 15:44, Cédric Damioli wrote:

Any hint of why I keep having

[INFO] 2. Check for the presence of the staged release candidate
[INFO]
check-release.sh: 120: compgen: not found
[ERROR]   NOT FOUND: jackrabbit-2.20.1-src.zip

when trying to check the release ?

Of course, it is a fresh checkout and jackrabbit-2.20.1-src.zip is
actually really present.

Cédric


Is this with bash running the script?

Yes
Strange enough ...

Re: [VOTE] Release Apache Jackrabbit 2.20.1

[Cédric Damioli]

Le 05/06/2020 à 12:04, Julian Reschke a écrit :

On 05.06.2020 11:53, Cédric Damioli wrote:



Le 04/06/2020 à 17:02, Julian Reschke a écrit :

On 04.06.2020 15:44, Cédric Damioli wrote:

Any hint of why I keep having

[INFO] 2. Check for the presence of the staged release candidate
[INFO]
check-release.sh: 120: compgen: not found
[ERROR]   NOT FOUND: jackrabbit-2.20.1-src.zip

when trying to check the release ?

Of course, it is a fresh checkout and jackrabbit-2.20.1-src.zip is
actually really present.

Cédric


Is this with bash running the script?

Yes
Strange enough ...


Well, it certainly looks as if the shell running the script doesn't
support "compgen" (remember 
https://issues.apache.org/jira/browse/JCR-4220).



This ticket was even opened by myself, but I didn't remember :)
But since then and the revision r23233, the check-release.sh forces the 
use of Bash, so I assume this is not the same issue ...


Nevertheless, I checked the release manually in the meanwhile so here is 
my +1


Regards,
Cédric

--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

Re: [VOTE] Switch Jackrabbit trunk to require Java 11

[Cédric Damioli]

+1

Cédric

Le 16/01/2024 à 16:05, Julian Reschke a écrit :

On 12.01.2024 16:15, Julian Reschke wrote:

On 08.01.2024 09:25, Julian Reschke wrote:

Hi there.

In the upcoming weeks, I'd like to discuss the roadmap for Jackrabbit.

Things that come to mind are:

- require Java 11 (that will allow us to update a few more
dependencies), and also support changes in the Jackrabbit API (which 
now

lives in Oak, which switched to Java 11 ca one year ago)
...


FWIW, I opened  for the
switch to Java 11, and will follow up with a PR shortly.


I'm planning to make the switch on Friday.

The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

    [ ] +1 Switch Jackrabbit trunk to require Java 11
    [ ] -1 Do not switch because...

Best regards, Julian