Refactor the navigation bar:

1: The terminology "Knowledge Bases" needs to be configurable. And it needs to be pre-configured with pre-installed perspectives, for example Drools perspective and SOA perspective. In Drools perspective, we will continue to call it "Knowledge Bases". In SOA perspective, I am not sure yet what terminology to use, maybe "Service Bases"? Anyway this wont be a big issue. The name is configurable, so its the choice of end users to decide the best term to use based on the context.

Question: If the name is configurable, and assume the name configuration is stored in a file somewhere, how can we make sure this works with i18n?

2: The terminology "Packages" needs to be configurable. And it needs to be pre-configured with pre-installed perspectives.  In Drools perspective, we may want to rename "Packages" to "Modules". In SOA perspective, we may call it "Services".

3: Supported asset types need to be configurable. And it needs to be pre-configured with pre-installed perspectives. Following info are required to configure asset types:

1. What asset types are supported in this module/package(or container/folder or whatever term you want to use) for this specific perspective.
2. The type name.
3. Type icon
4. Associated asset editor. So that when you click the asset, we know which editor to show.

As there are always new types ppl want to support, we should allow users to register new asset types. They need to provide following information: name, icon, asset editor. The process of registering new asset types should be done through UI.

Update: Done (GUVNOR-1494). Below is an example how we configure asset editors for Drools perspective in drools-asseteditors.xml:

<?xml version="1.0" encoding="UTF-8"?>

<asseteditors>

    <!--  business rules group   -->  

    <asseteditor>

        <class>org.drools.guvnor.client.modeldriven.ui.RuleModeller</class>

        <format>brl</format>

        <icon>images.ruleAsset()</icon>

        <title>constants.BusinessRuleAssets()</title>   

    </asseteditor>

    <asseteditor>

        <class>org.drools.guvnor.client.ruleeditor.RuleValidatorWrapper</class>

        <format>dslr</format>

        <icon>images.ruleAsset()</icon>

        <title>constants.BusinessRuleAssets()</title>   

    </asseteditor>

    ......   

</asseteditors>

All asset editors need to have a constructor conforms to this format:

    public RuleModeller(RuleAsset asset,

                                     RuleViewer viewer,

                                     ClientFactory clientFactory) {

     }

4: All perspectives need a Global Area. Guvnor already has Global Area, no change needed.

5: At the moment, "QA" is specific to Drools. We will keep it as part of Drools perspective, which means you wont see a QA panel in SOA perspective.

6: We wont need Package snapshot anymore when this story is done: https://issues.jboss.org/browse/GUVNOR-1182

Update: Done

Refactor Package Editor

Current Package Editor:

All packages (the alternative to the terminology of "Packages" is "Modules/Services/Containers/Folders...") will have two editors:

1. Generic editor: This is the editor that contains non-domain specific information.  Includes:

• Non-domain-specific actions: Copy/Rename/Archive
• Metadata widget:Package needs a metadata widget similar to asset has:

Define custom metadata(tags):

• Description: Currently Guvnor does not have a Description section for package. Though I don't see the reason why Package does not need a description.
• Discussion: Currently Guvnor does not have a Discussion section for package. We will add discussion widget to package editor.
• Dependant:Who depend on this module.
• Dependencies:

• Lifecycle Management:

Customize lifecycle definition:

• Feed/URLs:

Versions feed: http://host:portnumber/repository/packages/testPackage1/versions

Discussions feed:

http://host:portnumber/repository/packages/testPackage1/discussions

Assets feed: This is for monitoring the change of assets that are contained by this package.

http://host:portnumber/repository/packages/testPackage1/assets

Package Atom entry:

http://host:portnumber/repository/packages/testPackage1

2. Domain specific editor: This is the editor that contains domain specific information.  In Drools perspective, it includes following sections:

• Drools package specific actions:
• Package configuration.
• Package builder: 

Module builder (package builder) is a plugable mechanism that knows how to build a module for a specific domain (Drools/Jboss ESB etc). The builder knows how to validate, how combine and assembly assets, how to generate the deployment unit (jar/war etc) for the target domain.

• Drools package specific links: show documentation/show source/package binary/test scenarios etc.
• In the future, we will have a section called package deployment. The idea is that this section shows which servers/containers this package has been deployed. Runtime statistics. Deploy/Undeploy.

Update: Done (GUVNOR-1279)

Refactor Asset Editor

Current asset editor:

All assets will have two editors:

1. Generic editor: This is the editor that contains non-domain specific information.  Includes:

• Non-domain-specific actions: Save/Delete/Copy/Promote to Global
• MetaData editor
• Description
• Discussion
• Dependant: Who depend on this asset.
• Dependencies: Not sure about this yet. To make things simple, we do not want to allow assets depend on assets, at least not on the build level. By saying "not on the build level." I mean the inter-asset dependency relationship is not used by module builder. Though we can still have a dependency section in asset editor so that we can do change impact analysis (it is called soft dependency, see http://community.jboss.org/docs/DOC-16350 for details).
• Lifecycle Management:
• Feed/URLs:

2. Asset specific editor: Each asset may have its own specific editor.

Update: Done (GUVNOR-1279)

Perspectives:

Besides pre-installed perspectives (Drools/SOA etc), users can create/define their own perspective through UI. Perspective definition can be exported and imported as a certain format of file. Basically it works like below:

https://issues.jboss.org/browse/GUVNOR-1125

Register/Install new asset types:

This is done through UI.

1. There is a view to display already installed asset types for the current perspective. Information displayed includes:

• Asset type
• Asset icon
• Asset specific editor
• Asset specific "New Asset" widget

2. Type name, icons, java classes etc can probably be archived into a jar. The process of registering/installing new asset type is done by  uploading a jar file.

Development path proposed:

As we will be working on the drools-guvnor master, to not break anything, I propose we take a step-by-step approach:

Step 1: Create a generic Asset editor. Move anything that is not asset-specific to this editor. Then move anything asset specific to the asset specific editor. So one asset normally consists of two editor views.

Step 2: Create a generic Package editor (Module editor). Move anything that is not domain-specific (Drools package specific) to this editor. Then move anything specific to Drools package to a Drools package specific editor. So one Package normally consists of two editor views.

Step 3: Investigate how to write a custom asset editor and how to plug it into Guvnor.

Step 4: Investigate how module builder works. Extract anything specific to Drools package builder to a Drools module builder. Investigate how to plug a module builder into Guvnor.

Step 5: Investigate how to define and customize a perspective (essentially it means how to customize the navigation bar). Extract Drools specific code to a Drools perspective.