Guvnor project layout

[michaelneale]

I propose the following layout:

1: guvnor-repository: Guvnor SOA artifact repository
(JCR back end) with AtomPub and WebDAV interfaces.
2: guvnor-web: The AJAX/GWT web interface to the SOA artifact repository.
Essentially a front end to guvnor-repository.
3: guvnor-widgets: A set of widgets for a common web experience (using GWT)
Mike Brock is working on a set of nice widgets to replace gwt-ext.
4: guvnor-plugin: An eclipse plug in to allow artifacts to be shared
between the guvnor repository and developer workspaces (currently uses
webdav)
4: guvnor-drools: The Drools Guvnor rule management tools (web
interface and related compiler tools)
This will reuse the guvnor-repository and the guvnor-widgets projects.

So there are 5 top level "modules" - folders in SVN. As jervis pointed
out, he is structuring guvnor-repository to actually be 2 or more
modules (the atom module for instance) - but that is ok, just
subfolders is fine.

Does this sound reasonable? Mikes stuff can move into guvnor-widgets
(like the name?) - make it top level to encourage others to use it (we
can move it somewhere else in the future if more people want to
contribute - its not really guvnor specific). Heiko probably is quite interested in this stuff (it shouldn't be repo specific).

John - have to work on the timeing to move the guvnor plug int to #4,
and also make sure it works with what jervis comes up with in #1 (same
applies to me for drools).

Thoughts? Objections?

[jervisliu]

So there are 5 top level "modules" - folders in SVN. As jervis pointed
out, he is structuring guvnor-repository to actually be 2 or more
modules (the atom module for instance) - but that is ok, just
subfolders is fine.

Actually I would prefer separating the atom module from the repository module. This is because the atom module will depend on a lot of third-party libraries such as JAX-RS implementation (Apache CXF for example), Abdera, HttpClient etc, which are totally irrelevant to the repository core. With the nice separation, we will be able to release the distribution of our repository core (and its dependencies) in a very small package.

[marklittle]

Does it make sense to release the repository without any way of access it remotely?

[jeffdelong]

You listed:

4: guvnor-drools: The Drools Guvnor rule management tools (web
interface and related compiler tools)

Is there similar functionality for services? I.e. a services specific web interface and possible tools to create deployment archives, etc.?

[jervisliu]

Does it make sense to release the repository without any way of access it remotely?

So for example, we may release a special bundle which is repository + webDAV. In this case, it wont make sense if we have to include atomPub or JAX-RS related jars in this bundle because the repository module has dependencies on atomPub and JAX-RS.

[marklittle]

So webDAV is more fundamental to the core than REST? I'm just wondering why the differentiation.

[jervisliu]

So webDAV is more fundamental to the core than REST? I'm just wondering why the differentiation.

No, I view the repository module as the back end core, the GWT/Ajax based GUI, AtomPub/REST or webDAV are just different interfaces that allow you to access the back end repository. Potentially we can releases these components in different combinations, such as GWT+Repository, AtomPub + Repository, webDAV + Repository or GWT+AtomPub +webDAV+Repository. Of course over time, we may find AtomPub needs to be integrated with the repository module much more closely than any other access layer modules, i.e., the atomPub is more like a built-in capability of back end repository core. But even in this case, the separation of the atomPub module from the repository module still makes it easier to manage dependencies in maven.

[michaelneale]

"jervisliu" wrote:

So there are 5 top level "modules" - folders in SVN. As jervis pointed
out, he is structuring guvnor-repository to actually be 2 or more
modules (the atom module for instance) - but that is ok, just
subfolders is fine.

Actually I would prefer separating the atom module from the repository module. This is because the atom module will depend on a lot of third-party libraries such as JAX-RS implementation (Apache CXF for example), Abdera, HttpClient etc, which are totally irrelevant to the repository core. With the nice separation, we will be able to release the distribution of our repository core (and its dependencies) in a very small package.

[michaelneale]

"jervisliu" wrote:


Actually I would prefer separating the atom module from the repository module. This is because the atom module will depend on a lot of third-party libraries such as JAX-RS implementation (Apache CXF for example), Abdera, HttpClient etc, which are totally irrelevant to the repository core. With the nice separation, we will be able to release the distribution of our repository core (and its dependencies) in a very small package.

You can make a submodule - that is fine. Just only one top level folder is my idea.

[michaelneale]

"jeffdelong" wrote:
You listed:

4: guvnor-drools: The Drools Guvnor rule management tools (web
interface and related compiler tools)

Is there similar functionality for services? I.e. a services specific web interface and possible tools to create deployment archives, etc.?

Not sure what you mean - this is really just drools-guvnor from the drools SVN, moved across and using drools deps rather then a module of the drools project (so it can have separate releases).

[marklittle]

"jervisliu" wrote:

So webDAV is more fundamental to the core than REST? I'm just wondering why the differentiation.

No, I view the repository module as the back end core, the GWT/Ajax based GUI, AtomPub/REST or webDAV are just different interfaces that allow you to access the back end repository. Potentially we can releases these components in different combinations, such as GWT+Repository, AtomPub + Repository, webDAV + Repository or GWT+AtomPub +webDAV+Repository. Of course over time, we may find AtomPub needs to be integrated with the repository module much more closely than any other access layer modules, i.e., the atomPub is more like a built-in capability of back end repository core. But even in this case, the separation of the atomPub module from the repository module still makes it easier to manage dependencies in maven.

Sure, so why treat Atom differently to webDAV? I understand why you'd want to factor the transports from the core, but in which case factor all of the transports.

[michaelneale]

ok so we could have repository-atom, repository-webdav and repository-core?

Personally I would put it all in one ball until there is a good reason not to (I guess the advantage to the above is that repository-core doesn't have any servlet dependency needed - its just a plain old library).