jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Timeline for a FileVault release
Date Tue, 24 Sep 2013 22:59:30 GMT
On 09/23/2013 07:24 AM, Tobias Bocanegra wrote:
> Hi Robert,
>
> sorry for the delay - I was on vacation. But I was also waiting for
> the new JIRA project for filevault to be created. apparently it takes
> some time :-)
> I will go ahead and create the 3.0 release asap this week.
>
> Regards, Toby

Hi Toby, and others interested in FileVault!

I've been playing a bit with FileVault the past few weeks and I like it :)

There are still several rough edges for sure, and the lack of documentation 
doesn't make it easy to figure out how everything works (I certainly don't 
understand everything yet). But it definitely looks like it can become useful 
for us in due time. Note: I'm working for Hippo.

I expect we'll shortly will start investigating FileVault more seriously, and 
see how we can leverage and integrate it for our own purposes.
And very likely come up with some contributions and patches :)

Concerning the current code-base, although maybe not relevant yet for the 
intended first release, I did notice there is still quite a bit of CQ5/CRX 
specific behavior and configuration in place.
Most of it doesn't really do any 'harm' in a non-CQ5/CRX context, Like for 
example the CRX specific Node types in (vault-core) DefaultNodeTypes.java, or 
the default configurations in the (vault-core) defaultConfig-1.[0|1].xml files.

But in some other areas I think they might be(come) more than a nuisance, like 
for example:
- default/fallback "crx.default" workspace name used in (vault-core) 
AggregatManagerImpl.java
- default/fallback "/crx/server" prefix used in (vault-core) RepositoryAddress.java
- "/var/crxpatches" patchParentPath in (vault-core) ImportOptions.java
- CRX specific default URI/WPS constants in (vault-cli) VaultFsApp.java
- CRX specific constants in (vault-vlt) Sync.java
- and a few more (just search for CQ or CRX, case-insensitive)

As we don't use FileVault yet, none of this is critical for us right now, but I 
think it would be good if the Adobe/Day repository specifics can be made 
optional or refactored out.

I certainly can see some of these might lead to non-trivial changes, as they 
might potentially break existing behavior in a CQ5/CRX specific context if not 
done carefully, and I'm definitely willing to help and for example propose patches.

Like I said: for us this is not critical yet, but I think it is important for 
the project to be more repository agnostic :)

And of course I'm very interested to hear more details about other 
features/changes/simplifications/etc. you hinted about before...
I'm definitely willing to chime in and further collaborate where feasible!

Kind regards, Ate

>
> On Fri, Sep 6, 2013 at 2:32 AM, Robert Munteanu <rombert@apache.org> wrote:
>> Hi,
>>
>> In the Sling IDE tooling we're using FileVault to transfer content from
>> the workspace to the JCR repository and back.
>>
>> We're getting close to a releasable state with the current FileVault, as
>> donated to the Jackrabbit project. However, we can't release an initial
>> version of our IDE tooling since there is no FileVault release.
>>
>> It would be great if someone could handle an initial FileVault release.
>> If there's any help that I can give with that, please let me know.
>>
>> Thanks,
>>
>> Robert
>>


Mime
View raw message