Marc Hadley wrote:
> On Nov 7, 2007, at 2:32 AM, Wilfred Springer wrote:
>>
...
>>
> OK, I haven't really got my head round how debugging etc is going to
> work with the new build. I need to do some experimentation to see what
> works and doesn't.
Debugging works as normal when using NetBeans with mevenide2 plugin.
>
>> There is one other thing that Farrukh suggested, which is to have a
>> wadl-spec module that also contains the latest version of the
>> specification
>> and related schemas. I'm starting to doubt if we really need another
>> Maven
>> module for that; I could also imagine that we stick those files in a
>> subdirectory of the project root (ithe 'source' directory). I do however
>> agree that it would be a good idea to keep those files *inside* the
>> Maven
>> project's directory layout. Comments highly appreciated.
>>
> What's the benefit of moving the spec from its current location in
> subversion - I'm not against doing that just wondering what we gain ?
Here are some benfits based on my experience with several spec projects
at OASIS and OGC.
Having a maven spec module allows the spec team to use all the
advantages of maven for managing the spec.
Note all of benefits below may apply to wadl spec:
* Spec build process automation to handle impedance mismatch between
desired public structure and svn structure. In OGC the public
structure needed spec revision in directory paths while this was
not desirable in svn
* Resource filtering
o to replace version specific variable in xsd, wsdl, wadl etc.
o to replace versions of imported xsd, wsdl etc with specs xsd
based maven profile defined properties
* Test automation: automatically validate schemas, wsdl etc. as part
of build process
* Packaging automation: automatically create zip/jar file with
version name etc. in it.
* Generate language specific bindings (e.g. JAX-WS, JAXB bindings as
part of spec build process where applicable
* Project validation to make sure things like licensing etc. are include
* Management of dependencies on other spec projects if applicable
(this will require some time before being significant. requires
others spec to us emaven)
* Release automation for common release tasks:
o Generate a change log
o Include latest version of licenses, release notes etc.
o Tag the svn repo with release tag
o Create an svn branch
o Deployment automation to copy spec distribution to a public
svn repo
Thanks.
--
Regards,
Farrukh
Web: http://www.wellfleetsoftware.com