yes, I know that - but if you don't try and export/import via JCR
then
you can do what you want.
The "correct" JCR way to have multiple regions (QA, DEV etc) is
actually Workspaces if you read the JCR spec - it is designed for this
in mind (and allows this to some extent) - but not sure how that helps
with per-package stuff.
IS this exporting and importing a package to a completely separate
guvnor instance?
Yes, a separate Guvnor instance. This is because I believe, some
companies run different instances of Guvnor for different life cycles,
eg, one instance of Guvnor for testing stage, one instance of Guvnor for
production stage.
if so - JCR will not be able to be used - it will have to be a custom
file format which can be imported in the other and and adjusted.
On Fri, Aug 6, 2010 at 5:12 PM, Jervis Liu <jliu(a)redhat.com
<mailto:jliu@redhat.com>> wrote:
Michael Neale wrote:
> well for category things - it could be that if a category doesn't
> exist in the target "space" then it is created, if not, it is used.
> There are other things though, which are interlinked - but the same
> issue you bring up applies (which is why this wasn't done a
while back).
>
> So a simple JCR partial export won't really do - needs to be a bit
> more programmatic than that.
>
> The question is - in the target space - do we want to create the
> missing things, or remove the links from them as part of the export
> etc...
>
> So if RuleA depends on categoryX and categoryY, but only categoryX
> (same name) exists in the target place, then do we create categoryY
> there, or strip it?
>
Things are a little bit more complex than this. The category (and
other
things like status etc) attribute is not a plain text value, its a
reference type, essentially its a UUID point to the category
nodes. This
UUID value is always invalid in another repository.
> On Fri, Aug 6, 2010 at 4:44 PM, Jervis Liu <jliu(a)redhat.com
<mailto:jliu@redhat.com>
> <mailto:jliu@redhat.com <mailto:jliu@redhat.com>>> wrote:
>
> Hi,
>
> I am currently evaluating a Guvnor feature request which is to
> implement
> package based import/export. The idea is to use this feature
to move a
> rule package from the DEV repo to QA to Stage to the Prod
repo. For
> details please check
https://jira.jboss.org/browse/GUVNOR-311. My
> initial investigation shows that it is not possible to do a
single
> package import/export technically. A single package in Guvnor
> repository
> is never a self-contained unit. For example, every asset
under the
> package has a mandatory attribute which is a reference link to
> category
> information. In short, package can not be exported/imported
as long as
> it contains references to entities outside package.
>
> There are two things I would like to ask for your opinions.
> Firstly, can
> you think of any way to implement this import/export feature?
> Personally
> I dont see how this can be done. This is similar to relational
> database,
> generally it is impossible to export and import data from/to
a single
> non-isolated table in database. Or sometimes it is possible
but with
> extensive care normally involved in manual work to deal with
dirty
> data.
> In our case, one example of dirty data is category, but what
can we do
> with category information, we discard package information
when we do
> package export?
>
> Secondly, if such feature can not be implemented, can we
figure out a
> different way to help users to better manage the life cycle
in Guvnor?
> The current version of Guvnor is not very strong on this
part yet. If
> you are a Guvnor user or you have experience of using similar
> products,
> how did you manage and how do you want to manage the
lifecycle of
> assets
> in your repository?
>
>
> Thanks,
>
> Jervis
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
<mailto:rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
>
> --
> Michael D Neale
> home:
www.michaelneale.net <
http://www.michaelneale.net>
<
http://www.michaelneale.net>
> blog:
michaelneale.blogspot.com
<
http://michaelneale.blogspot.com> <
http://michaelneale.blogspot.com>
>
------------------------------------------------------------------------
>
> _______________________________________________
> rules-dev mailing list
> rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Michael D Neale
home:
www.michaelneale.net <
http://www.michaelneale.net>
blog:
michaelneale.blogspot.com <
http://michaelneale.blogspot.com>
------------------------------------------------------------------------
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev