Timeline for a FileVault release

[Robert Munteanu <ro...@apache.org>]

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

Re: Timeline for a FileVault release

[Tobias Bocanegra <tr...@apache.org>]

Hi Ate,

On Tue, Sep 24, 2013 at 3:59 PM, Ate Douma <at...@douma.nu> 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 <ro...@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
>>>
>

[0] https://issues.apache.org/jira/browse/JCR-3670

Re: Timeline for a FileVault release

[Ate Douma <at...@douma.nu>]

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 <ro...@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
>>

Re: Timeline for a FileVault release

[Robert Munteanu <ro...@lmn.ro>]

Hi Toby,

For now we're working on a branch, so not having a FileVault release
is not a hard blocker. However, it would be good to have a release in
order to move our work back to trunk and be able to make a first
release.

Thanks,

Robert

On Mon, Sep 23, 2013 at 7:24 AM, Tobias Bocanegra <tr...@apache.org> 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
>
> On Fri, Sep 6, 2013 at 2:32 AM, Robert Munteanu <ro...@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
>>



-- 
Sent from my (old) computer

Re: Timeline for a FileVault release

[Tobias Bocanegra <tr...@apache.org>]

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

On Fri, Sep 6, 2013 at 2:32 AM, Robert Munteanu <ro...@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
>