Details
-
Type:
Task
-
Status: Resolved (View Workflow)
-
Priority:
Critical
-
Resolution:
Won't Fix
-
Affects Version/s: drools-5.1
-
Fix Version/s: drools-6.0.0.Alpha1
-
Labels:None
Description
All classes/resources under the client/public package go to drools-guvnor-gwtclient.
The drools-guvnor-gwtclient pom.xml
- is of type war
- has only the gwt dependencies
All classes under the server package go to drools-guvnor(-server)
The drools-guvnor(-server) pom.xml
- is of type war
- has a dependency on drools-guvnor-gwtclient (= war overlay!)
- has dependencies on drools-core, drools-compiler (so on jdt too), ...
What do we do with drools-ide-common and drools-factconstraints? Split them up to, or simply move the client package code into drools-guvnor?
Where will the drools-ide-common and drools-factconstraints GWT modules be reused, besides in Guvnor?
Gliffy Diagrams
Issue Links
- blocks
-
GUVNOR-1538
Do not include gwt-dev in the guvnor-webapp classpath
-
- Resolved
-
-
GUVNOR-694
Guvnor: Use gwt-maven-plugin and remove the gwt compilation part from the ant script
-
- Resolved
-
- is incorporated by
-
GUVNOR-698
Build: Clean up GWT build
-
- Resolved
-
-
JBRULES-2869
Split up the build, the repositories and hudson jobs in seperate projects: at least drools, jBPM, guvnor and eclipse so it's easier to fork, checkout and build one project
-
- Resolved
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
drools-ide-common needs to be split into drools-ide-common-gwtclient and drools-ide-common
Geoffrey De Smet
added a comment - drools-ide-common needs to be split into drools-ide-common-gwtclient and drools-ide-common I'm fine with moving factconstraints into Guvnor. Davide is working on Description Logic support for Drools and in reality the fact constraints editor should really just author the DL aspects of the model, which the gui would consume. DL will be direct embedded in DRL, via the Manchester Syntax.
Mark Proctor
added a comment - I'm fine with moving factconstraints into Guvnor. Davide is working on Description Logic support for Drools and in reality the fact constraints editor should really just author the DL aspects of the model, which the gui would consume. DL will be direct embedded in DRL, via the Manchester Syntax. No need to split up drools-ide-common yet, if the dependency from drools-guvnor-gwtclient excludes drools-core and drools-compiler
Geoffrey De Smet
added a comment - No need to split up drools-ide-common yet, if the dependency from drools-guvnor-gwtclient excludes drools-core and drools-compiler feedback on dev list:
- Fact-constraints was born as an independent way to add meta-data to rule's model. I would only move the guvnor dependent part to drools-guvnor.
- I also like moving the backend stuff to drools-guvnor-server (I know you show it in parenthesis in the JIRA but having the -server suffix makes it obvious).
Geoffrey De Smet
added a comment - feedback on dev list:
Fact-constraints was born as an independent way to add meta-data to rule's model. I would only move the guvnor dependent part to drools-guvnor.
I also like moving the backend stuff to drools-guvnor-server (I know you show it in parenthesis in the JIRA but having the -server suffix makes it obvious).
Factconstraints has been moved into ide-common.
Geoffrey De Smet
added a comment - Factconstraints has been moved into ide-common. On a maven level, this splitup is doable:
"About splitting code between client and server modules, that's precisely what I'm doing: myapp-shared for shared classes (includes GWT-RPC interfaces), myapp-client for client-only code (depends on myapp-shared, and myapp-shared:sources), myapp-server for server-only code (depends on myapp-shared and implements GWT-RPC as RemoteServiceServlet-s), and finally a myapp module with packaging=war, that depends on myapp-server and myapp-client.
The *.gwt.xml of course live in the myapp-client module (server-side code don't need them), and in myapp-shared src/main/java (they are source files, used to compile the GWT app; not resources, that would unnecessarily be included in JARs that get deployed on the server)"
the problem is the hosted mode plugin in intellij/eclipse. Doesn't look that will be able to cope with it such a structure.
Geoffrey De Smet
added a comment - On a maven level, this splitup is doable:
"About splitting code between client and server modules, that's precisely what I'm doing: myapp-shared for shared classes (includes GWT-RPC interfaces), myapp-client for client-only code (depends on myapp-shared, and myapp-shared:sources), myapp-server for server-only code (depends on myapp-shared and implements GWT-RPC as RemoteServiceServlet-s), and finally a myapp module with packaging=war, that depends on myapp-server and myapp-client.
The *.gwt.xml of course live in the myapp-client module (server-side code don't need them), and in myapp-shared src/main/java (they are source files, used to compile the GWT app; not resources, that would unnecessarily be included in JARs that get deployed on the server)"
the problem is the hosted mode plugin in intellij/eclipse. Doesn't look that will be able to cope with it such a structure.
6.0.0 is fully modularized.
Michael Anstis
added a comment - 6.0.0 is fully modularized. 
drools-factconstraints can be eaten by guvnor (no need to keep it a separate module) note that it remains a separate package