Robert Burrell Donkin ha scritto:
On Feb 4, 2008 9:55 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
<snip>
Furthermore our website layout does not easily accomodate many products.
Maybe a multimodule product, including the "mailet-utils" generic
library and various modules depending on dependencies (standard-mailets,
security-mailets, sieve-mailets, and so on..) would be better?
in terms of project organisation, IMHO mailets independent of JAMES
belong with the API. so in terms of mailing lists and website
organisation, i think it makes sense to group mailet implementations
with the API.
+1
we move the api down a level and group all mailet-related products. say:
http://svn.apache.org/viewvc/james/mailet/api/trunk/ (<-
http://svn.apache.org/viewvc/james/mailet/trunk/)
http://svn.apache.org/viewvc/james/mailet/std/trunk/
http://svn.apache.org/viewvc/james/mailet/crypto/trunk/
the website is easy enough to sort out: like common, we svn:externals
to create virtual modules. then we also have:
http://svn.apache.org/viewvc/james/mailet/current/api
http://svn.apache.org/viewvc/james/mailet/current/std
http://svn.apache.org/viewvc/james/mailet/current/crypto
the mailet website can be generated from this using the reactor
- robert
Ok, this way the project can be checkedout as a multimodule product but
our svn still contains the trunks/branches/tags for each module.
1) We will need a pom.xml in
http://svn.apache.org/viewvc/james/mailet/current/pom.xml, right?
2) Will the mailet util library be an "util" product similar to api, std
and crypto?
I'm not sure that maven will be happy with a similar structure, but if
we can get maven to work (build the website) and the answers to the 2
questions above are "yes" then you convinced me and I'm fine with this
solution :-)
Stefano
