13 Apr
2007
13 Apr
'07
8:34 a.m.
Hi Sergiu,
I think we already have you described or at least that's the intent.
Let me explain.
* We already have a xwiki-applications/wikis directory in SVN which
is meant to be the place where you put what you call Flavors (I call
them wikis). Right now there's only one called "default" (actually
there's a second one called xwikiorg on my machine but I've never
checked it in because it's big and we don't distribute it as a
generic wiki).
* This wiki-applications/ dir has a trunk/, branches/ and tags/
directories which means it's already meant to have its own release
lifecycle separate from xwiki-core/ (called xwiki/ right now but
needs to be renamed). The idea is that anything top level dir that
has a trunk/, branches/ and tags/ is meant to have its own release
lifecycle. It's just that we're not doing it now for lack of manpower
and people working on the various components, and more importantly
we're not using Maven2 yet for the release. When we do, it takes
about 5 minutes to cleanly release any project (I know as I've made
this exact transition for the Cargo project). This is the direction.
But Maven2 is an absolute prerequisite.
* In term of JIRA it all derives from SVN simply in JIRA the rule is:
one JIRA project per release lifecycle. Indeed each JIRA project
defines its own versions (0.1, 0.2, 1.0, etc) and it's bad practice
to mix different version names for different releases in one JIRA
project. Thus once we start releasing any component separately from
the core, we'll create a JIRA project for it.
To summarize:
1) I agree with XWiki "Flavors" (which I call wikis but we can
standardize on a name, not very important - Not sure about Flavor
though)
2) Our SVN structure is already meant to accomodate this
3) We need the M2 build to be finished (it's really almost there
especially as our big issue with m2 has been fixed in m2 trunk). I
think I need about 2-3 full days to finish it
4) JIRA projects derive from 2) and it's just a question of creating
the project when the time comes.
Now there's one remaining thing to discuss: the documentation of
XWiki "flavors" on xwiki.org. This is the thread started by Guillaume
and to which nobody has answered yet. Right now we're mixing
documentation of core and default wiki on xwiki.org. Once we get
another flavor we'll need to fix this.
See "Reorganization the documentation content on XWiki.org":
http://www.nabble.com/Reorganization-the-documentation-content-on-
XWiki.org-tf3541863.html#a9887423
Thanks
-Vincent
On Apr 13, 2007, at 1:16 AM, Sergiu Dumitriu wrote:
Hi,
I'd like to propose a new subproject on JIRA, called XWiki Flavors.
What is a Flavor? A flavor is a custom XWiki-based site, with one
specific goal in mind. The XPN team creates such flavors when
working for client project. As it is said on http://jira.xwiki.org/
jira/browse/XWIKI-356 , by default XWiki comes with a collection of
pages, panels, classes, a pre-selected skin, etc, which gives it a
"flavor". Right now, it looks like a nice site where you can put
some pages (content), articles, documentation, etc. It is a weak
flavor, since it's a mixture of different ingredients put all
together.
An example of a "strong" flavor is a blog-wiki. When you install
XWiki and choose the blog-flavor, you will get the full
functionality of any blog app (for example blogger or wordpress)
without having to customize anything, without having to import one
or several xar-s, editing the main page or anything. Of course,
after the user gets used to the blog (and XWiki) he can customize
the skin (using a friendly skin browser and a skin wizard), the
displayed panels (using the panel wizard), and many other things
(actually anything a user can change in XWiki, which is everything).
Other strong flavors could be content management, OpenSource
project website (about, developer guide, user guide,
download, ...), or just the documentation for such a project (many
projects use wikis now), Social Networking site (link and photo
sharing, tagging, reviews), project management, and so many more.
Why are flavors necessary? Because XWiki is too powerful. Put it in
the hands of some who-knows-what "haskel model checker" developer
who only knows about axioms, theorems, proving, model checking and
functional programming, and he will run away very fast to a simple
wiki engine, or worse, a CMS. But hide all the power behind a
simple interface, with only what he needs in order to publish some
info about his project, and we have a happy XWiki user.
Why do we need a new subproject? Because:
- putting all the flavor-specific issues in the "Default database"
component is not efficient
- neither is putting them in a new "Flavors" component
- we don't know how many flavors we will create, so making an XWiki
component for each flavor will bloat the component list
- flavors don't follow the XWiki platform release plan; they get
shipped when they are ready
What is the relation between flavors, default database, and xwiki-
applications?
The default database should be almost empty. It should contain
mainly the setup wizard, which can be used to install a flavor.
A flavor contains some applications bundled together. It is not
enough to put only the individual applications in JIRA, because a
flavor is more than that: a custom skin, configuration for the
applications, rights setup, other documents outside of
applications, java plugins, XWiki configuration, and even more.
What should the subproject contain? First, a "global" component,
regarding flavor development, deployment, integration,
installation. Then a component for each flavor we are currently
supporting (or starting to work on).
WDYT?
Sergiu
--
http://purl.org/net/sergiu
--
You receive this message as a subscriber of the xwiki-
dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws