I'd prefer #2. There's no reason to have a site module; you
might as well just add src/site directly to the top-level plugins
project; then let Maven do all the work of linking to all the
individual plugins.
Maven naturally supports #2 (and automatic composition);
why not take advantage of
I always prefer compositon, I find it easier to maintain and it's also
easier to add/remove parts imho. so +1 for option 2.
Regards,
Simon Lessard
Fujitsu Consulting
Matthias Wessendorf [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
2006-08-14 23:41
Please respond to adffaces-dev
ok, sounds good.
so, do we want a src/site under *plugins* folder, as our entry point?
http://svn.apache.org/viewvc/incubator/adffaces/trunk/plugins/
(of course, each modules has its own src/site)
That's for the plugins.
Howto do we handle the integration with Trinidad?
I think it would be
I think that we should just have links from the plugin
site to the Trinidad site and vice versa (and probably
start people off on the Trinidad site, because that's
what 99% of people will want). No need for an
umbrella site.
-- Adam
On 8/15/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
My point is creating a simple and small page was
that almost all users are interested in Trinidad, instead of
the plugins. The JDev plugin might be the most interesting one, which
can be used outside of Trinidad. The archetype might be also
interesting for getting started.
But anyway, I'll put a
b) Structure:
There are two options for handling the doc structure:
1. create a site module, which contains *all* documentation
2. having each (sub)project/plugin having it's own src/site and *compose* it.
Shale uses the first (for instance). See [1] for David Geary's remote
example. MyFaces
On 8/14/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
this email contains two things.
a) Call for help on documentation:
If you like to provide some documentation about the Trinidad plugins,
feel free to add content to the wiki. Or provide xdoc or apt patches
;)
b) Structure:
There
b) Structure:
There are two options for handling the doc structure:
1. create a site module, which contains *all* documentation
2. having each (sub)project/plugin having it's own src/site and *compose* it.
Shale uses the first (for instance). See [1] for David Geary's remote
example.
