13 Apr
2007
13 Apr
'07
1:16 a.m.
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
13 Apr
13 Apr
8:34 a.m.
New subject: [xwiki-dev] [Proposal] Create a new XWiki Flavors subproject on JIRA
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
11:01 a.m.
New subject: [xwiki-dev] [Proposal] Create a new XWiki Flavors subproject on JIRA
On 4/13/07, Vincent Massol <vincent(a)massol.net> wrote:
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).
Yes, I forgot to mention this in my email.
* 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.
I'm waiting for the mvn build, too. (and for checkstyle that works on all
the files :) )
* 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.
That's even better, I though that you wouldn't agree on making so many
projects. So yes, it would be better to have a "Flavors" category and a
project for each available flavor.
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.
Use tags?
See "Reorganization the documentation content on XWiki.org":
http://www.nabble.com/Reorganization-the-documentation-content-on-XWiki.org…
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?
--
http://purl.org/net/sergiu
6366
days inactive
6367
days old
2 comments
2 participants
participants (2)
-
Sergiu Dumitriu -
Vincent Massol