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 <[email protected]> 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
