18 Jun
2007
18 Jun
'07
9:12 a.m.
Hi Vincent and all,
Thank you for your explanations. Below are my ok for each answer your
brought.
Vincent Massol wrote:
ok
ok
ok
I have the feeling it is likely that the Eclipse extension will quickly
evolve to an Eclipse API for creating Eclipse apps that will interact
with XWiki, but you're right it's not the case for now, so we'll see
when it's the case.
right
Thanks
Cheers
Stéphane
--
Stéphane Laurière
slauriere(a)xwiki.com
XWiki Research
http://www.xwiki.com
http://concerto.xwiki.com
http://nepomuk.semanticdesktop.org
Hi Stephane,
Thanks a lot for your comments. See below.
On Jun 12, 2007, at 9:56 PM, Stéphane Laurière wrote:
[snip]
I see, ok.
Hi Vincent,
Sounds good to update the SVN structure for addressing the growing
complexity :-)
Here are below some questions and suggestions.
Vincent Massol wrote:
The xwiki-applications all depend on the platform. I was viewing the
platform as providing the core infrastructure be it at runtime or at
build time. Hi,
Note: This email supercedes all my other proposals on the SVN
directory structure.
The rationale for this mail is that we're starting to have lots of
applications built on top of the xwiki platform: XWiki Enterprise
(default wiki), XEM, Watch, Curriki, Chronopolys, etc. We need to
accomodate them in our directory structure.
Top level structure
===============
/svnroot/xwiki/
|_ xwiki-platform/
|_ xwiki-applications/
|_ xwiki-enterprise/
|_ xwiki-enterprise-manager/
|_ xwiki-watch/
|_ curriki/
|_ chronopolys/
|_ xwiki-extensions/
|_ xwiki-eclipse/
|_ xwiki-concerto/
|_ sandbox/
where:
* xwiki-platform is the xwiki platform on which all the applications
are built.
* xwiki-applications are applications that extend the platform with:
skins, xwiki pages (XAR), plugins
* xwiki-enterprise is the name of our previously known "default wiki"
application.
* xwiki-extensions are any other extensions of xwiki not fitting in
xwiki-applications. For example the XWiki Eclipse integration, etc.
I've put concerto there but I'm not sure what it'll look like.
Definition of xwiki-platform
=====================
/svnroot/xwiki/xwiki-platform/
|_ tools/
|_ core/ (JAR)
|_ plugins/ (JARs)
|_ skins/ (ZIPs)
|_ dodo/
|_ finch/
|_ albatross/
|_ web/ (WARs)
|_ gwt/
|_ standard/
|_ xarlets (XARs)
|_ selenium/
|_ blog/
|_ calendar/
|_ ...
where:
* tools/ contains tools used to build the platform and xwiki
applications
If they are used both by the platform and the applications, shouldn't we
put the "tools" folder at the root level (/svnroot/xwiki/tools/)? Regarding the
xarlets: why should they be considered as part of the
platform? They build upon the platform, but they are rather extensions
of the platform than part of it, aren't they?
They are reusable xarlets and as such, like plugins or component jars,
they can be reused by the xwiki applications.
Maybe our differences of view is that you view the platform as only JARs
whereas I view the platform as providing all the pieces required by
applications to be built upon (build tools, components, UI pieces, etc).
Application are end products for me.
I have also this question: should we really
distinguish in the structure
between the concepts of plugins, xarlets and xwiki-applications?
They are different right now. In the future, hopefully everything will
be a component. They
have a different nature indeed, but won't splitting them into different
folders make the life of developers more complex? If I write a
BlogTrackBackPlugin that does some specific stuff with blogs, where will
I put it in the repository? It should probably go to the "blog xarlet",
which then contains xwiki-documents + Java classes. Isn't it likely that
our xarlets, or at least some of them will evolve to full-fledged
"applications" that will use all the XWiki concepts? Along the same
lines, won't we have plugins that will have their xwiki-documents?
Stephane I think you're jumping ahead about 6 months to 1 year... ;)
This is indeed what we want but we're far from there and the structure
I'm proposing is for now with the ability to evolve to something else in
the future. Right now it means these blogging features will be split
between xwiki-platform/plugins/blog and xwiki-platform/xarlets/blog. Regarding the evolution, 2 possibilities:
- the blogging features are components meant to be reused by
applications. In this case they can go in the platform which will then
offer blogging features for applications
- the blogging features are not meant to be reusable and embedded in
xwiki applications. They form a standalone blogging application and
should be located in xwiki-applications.
If I follow your direction, then everything is potentially an
application and the platform becomes the core. I'm viewing the platform
as core + reusable components and I differentiate between reusable
components and end applications (products if you prefer). I wouldn't mind:
xwiki/
|_ xwiki-core/
|_ xwiki-components/ (or whatever you want to call it)
|_ xwiki-applications/
But my preference currently goes to what I proposed:
xwiki/
|_ xwiki-platform/
|_ xwiki-core/
|_ xwiki-components/
|_ xwiki-applications
fine with me for that one for now then (with probably xwiki-core as a
component among others in the future then if I understand correctly).
If this
happens, we can of course let the xarlet become an application
and move it in the repository, but we may then consider putting plugins
and xarlets in the xwiki-application folder, and distinguish between the
following concepts not at the repository structure level but only at the
deployment API and configuration levels:
1) application that contains only documents ("xarlet"): can be installed
on any xwiki instance
2) application that contains plugins and possibly other Java classes,
and possibly some xwiki documents (could be dubbed "xwiki application",
"xwiki plugin" or "xwiki extension"?): can be installed on any xwiki
instance, but it requires a restart of the application server
3) application that contains Java classes, xwiki documents and other
contents: need specific deployment. -> "xwiki product"?.
What do you think?
I've put 1) in xwiki-platform/ and 3) in xwiki-applications/. For 2), my
proposal also puts them in 1) as they are reusable pieces. Regarding the
extensions you mention: I don't understand why we wouldn't
consider xwiki-eclipse as part of the platform: how is it different from
the /xwiki-platform/web/gwt?
web/gwt is offering an API for developing applications. The IDE
extension is a client/application using the XWiki API. It's not like
we're offering an Eclipse API for people to build Eclipse applications
that interact with XWiki. Here 's a
modified tree to summarize my suggestions:
xwiki-platform
==============
/svnroot/xwiki/xwiki-platform/
|_ core for now
|_ xwiki-model, xwiki-storage etc. in the future
|_ webapp
|_ gwt
|_ standard
|_ xwiki-platform-ui (the components below may be moved to the
component level in the future, i.e. would be at the same level as
xwiki-model etc.)
|_ eclipse-ui
|_ flex-ui
|_ xul-ui
|_ web-ui-standard
|_ templates
|_ skins
|_ gwt
Re the UIs I'm fine but I think we should wait till we have more UIs
before creating a deep structure. For now we only have web UIs which is
why I put the web/ directory.
|_ plugins: only the platform core plugins:
image, packaging,
fileupload, zipexplorer, but not: flickr, graphviz, ...
Where would you put the flickr/ and graphviz/ plugins? I'd still put
them in xwiki-platform as they are reusable for xwiki-applications.
xwiki-applications
==================
/svnroot/xwiki/xwiki-applications/
|_ xwiki-blog
|_ wiki
xwiki-blog is not an application. It's not runnable. It's a component
that can be integrated into an application.
For me the definition of an Application is:
* A set of plugins
* A set of components (JARs)
* A set web pages (velocity templates, etc)
* A set of xwiki documents in a database
* All this inside a configured container
* An application distribution is a zip/exe/tar.gz
I'd agree with xwiki-blog as an application if we were delivering a
standalone blogging application but that's not the purpose of the blog
xarlet (it's meant to be used as a component by xwiki applications) as
it exists as we're not making a product out of it (at least no yet). |_
xwiki-calendar
|_ plugins/
|_ com.xpn.xwiki.plugins.CalendarPlugin
|_ wiki/
Same as for the blog.
|_ xwiki-enterprise-manager
|_ wiki
|_ web
|_ distribution
|_ xwiki-watch
|_ xwiki-concerto
[snip]
Thanks for this interesting POV! :)
Let's see what Sergiu, Ludovic and the others say.
Thanks
-Vincent