Re: [wtp-dev] WTP modules, facets and extensability

["Robert Stryker" <rob.stryker@xxxxxxxxx>]

Let me preface this response by saying that I've not yet looked into facets at all. Not in the least. However.........

I agree with Gunnar. 

Module types should be allowed to designate their own default packaging / publishing methods, and allow the server to override it. As of now I've not seen the ability for a module itself to declare how to package itself. 

When I had last looked through the webtools code on the generic server publishing, the generic server had to package and assemble any WTP projects itself. I admit allowing the server to override such functionality is important if they have their own descriptors to add and such, but sometimes the server has no such descriptors to add and would just as easily go along with the module's default packaging process. 

I'm no system architect, so I don't know the best way to design such a process, but it'd be nice if something like that were available.

Gunnar: Even if your module were able to designate its own publishing or packaging steps, most servers still would not recognize it, as a server plug-in implementation has to actively say (in their 
plugin.xml) that they support the following module types. So if you created a module of type gunnars.jst.utility, no server would recognize it. 

Perhaps a good idea is to allow a server's runtime type to say whether they support the default packaging and publishing operations for a module if it doesn't explicitly support that module? For example, my server runtime might contain the following:


      <runtimeType
            vendor="%providerName"
            class="net.oxbeef.someruntime"
            description="%oxbeef.version.description"
            name="Oxbeef"
            id="org.oxbeef.runtime"
            version="5"
            supportArbitraryModuleTypes="true">

          <moduleType
                types="jst.web"
                versions="2.2, 2.3, 2.4"/>
          <moduleType
                types="jst.ejb"
                versions="1.0, 1.1
, 
2.0, 2.1"/>
          <moduleType
                types="jst.ear"
                versions="1.2, 1.3, 1.4"/>

      </runtimeType>


At this point the serverbehavior could do something like 
  if( runtimetype.supports(moduletype)) {
        serverbehavior.publish(module) 
  } else if( runtimetype.supportsArbitraryModules() ) {
        try {
            module.publishTo(server);
         } catch( UtterlyFailedException ufe) { }
  } else {
        // do the error where the server does not support that module type
  }

The example above would support the three jst types explicitly, but then says it will support arbitrary module types. Perhaps a module type looking to be supported as an "arbitrary type" could be subclasses of the current Module / ModuleDelegate pair which throw some exceptions built in, in case the 'arbitrary' module type does something the server doesn't like or can't complete the publish. 


I guess what I'm asking for is two different types of module. One where the servers themselves decide how to package and deploy the module (as currently), and another where the module is in charge of making contingency plans for each server type, and allow the server / runtime to say whether they even want to allow this second type to be handled or not. 
The server, as shown above, could opt out by declaring it only wants to publish modules explicitly declared in the plugin.xml. 

Or you can dream up your own system-architecty ways of doing it. I just felt like bloviating out loud.  ;)

- Rob Stryker

On 7/13/06, Gunnar Wagenknecht < gunnar@xxxxxxxxxxxxxxx> wrote:

Hi!

I'm trying to create a specialized type of a jst.utility module that any
dynamic web project can depend on. It's "specialized" because I want to
define additional publishing steps.

Usually jst.utility modules are published as Jars in the WEB-INF/lib
directory. I want to extend this behavior and also publish some
additional resources into the web root directory (eg. HTML files,
_javascript_ files, etc.).

However, it looks like the whole facets and modules framework was not
designed with such extensibility in mind. All the server implementation
which do the actual publishing hard code the publishing process. Is
there a generic solution to this problem or is this a complete new
feature request for the API?

CU, Gunnar


--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev