Hi Ate, On Tue, Sep 24, 2013 at 3:59 PM, Ate Douma <[email protected]> wrote: > 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 :) Great to hear!
> 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. Unfortunately, filevault's documentation was always a bit short even during day/adobe time. It is still one of my open tasks to gather all the documentation there is and consolidate it. > 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 :) great. > 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. the 1.0 config files can be removed. the nodetype namespaces can be renamed. but as you mentioned below, there are some backward compatibility concerns (which we can solve, I'm sure). > 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. of course. I created bug [0] to track this. > 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! the current version is very clumsy to use, as it tries to mimic a SVN like behavior. it is designed for multiple developers work against 1 central JCR repository. Over the years we figured that this is rarely the mode of development and usually each dev has a repo running on his computer. One idea is to use a more simplified version of how to sync repository content - probably more fsync than a SVN approach. Regards, Toby > > 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 >>> > [0] https://issues.apache.org/jira/browse/JCR-3670
