Sorry, my previous tree had a flattened layout. Here's the right one: 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 |_ plugins: only the platform core plugins: image, packaging, fileupload, zipexplorer, but not: flickr, graphviz, ... xwiki-applications ================== /svnroot/xwiki/xwiki-applications/ |_ xwiki-blog |_ wiki |_ xwiki-calendar |_ plugins/ |_ com.xpn.xwiki.plugins.CalendarPlugin |_ wiki/ |_ xwiki-enterprise-manager |_ wiki |_ web |_ distribution |_ xwiki-watch |_ xwiki-concerto |_ ... Stéphane

I'm a bit tired right now, so I can't decide which one makes more sense. However, I have my own questions :) 1) How about the decision to move skins in a distinct place? 2) Where in the structure are the trunk/branches/tags defined? 3) Why are the xarlets inside the platform? I'll be back with more when I'll be awake. On 6/12/07, Vincent Massol <vincent@massol.net> wrote:

Hi Stephane,

Thanks a lot for your comments. See below.

On Jun 12, 2007, at 9:56 PM, Stéphane Laurière wrote:

[snip]

...

Hi Vincent,

Sounds good to update the SVN structure for addressing the growing complexity :-)

Here are below some questions and suggestions.

Vincent Massol wrote:

...

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/)?

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.

...

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

...

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

Sergiu -- http://purl.org/net/sergiu

...

1) How about the decision to move skins in a distinct place?

They are there in xwiki-platform/skins.

Told you I was tired. Now it all makes sense. I thought that platform = core, built all at once.

...

2) Where in the structure are the trunk/branches/tags defined? 3) Why are the xarlets inside the platform?

I think this is the most controversial issue as Stephane raised a similar issue. See my answer there.

OK, I agree with you.

To summarize, in my proposal: * platform = reusable bits * platform != core * platform = core + other reusable bits

You said that core => jar, web => war. Does the war include the required libs + xwiki.jar? -- http://purl.org/net/sergiu

This will make trunks-devs a must, since not everybody wants 6G (and counting) of xwiki history on his HDD. On 6/21/07, Vincent Massol <vincent@massol.net> wrote:

On Jun 13, 2007, at 1:39 AM, Sergiu Dumitriu wrote:

...

I'm a bit tired right now, so I can't decide which one makes more sense. However, I have my own questions :)

1) How about the decision to move skins in a distinct place? 2) Where in the structure are the trunk/branches/tags defined?

[snip]

We haven't answered this question. Here's my take:

/svnroot/xwiki/xwiki-platform/ |_ tools/ |_ trunk/ |_ branches/ |_ tags/ |_ core/ (JAR) |_ trunk/ |_ branches/ |_ tags/ |_ plugins/ (JARs) |_ trunk/ |_ branches/ |_ tags/ |_ skins/ (ZIPs) |_ trunk/ |_ branches/ |_ tags/ |_ web/ (WARs) |_ trunk/ |_ branches/ |_ tags/ |_ xarlets (XARs) |_ trunk/ |_ branches/ |_ tags/

/svnroot/xwiki/ |_ xwiki-platform/ |_ xwiki-applications/ |_ xwiki-enterprise/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-enterprise-manager/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-watch/ |_ trunk/ |_ branches/ |_ tags/ |_ curriki/ |_ trunk/ |_ branches/ |_ tags/ |_ chronopolys/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-extensions/ |_ xwiki-eclipse/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-concerto/ |_ trunk/ |_ branches/ |_ tags/ |_ sandbox/

WDYT?

Thanks -Vincent

Sergiu -- http://purl.org/net/sergiu

Hi David, On Jun 21, 2007, at 7:33 PM, David Ward wrote:

Yes, or it might make more sense to have trunk/branches/tags for xwiki-platform to be at a level higher than core/plugins/skins/... so that one can checkout the trunk of xwiki-platform and get the whole tree that is required (which would probably be how each of the applications are structured underneath the trunk/tags/branches for each of them).

With the svn:externals you can get everything at once. The real question is how we want to release these and the reason for trunk/branches/tags at the level beneath xwiki-platform is to allow release each of them independently. For example it should be possible to release only a given skin without releasing the rest. This would still be possible with your suggestion although it would be slightly less clean. BTW the whole platform isn't required to build XWiki Enterprise for example. WDYT? Thanks -Vincent PS: I'm really open on this as I'm not entirely sure that what I've proposed is the best. I suggest to keep going for now, see what we get and then improve if need be.

On 6/21/07, Sergiu Dumitriu <sergiu.dumitriu@gmail.com> wrote:

...

This will make trunks-devs a must, since not everybody wants 6G (and counting) of xwiki history on his HDD.

On 6/21/07, Vincent Massol <vincent@massol.net> wrote:

...

On Jun 13, 2007, at 1:39 AM, Sergiu Dumitriu wrote:

...

I'm a bit tired right now, so I can't decide which one makes more sense. However, I have my own questions :)

1) How about the decision to move skins in a distinct place? 2) Where in the structure are the trunk/branches/tags defined?

[snip]

We haven't answered this question. Here's my take:

/svnroot/xwiki/xwiki-platform/ |_ tools/ |_ trunk/ |_ branches/ |_ tags/ |_ core/ (JAR) |_ trunk/ |_ branches/ |_ tags/ |_ plugins/ (JARs) |_ trunk/ |_ branches/ |_ tags/ |_ skins/ (ZIPs) |_ trunk/ |_ branches/ |_ tags/ |_ web/ (WARs) |_ trunk/ |_ branches/ |_ tags/ |_ xarlets (XARs) |_ trunk/ |_ branches/ |_ tags/

/svnroot/xwiki/ |_ xwiki-platform/ |_ xwiki-applications/ |_ xwiki-enterprise/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-enterprise-manager/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-watch/ |_ trunk/ |_ branches/ |_ tags/ |_ curriki/ |_ trunk/ |_ branches/ |_ tags/ |_ chronopolys/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-extensions/ |_ xwiki-eclipse/ |_ trunk/ |_ branches/ |_ tags/ |_ xwiki-concerto/ |_ trunk/ |_ branches/ |_ tags/ |_ sandbox/

WDYT?

Thanks -Vincent

Sergiu -- http://purl.org/net/sergiu

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki- dev@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

Hi Vincent and all, Thank you for your explanations. Below are my ok for each answer your brought. Vincent Massol wrote:

Hi Stephane,

Thanks a lot for your comments. See below.

On Jun 12, 2007, at 9:56 PM, Stéphane Laurière wrote:

[snip]

...

Hi Vincent,

Sounds good to update the SVN structure for addressing the growing complexity :-)

Here are below some questions and suggestions.

Vincent Massol wrote:

...

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/)?

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.

I see, ok.

...

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.

ok

...

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.

ok

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.

ok

...

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.

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.

...

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).

right

...

|_ 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

Thanks Cheers Stéphane -- Stéphane Laurière slauriere@xwiki.com XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org

I'm giving an overall +1 to Vincent's proposal except for the xarlets. I feed that having the xarlets in the platform will either make us end up with small applications in the platform, or have us mix small and big apps in xwiki-applications. I think we need xarlets outside but not in xwiki-applications. So 1/ I agree with stephane xarlets should not be in the platform 2/ I agree with vincent that applications should be "big packages" like watch, curriki, chrono, xem.. It does not means they have to have java plugins but it means they deserve the "product" or "application" name.. So maybe xwiki-xarlets (small XWiki applications) xwiki-products (product level XWiki applications) Ludovic Vincent Massol a écrit :

Any other feedback on this?

* So far we have Stephane and Sergiu who have answered. * Sergiu said he was ok with the structure I proposed * Stephane didn't quite agree and proposed something else to which I replied (no new answer from Stephane yet ;)).

We need to make way to XEM and Watch so I'd like to start implementing this ASAP. Please comment if you agree or don't agree as it'll be too late once I start the work :)

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

WDYT?

Thanks -Vincent

-- You receive this message as a subscriber of the xwiki-dev@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

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@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

-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

I don't agree that much about the parallel between plugins and xarlets.. The process of working with plugins and xarlets is in my view quite different.. Most use cases will want the most important plugins already installed but have the ability to activate/deactivate. The reason is that applications will often base themselves on these plugins and we want them as easy to install as possible. Concerning xarlets they can be installed on top of the core XWiki.. so for me it's much easier to consider them out of the platform. But in the end I think it shows that there are - core components - external components Core compenents (plugins or xar, but most often plugins) are stuff that you need to build upon. External components (plugins or xar or gwt apps, but mostly xar or gwt apps) are stuff that are mostly used by itself, by the app you build So I think we can discuss a lot about that organisation because in the end both organisations are right.. However what I see in your current proposal is that we don't have a repository for small external components.. we only have the "big application" component.. I don't think it's that good to put stuff like the "Packager" app or the "Document Template" app or the "FAQ" app in the core.. neither I think it's good to put it in the "big application" repository. I don't think this is true for plugins which you prefer to have in the core so that they are ready to use on any recent XWiki install. Ludovic Vincent Massol a écrit :

On Jun 17, 2007, at 12:00 PM, Ludovic Dubost wrote:

...

I'm giving an overall +1 to Vincent's proposal except for the xarlets. I feed that having the xarlets in the platform will either make us end up with small applications in the platform, or have us mix small and big apps in xwiki-applications. I think we need xarlets outside but not in xwiki-applications.

So

1/ I agree with stephane xarlets should not be in the platform 2/ I agree with vincent that applications should be "big packages" like watch, curriki, chrono, xem.. It does not means they have to have java plugins but it means they deserve the "product" or "application" name..

So maybe

xwiki-xarlets (small XWiki applications) xwiki-products (product level XWiki applications)

The problem is that if you follow that logic you should also move xwiki plugins out of the platform as plugins are reusable code in the same manner xarlets are reusable UIs. Also, in the near future a xwiki components would be able to package both xwiki pages and Java code in a JAR so the distinctions between xarlets and plugins will be blurred and they'll simply be components. A component will be able to provide only code, UIs, or both. This means that all the code and UIs that make the default wiki will be scattered into various components.

So if we follow your logic that xarlets (and thus components) do not belong to the platform (and I think they do) then we end up with what I mentioned in my reply to Stephane:

xwiki/ |_ xwiki-core/ |_ xwiki-components/ (or whatever you want to call it) |_ xwiki-applications/

But my preference currently goes to:

xwiki/ |_ xwiki-platform/ |_ xwiki-core/ |_ xwiki-components/ |_ xwiki-applications

i.e. platform = core + reusable components (where core will become in the future a set of components itself and core will simply be a list of components that go together, i.e. a packaging)

WDYT?

Thanks -Vincent

...

Vincent Massol a écrit :

...

Any other feedback on this?

* So far we have Stephane and Sergiu who have answered. * Sergiu said he was ok with the structure I proposed * Stephane didn't quite agree and proposed something else to which I replied (no new answer from Stephane yet ;)).

We need to make way to XEM and Watch so I'd like to start implementing this ASAP. Please comment if you agree or don't agree as it'll be too late once I start the work :)

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

WDYT?

Thanks -Vincent

--You receive this message as a subscriber of the xwiki-dev@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

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@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

--Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

-- You receive this message as a subscriber of the xwiki-dev@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

------------------------------------------------------------------------

-- You receive this message as a subscriber of the xwiki-dev@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

-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

OK, I talked to Ludovic on skype and he's agreed to the directory structure I proposed. In any case, we can always modify things (actually I'm pretty sure the final structure will not be exactly like the one I proposed as we'll find some gotchas along the way...). I'm thus ready to start implementing it. I'd like to start it ASAP (right now would even be my choice). It means that during 2-3 days the build won't work and it'll be a bit of chaos during that time. Everyone ok with that? Note: I'd rather do it now because we're still early in the 1.1M3 release and it's safer to do it now rather than later... Thanks -Vincent On Jun 21, 2007, at 1:31 PM, Vincent Massol wrote:

On Jun 20, 2007, at 12:16 PM, Ludovic Dubost wrote:

...

I don't agree that much about the parallel between plugins and xarlets.. The process of working with plugins and xarlets is in my view quite different..

Most use cases will want the most important plugins already installed but have the ability to activate/deactivate. The reason is that applications will often base themselves on these plugins and we want them as easy to install as possible. Concerning xarlets they can be installed on top of the core XWiki.. so for me it's much easier to consider them out of the platform.

But in the end I think it shows that there are

- core components - external components

Core compenents (plugins or xar, but most often plugins) are stuff that you need to build upon. External components (plugins or xar or gwt apps, but mostly xar or gwt apps) are stuff that are mostly used by itself, by the app you build

So I think we can discuss a lot about that organisation because in the end both organisations are right.. However what I see in your current proposal is that we don't have a repository for small external components.. we only have the "big application" component..

In my proposal we have:

XWiki = Platform + Applications

where

Platform = Core (i.e. components + others) + Reusable components (what you call external components I think)

What you want (I think) is:

XWiki = Core + External Components + Applications

meaning you'd like to remove the notion of Platform and instead show Core at the top level:

xwiki/ |_ core/ |_ components/ |_ applications/

Personally I don't mind that much although I liked the dichotomy Platform/Applications which was simple enough to explain I think.

For me Platform = any bit than can reused as is in an Application.

...

I don't think it's that good to put stuff like the "Packager" app or the "Document Template" app or the "FAQ" app in the core..

I wouldn't put it in the Core. But I would put it in the Platform.

...

neither I think it's good to put it in the "big application" repository.

Right.

...

I don't think this is true for plugins which you prefer to have in the core so that they are ready to use on any recent XWiki install.

Same applies to plugins. There are some that are Core plugins and there are some that reusable plugins that can bundled in applications but not needed in the core.

In order to close this proposal, I'd like to know what others think about this remaining issue between Ludovic's vision and mine. I have the feeling the issue is more a terminology issue than anything else though.

Thanks -Vincent

...

Ludovic

Vincent Massol a écrit :

...

On Jun 17, 2007, at 12:00 PM, Ludovic Dubost wrote:

...

I'm giving an overall +1 to Vincent's proposal except for the xarlets. I feed that having the xarlets in the platform will either make us end up with small applications in the platform, or have us mix small and big apps in xwiki-applications. I think we need xarlets outside but not in xwiki-applications.

So

1/ I agree with stephane xarlets should not be in the platform 2/ I agree with vincent that applications should be "big packages" like watch, curriki, chrono, xem.. It does not means they have to have java plugins but it means they deserve the "product" or "application" name..

So maybe

xwiki-xarlets (small XWiki applications) xwiki-products (product level XWiki applications)

The problem is that if you follow that logic you should also move xwiki plugins out of the platform as plugins are reusable code in the same manner xarlets are reusable UIs. Also, in the near future a xwiki components would be able to package both xwiki pages and Java code in a JAR so the distinctions between xarlets and plugins will be blurred and they'll simply be components. A component will be able to provide only code, UIs, or both. This means that all the code and UIs that make the default wiki will be scattered into various components.

So if we follow your logic that xarlets (and thus components) do not belong to the platform (and I think they do) then we end up with what I mentioned in my reply to Stephane:

xwiki/ |_ xwiki-core/ |_ xwiki-components/ (or whatever you want to call it) |_ xwiki-applications/

But my preference currently goes to:

xwiki/ |_ xwiki-platform/ |_ xwiki-core/ |_ xwiki-components/ |_ xwiki-applications

i.e. platform = core + reusable components (where core will become in the future a set of components itself and core will simply be a list of components that go together, i.e. a packaging)

WDYT?

Thanks -Vincent

...

Vincent Massol a écrit :

...

Any other feedback on this?

* So far we have Stephane and Sergiu who have answered. * Sergiu said he was ok with the structure I proposed * Stephane didn't quite agree and proposed something else to which I replied (no new answer from Stephane yet ;)).

We need to make way to XEM and Watch so I'd like to start implementing this ASAP. Please comment if you agree or don't agree as it'll be too late once I start the work :)

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

WDYT?

Thanks -Vincent

--You receive this message as a subscriber of the xwiki- dev@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

------------------------------------------------------------------ ------

-- You receive this message as a subscriber of the xwiki- dev@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

--Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

-- You receive this message as a subscriber of the xwiki- dev@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

-------------------------------------------------------------------- ----

-- You receive this message as a subscriber of the xwiki- dev@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

-- Ludovic Dubost Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost AIM: nvludo Yahoo: ludovic

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki- dev@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

Vincent Massol wrote:

OK, I talked to Ludovic on skype and he's agreed to the directory structure I proposed. In any case, we can always modify things (actually I'm pretty sure the final structure will not be exactly like the one I proposed as we'll find some gotchas along the way...).

I'm thus ready to start implementing it.

I'd like to start it ASAP (right now would even be my choice). It means that during 2-3 days the build won't work and it'll be a bit of chaos during that time.

Everyone ok with that?

Fine with me as well. Cheers Stéphane

On 6/21/07, Vincent Massol <vincent@massol.net> wrote:

I forgot one directory we need: a place where to put our top level POM. I'm proposing to put in:

/svnroot/xwiki/xwiki-platform/pom/

(and thus have trunk/, branches/ and tags/ beneath it)

ok for everyone?

How about tags and branches for what's outside the platform? -- http://purl.org/net/sergiu

Even better. Btw, I think there was a discussion on the term xar, and I think we agreed that it is not a good name, since it conflicts with another archive format. On 6/21/07, Vincent Massol <vincent@massol.net> wrote:

hmm... I'm just starting to implement the new structure and already I'd like to suggest 2 modifications:

1) Rename xwiki-applications into xwiki-products 2) Rename xarlets into xwiki-applications

WDYT?

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

Sergiu -- http://purl.org/net/sergiu

On Jun 21, 2007, at 7:40 PM, Sergiu Dumitriu wrote:

Even better.

Btw, I think there was a discussion on the term xar, and I think we agreed that it is not a good name, since it conflicts with another archive format.

Exactly which is why I'm suggesting a directory name that doesn't have "xar" in the name... ;) -Vincent

On 6/21/07, Vincent Massol <vincent@massol.net> wrote:

...

hmm... I'm just starting to implement the new structure and already I'd like to suggest 2 modifications:

1) Rename xwiki-applications into xwiki-products 2) Rename xarlets into xwiki-applications

WDYT?

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

Sergiu -- http://purl.org/net/sergiu

-- You receive this message as a subscriber of the xwiki- dev@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

I discovered a Maven2 bug yesterday which makes our build fail if you try it (it fails to download the XAR handler JAR). To fix this you need to create a ~/.m2/settings.xml file with the following inside: <settings> <profiles> <profile> <id>xwiki</id> <repositories> <repository> <id>xwiki</id> <name>XWiki Maven2 Remote Repository</name> <url>http://maven.xwiki.org</url> <releases> <enabled>true</enabled> </releases> </repository> </repositories> </profile> </profiles> <activeProfiles> <activeProfile>xwiki</activeProfile> </activeProfiles> </settings> This simply tells maven to add the xwiki remote repo to the list of repo it looks in when looking for an artifact that it doesn't find in your local repo. I'll document this. Even better, the m2 dev team has fixed it I think so I'll try to bundle a new snapshot that contains the fix but that'll take a bit of time so for now you're safe with the settings.xml thing. Thanks -Vincent On Jun 22, 2007, at 8:51 PM, Vincent Massol wrote:

Hi everyone,

Here's the current status:

* The m2 build works for everything except watch which isn't finished yet. * I haven't put back the Ant build as it's more work to maintain 2 builds and I think the m2 build is good enough not to require the Ant build.

Thus you can start doing some check outs and commits again. Please let me know of any issue you find and I'll fix it.

Improvements yet to come: * Add support for build numbering for having the SVN rev in version.properties (this is supposed through the buildnumber plugin in m2) * Finish the Watch build and add support for GWT compiler in the build (using the m2 gwt plugin) * Find out to automate generation of NSIS executables. * Move some of the old unit tests previously in xwiki/tests in the new dir structure and as unit tests done in isolation * Add a distribution module for the XEM build (and a distribution- test module for functional tests) * Update the building doc on xwiki.org to reflect the latest changes * Possibly add more svn:externals definitions if users/devs find that the main one is too all-encompassing * Find ways and documents them to do in place web development easily with the new structure

Thanks -Vincent

On Jun 21, 2007, at 5:59 PM, Vincent Massol wrote:

...

hmm... I'm just starting to implement the new structure and already I'd like to suggest 2 modifications:

1) Rename xwiki-applications into xwiki-products 2) Rename xarlets into xwiki-applications

WDYT?

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

WDYT?

Thanks -Vincent

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki- dev@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

It seems that the updated pom.xml files that were checked in which added the repository for xwiki-platoform-core (and a couple others) seems to break the syntax. Maven complained that there should only be one <repositories> tag, two seem to cause a problem with parsing the pom.xml file. David -- On 6/23/07, Vincent Massol <vincent@massol.net> wrote:

ok, it's now documented at:

http://www.xwiki.org/xwiki/bin/view/Community/SourceRepository http://www.xwiki.org/xwiki/bin/view/Community/Building

Let me know if something is missing.

Thanks -Vincent

On Jun 23, 2007, at 10:51 AM, Vincent Massol wrote:

...

I discovered a Maven2 bug yesterday which makes our build fail if you try it (it fails to download the XAR handler JAR). To fix this you need to create a ~/.m2/settings.xml file with the following inside:

<settings> <profiles> <profile> <id>xwiki</id> <repositories> <repository> <id>xwiki</id> <name>XWiki Maven2 Remote Repository</name> <url>http://maven.xwiki.org</url> <releases> <enabled>true</enabled> </releases> </repository> </repositories> </profile> </profiles> <activeProfiles> <activeProfile>xwiki</activeProfile> </activeProfiles> </settings>

This simply tells maven to add the xwiki remote repo to the list of repo it looks in when looking for an artifact that it doesn't find in your local repo.

I'll document this. Even better, the m2 dev team has fixed it I think so I'll try to bundle a new snapshot that contains the fix but that'll take a bit of time so for now you're safe with the settings.xml thing.

Thanks -Vincent

On Jun 22, 2007, at 8:51 PM, Vincent Massol wrote:

...

Hi everyone,

Here's the current status:

* The m2 build works for everything except watch which isn't finished yet. * I haven't put back the Ant build as it's more work to maintain 2 builds and I think the m2 build is good enough not to require the Ant build.

Thus you can start doing some check outs and commits again. Please let me know of any issue you find and I'll fix it.

Improvements yet to come: * Add support for build numbering for having the SVN rev in version.properties (this is supposed through the buildnumber plugin in m2) * Finish the Watch build and add support for GWT compiler in the build (using the m2 gwt plugin) * Find out to automate generation of NSIS executables. * Move some of the old unit tests previously in xwiki/tests in the new dir structure and as unit tests done in isolation * Add a distribution module for the XEM build (and a distribution- test module for functional tests) * Update the building doc on xwiki.org to reflect the latest changes * Possibly add more svn:externals definitions if users/devs find that the main one is too all-encompassing * Find ways and documents them to do in place web development easily with the new structure

Thanks -Vincent

On Jun 21, 2007, at 5:59 PM, Vincent Massol wrote:

...

hmm... I'm just starting to implement the new structure and already I'd like to suggest 2 modifications:

1) Rename xwiki-applications into xwiki-products 2) Rename xarlets into xwiki-applications

WDYT?

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

WDYT?

Thanks -Vincent

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki- dev@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

-- You receive this message as a subscriber of the xwiki-dev@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

Thanks, everything works very well for me so far. I'm using Eclipse here for development. This new structure is very convenient. Well done :-) I'll try to update the Eclipse building page asap: http://www.xwiki.org/xwiki/bin/view/Community/BuildingInEclipse Cheers Stéphane Vincent Massol wrote:

Hi everyone,

Here's the current status:

* The m2 build works for everything except watch which isn't finished yet. * I haven't put back the Ant build as it's more work to maintain 2 builds and I think the m2 build is good enough not to require the Ant build.

Thus you can start doing some check outs and commits again. Please let me know of any issue you find and I'll fix it.

Improvements yet to come: * Add support for build numbering for having the SVN rev in version.properties (this is supposed through the buildnumber plugin in m2) * Finish the Watch build and add support for GWT compiler in the build (using the m2 gwt plugin) * Find out to automate generation of NSIS executables. * Move some of the old unit tests previously in xwiki/tests in the new dir structure and as unit tests done in isolation * Add a distribution module for the XEM build (and a distribution-test module for functional tests) * Update the building doc on xwiki.org to reflect the latest changes * Possibly add more svn:externals definitions if users/devs find that the main one is too all-encompassing * Find ways and documents them to do in place web development easily with the new structure

Thanks -Vincent

On Jun 21, 2007, at 5:59 PM, Vincent Massol wrote:

...

hmm... I'm just starting to implement the new structure and already I'd like to suggest 2 modifications:

1) Rename xwiki-applications into xwiki-products 2) Rename xarlets into xwiki-applications

WDYT?

Thanks -Vincent

On Jun 12, 2007, at 6:36 PM, Vincent Massol wrote:

...

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 * xarlets/ contains independent xwiki apps (we need a word better than xarlets and different than applications which we should reserve for things like curriki, xwiki enterprise, xem, etc) that can be installed in any running xwiki app * In the future core/ will be replaced with: |_ components/ (JARs) |_ xwiki-model/ |_ xwiki-storage/ |_ ... * In the future web/ will be replaced with UI components (see the UI proposal for more)

Definition of xwiki-enterprise/ =======================

/svnroot/xwiki/xwiki-applications/xwiki-enterprise/ |_ wiki/ |_ distribution/ |_ distribution-test/

where:

* wiki/ contains the xar pages

Generic definition of an xwiki-application/ =================================

/svnroot/xwiki/xwiki-applications/<app name>/ |_ wiki/ |_ web/ (optional) |_ plugins/ (optional) |_ skin/ (optional) |_ distribution/ |_ distribution-test/

For example for xwiki-watch/:

/svnroot/xwiki/xwiki-applications/xwiki-watch/ |_ wiki/ |_ web/ (the gwt stuff) |_ distribution/ |_ distribution-test/

I think this pretty much includes everything we currently have in SVN.

WDYT?

Thanks -Vincent

-- You receive this message as a subscriber of the xwiki-dev@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

-- You receive this message as a subscriber of the xwiki-dev@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

-- Stéphane Laurière slauriere@xwiki.com XWiki Research http://www.xwiki.com http://concerto.xwiki.com http://nepomuk.semanticdesktop.org