In which case it isn't just cloning things so much as migrating for management purposes... so perhaps not all the metadata that is in JCR is require - its all about the rules themselves for that purpose?

On Mon, Aug 9, 2010 at 10:21 AM, Jervis Liu <jliu@redhat.com> wrote:

On 2010/8/6 19:37, Nimesh Muley wrote:
> Hi,
>
> In my experience having implemented this functionality, there is much more to import-export of rules than what meets the eye.
>
> When we look at Dev - QA not everything goes. This is purely based upon what is it that we are releasing to QA and only those many rules / configurations would need to be sent across.
>
> Then we ship from QA to client site (maybe directly to staging or pre-staging depending upon how much testing is being done at client side). During this time we would typically export everything from what is QA passed to client. The challenges faced during this transition increases manifold when the "business" user is allowed to define a rule (apart from developers). SO what this means is that in the destination repository there may be additional rules than what we are shipping with. But the object structure is new one. This is not related to drools per se but nevertheless is an issue faced during export-import.
>
> Lastly we move from staging to production. Here the export and import is now a business user choice. Typically the business users would prepare some data on the staging and run some business transactions to test that setup. Once they are happy they would want to migrate the entire data setup (along with rules). E.g. if there are 3 new banking products setup in staging and out of those we would want to export only one product (it's data in different modules and also rules associated with it) to the production box. The choice of rekeying the entire data and rules does not go down well with the business user as it may happen that there may be a mistake during rekeying of data.
>
> To summarize the additional challenges faced during export - import of
> Dev to QA - Need ability to select based on package / flags (authorized or marked for moving to QA).
> QA to Staging - Need ability to select based on package / flags (authorized or marked for moving to Staging).
> Staging to Production - Need API for developers to state which rules would be exported. The list would be picked up based on the configuration UI that is exposed by the application for exporting functional entities.
>
> If alternatively a refactoring tool can be provided to accommodate object structure changes it would be great. This is needed only when rules are defined by business user and hence the developer is not aware of them.
>
> p.s. Although this is dev list, I thought a user's point of view may be helpful in development of this feature.

Nimesh, this is exactly what we want to hear from. Thanks.

Jervis

> Thanks.
> Regards,
> - Nimesh
>
> -----Original Message-----
> From: rules-dev-bounces@lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Michael Neale
> Sent: Friday, August 06, 2010 4:41 PM
> To: Rules Dev List
> Subject: Re: [rules-dev] Package based import/export in Guvnor
>
> Good points and ideas. I think it is a valuable feature.
>
> On Friday, August 6, 2010, Anstis, Michael (M.)<manstis1@ford.com> wrote:
>> I'd be more surprised if companies used the same instance! Separation of
>> PROD, QA and DEV data seems to be at the heart of many organisations for
>> auditing, security, backup and other requirements. It gives lots of
>> "internal control" people lots of jobs.
>>
>> You could consider building a denormlalised tree in JCR representing the
>> export; export with JCR, import de-normalised tree into the target and
>> then worry about merge\normalisation as part of the import API. Keeps
>> the "public" data JCR compliant and the described difficulties internal.
>> Might be a better option than proprietary file format but the temporary
>> growth in the repository could be a concern... You could consider the
>> use of a transient "secondary" repository for the
>> denormalisation/normalisation process too...
>>
>> -----Original Message-----
>> From: rules-dev-bounces@lists.jboss.org
>> [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Jervis Liu
>> Sent: 06 August 2010 09:32
>> To: Rules Dev List
>> Subject: Re: [rules-dev] Package based import/export in Guvnor
>>
>> Michael Neale wrote:
>>> 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@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@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
>>> >
>
> --
> Michael D Neale
> home: www.michaelneale.net
> blog: michaelneale.blogspot.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
> MASTEK LTD.
> In the US, we're called MAJESCOMASTEK
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Opinions expressed in this e-mail are those of the individual and not that of Mastek Limited, unless specifically indicated to that effect. Mastek Limited does not accept any responsibility or liability for it. This e-mail and attachments (if any) transmitted with it are confidential and/or privileged and solely for the use of the intended person or entity to which it is addressed. Any review, re-transmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. This e-mail and its attachments have been scanned for the presence of computer viruses. It is the responsibility of the recipient to run the virus check on e-mails and attachments before opening them. If you have received this e-mail in error, kindly delete this e-mail from desktop and server.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev

--
Michael D Neale
home: www.michaelneale.net
blog: michaelneale.blogspot.com