Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <24019194.1153981935320.JavaMail.jira@brutus>
Date: Wed, 26 Jul 2006 23:32:15 -0700 (PDT)
From: "Jukka Zitting (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-442) Implement a backup tool
In-Reply-To: <653998.1148469389882.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/JCR-442?page=comments#action_12423777 ] 
            
Jukka Zitting commented on JCR-442:
-----------------------------------

Thanks for the update!

> c/ Maybe we should add an external tool session instead of sharing a session with JR "internals". What do you think?

I'd go for that unless there is something special in the SystemSession class that's needed for the backup.

> d/ This is what I did first, but I use it in BackupConfigurationParser and it is already used in RepositoryConfigurationParser.
> It is why it's there. (for now I don't use the PM but this might change). I suggest to leave a TODO on this point and see if it's
> still needed there at the end of the project. Do you agree?

Not really. Code reuse should be the result of the design, not the other way around. I think it's better for now if you just duplicate the parsePersistenceManagerConfig() method in BackupConfigurationParser instead of pushing it higher, especially since the method is so small.

> e/ At first I put it in my backup class and then I thought it could be useful to others. It's why it's there. As you can see,
> I can put it in my backup class if needed but this functionnality can be needed also by other application. What do you think?

OK. I think it's better to keep the functionality in the backup contrib for now and move it to core when we find another use case. It's another case of code reuse driving the design, which I'm a bit worried about. I don't think it's worth it to expand the public interface of the class with a utility method just for a single client that can achieve the same result using the other methods.

Could you still fix these issues (or counter my arguments :-) before I commit your changes?

> Implement a backup tool
> -----------------------
>
>                 Key: JCR-442
>                 URL: http://issues.apache.org/jira/browse/JCR-442
>             Project: Jackrabbit
>          Issue Type: New Feature
>            Reporter: Jukka Zitting
>         Attachments: jackrabbit-1.patch.txt, patch, patch-backup-060716.txt, patch-backup-060719.txt, patch-backup-060725.txt, patch-backup-060726.txt, patch-jackrabbit-060716.txt, patch-jackrabbit-060718.txt, patch-jackrabbit-060725.txt, patch-jackrabbit-060726.txt, patch.txt, patch.txt, patch.txt, patch.txt
>
>
> Issue for tracking the progress of the Google Summer of Code project assigned to Nicolas Toper.  The original project requirements are:
> "Implement a tool for backing up and restoring content in an Apache Jackrabbit content repository. In addition to the basic content hierarchies, the tool should be able to efficiently manage binary content, node version histories, custom node types, and namespace mappings. Incremental or selective backups would be a nice addition, but not strictly necessary."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira