19 Apr
2007
19 Apr
'07
11:52 p.m.
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files from
the generated WAR.
What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made configurations
for XWiki: for HSQLDB, for MySQL, for Oracle, with a minimal list of
plugins configured, with all plugins enabled, with virtual wiki set
up, etc. It's going to be way better to release a single WAR that is
the same for all configs and a set of config files separately. This
also makes it much easier in the build process.
2) It's currently a little bit of a pain for users when they upgrade
their xwiki installation to a newer version. They have to remember to
save their config files, to unpack the XWiki WAR, modify the
configuration files, etc. What if an upgrade was a simple as dropping
the new WAR file in the webapps/ directory of your servlet container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say for
example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the
web.xml file (as an init parameter)
2) if not found, it checks if the files can be found at the root
of the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured
directory structure which uses the system property strategy for
finding the configuration directory.
<further future - but not too far as it's the best solution I think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc). It
generate the files that can be downloaded by the users. Actually this
can even be implemented as a XWiki Application... ;-) Eating our dog
food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the first
time XWiki is started. This is really by far the best I believe.
</further future>
WDYT?
Thanks
-Vincent
20 Apr
20 Apr
1:33 a.m.
New subject: [xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR
This is already possible with a variable telling where to find xwiki.cfg
From there you can specify where to find the hibernate file
From there you can specify where to find the hbm files (however I think
these have to be in the classpath)
See this code in XWiki.java
private static String getConfigPath() throws NamingException
{
if (configPath == null) {
try {
Context envContext = (Context) new
InitialContext().lookup("java:comp/env");
configPath = (String) envContext.lookup(CFG_ENV_NAME);
} catch (Exception e) {
// Allow a config path from WEB-INF
if (log.isInfoEnabled())
log
.info("xwiki.cfg taken from /WEB-INF/xwiki.cfg
because the XWikiConfig variable is not set in the context");
configPath = "/WEB-INF/xwiki.cfg";
}
}
return configPath;
}
Ludovic
Vincent Massol a écrit :
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files from
the generated WAR.
What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made configurations
for XWiki: for HSQLDB, for MySQL, for Oracle, with a minimal list of
plugins configured, with all plugins enabled, with virtual wiki set
up, etc. It's going to be way better to release a single WAR that is
the same for all configs and a set of config files separately. This
also makes it much easier in the build process.
2) It's currently a little bit of a pain for users when they upgrade
their xwiki installation to a newer version. They have to remember to
save their config files, to unpack the XWiki WAR, modify the
configuration files, etc. What if an upgrade was a simple as dropping
the new WAR file in the webapps/ directory of your servlet container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say for
example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the web.xml
file (as an init parameter)
2) if not found, it checks if the files can be found at the root of
the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured directory
structure which uses the system property strategy for finding the
configuration directory.
<further future - but not too far as it's the best solution I think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc). It
generate the files that can be downloaded by the users. Actually this
can even be implemented as a XWiki Application... ;-) Eating our dog
food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the first
time XWiki is started. This is really by far the best I believe.
</further future>
WDYT?
Thanks
-Vincent
------------------------------------------------------------------------
--
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
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
9:19 a.m.
New subject: [xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR
If it's already possible then cool. Right now I'm more interested in
having a default configuration strategy that we all agree on, use
ourselves in our distributions and document.
Thanks
-Vincent
On Apr 20, 2007, at 1:33 AM, Ludovic Dubost wrote:
This is already possible with a variable telling where to find
xwiki.cfg
From there you can specify where to find the hibernate file
From there you can specify where to find the hbm files (however I
think these have to be in the classpath)
See this code in XWiki.java
private static String getConfigPath() throws NamingException
{
if (configPath == null) {
try {
Context envContext = (Context) new InitialContext
().lookup("java:comp/env");
configPath = (String) envContext.lookup(CFG_ENV_NAME);
} catch (Exception e) {
// Allow a config path from WEB-INF
if (log.isInfoEnabled())
log
.info("xwiki.cfg taken from /WEB-INF/
xwiki.cfg because the XWikiConfig variable is not set in the
context");
configPath = "/WEB-INF/xwiki.cfg";
}
}
return configPath;
}
Ludovic
Vincent Massol a écrit :
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files
from the generated WAR.
What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made
configurations for XWiki: for HSQLDB, for MySQL, for Oracle, with
a minimal list of plugins configured, with all plugins enabled,
with virtual wiki set up, etc. It's going to be way better to
release a single WAR that is the same for all configs and a set of
config files separately. This also makes it much easier in the
build process.
2) It's currently a little bit of a pain for users when they
upgrade their xwiki installation to a newer version. They have to
remember to save their config files, to unpack the XWiki WAR,
modify the configuration files, etc. What if an upgrade was a
simple as dropping the new WAR file in the webapps/ directory of
your servlet container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say
for example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the
web.xml file (as an init parameter)
2) if not found, it checks if the files can be found at the root
of the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured
directory structure which uses the system property strategy for
finding the configuration directory.
<further future - but not too far as it's the best solution I think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc). It
generate the files that can be downloaded by the users. Actually
this can even be implemented as a XWiki Application... ;-) Eating
our dog food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the
first time XWiki is started. This is really by far the best I
believe.
</further future>
WDYT?
Thanks
-Vincent
---------------------------------------------------------------------
---
--
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
--
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(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
10:51 p.m.
New subject: [xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR
The main reason we haven't even used this ourselves is that it requires
creating a configuration file in the app server (tomcat/conf/ for tomcat)
And in the end it's actually easier to keep a backup of xwiki.cfg
hibernate.cfg.xml and other files needed and overwrite them when
upgrading the war file.
This is true for tomcat since it explodes war files by default and you
can upgrade files by copying.
This is more complex in other app servers especially those that don't
even explode the war file.
I'm not sure there is a current benefit of doing things differently.
So I believe we should properly document how to keep config files
separate but I don't think we should push our tomcat users to actually
use that feature since it does not provide administration benefits.
Or maybe I'm missing a benefit ?
Ludovic
Vincent Massol a écrit :
If it's already possible then cool. Right now
I'm more interested in
having a default configuration strategy that we all agree on, use
ourselves in our distributions and document.
Thanks
-Vincent
On Apr 20, 2007, at 1:33 AM, Ludovic Dubost wrote:
--
Ludovic Dubost
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
AIM: nvludo Yahoo: ludovic
This is already possible with a variable telling where to find xwiki.cfg
From there you can specify where to find the hibernate file
From there you can specify where to find the hbm files (however I
think these have to be in the classpath)
See this code in XWiki.java
private static String getConfigPath() throws NamingException
{
if (configPath == null) {
try {
Context envContext = (Context) new
InitialContext().lookup("java:comp/env");
configPath = (String) envContext.lookup(CFG_ENV_NAME);
} catch (Exception e) {
// Allow a config path from WEB-INF
if (log.isInfoEnabled())
log
.info("xwiki.cfg taken from /WEB-INF/xwiki.cfg
because the XWikiConfig variable is not set in the context");
configPath = "/WEB-INF/xwiki.cfg";
}
}
return configPath;
}
Ludovic
Vincent Massol a écrit :
------------------------------------------------------------------------
--
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
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files from
the generated WAR.
What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made configurations
for XWiki: for HSQLDB, for MySQL, for Oracle, with a minimal list of
plugins configured, with all plugins enabled, with virtual wiki set
up, etc. It's going to be way better to release a single WAR that is
the same for all configs and a set of config files separately. This
also makes it much easier in the build process.
2) It's currently a little bit of a pain for users when they upgrade
their xwiki installation to a newer version. They have to remember
to save their config files, to unpack the XWiki WAR, modify the
configuration files, etc. What if an upgrade was a simple as
dropping the new WAR file in the webapps/ directory of your servlet
container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say for
example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the
web.xml file (as an init parameter)
2) if not found, it checks if the files can be found at the root
of the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured
directory structure which uses the system property strategy for
finding the configuration directory.
<further future - but not too far as it's the best solution I think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc). It
generate the files that can be downloaded by the users. Actually
this can even be implemented as a XWiki Application... ;-) Eating
our dog food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the first
time XWiki is started. This is really by far the best I believe.
</further future>
WDYT?
Thanks
-Vincent
------------------------------------------------------------------------
--
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
--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(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
21 Apr
21 Apr
11:02 a.m.
New subject: [xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR
On Apr 20, 2007, at 10:51 PM, Ludovic Dubost wrote:
The main reason we haven't even used this ourselves is that it
requires creating a configuration file in the app server (tomcat/
conf/ for tomcat)
And in the end it's actually easier to keep a backup of xwiki.cfg
hibernate.cfg.xml and other files needed and overwrite them when
upgrading the war file.
Well this is not easier than having those files separate so that an
upgrade doesn't even need to copy them and overwrite existing files.
When I install an upgrade of an application i Windows XP or Mac OSX
I'm extremelly thankful that I don't have to migrate my config
files... :)
This is true for tomcat since it explodes war files by
default and
you can upgrade files by copying.
This is dangerous BTW as you're not supposed to play with exploded
war files (and all app server do this but some of them hide the
exploded files). The behavior could be unpredictable if you have both
a .war file and its exploded version in the same dir. Imagine that
war file is "touch"ed somehow for example. So a best practice would
be to always manually explode the WAR and not drop the .war file (for
containers which support this as they don't all support it I think).
This is more complex in other app servers especially
those that
don't even explode the war file.
I'm not sure there is a current benefit of doing things differently.
So I believe we should properly document how to keep config files
separate but I don't think we should push our tomcat users to
actually use that feature since it does not provide administration
benefits.
Or maybe I'm missing a benefit ?
hmmm... So does it mean you don't agree with the 2 points I posted in
my original mail? I'm summarizing them again here:
- easier upgrade paths
- much simpler build handling but more importantly the ability for us
to distribute various official and approved configs. We could do that
with full WARs too but it's going to be physically impossible once we
want to release more than , say, 3 or 4 as uploading a 40MB file is a
pain...
All that said, if you read my other emails on this thread, I believe
there are issues so I'm not sure myself what's the best option. The
config zip that is overlayed on top of an existing WAR might be a
good solution. The wizard that executes on the first run is probably
the best solution though as it can cope with any configuration and
doesn't require that we deliver more files. It'll just have to use
our remote Maven repo to download required libraries (like jdbc
drivers).
Right now I have implemented the several WARs/configuration solution
in our M2 build.
Thanks
-Vincent
Ludovic
Vincent Massol a écrit :
If it's already possible then cool. Right now
I'm more interested
in having a default configuration strategy that we all agree on,
use ourselves in our distributions and document.
Thanks
-Vincent
On Apr 20, 2007, at 1:33 AM, Ludovic Dubost wrote:
--
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(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
This is already possible with a variable telling where to find
xwiki.cfg
From there you can specify where to find the hibernate file
From there you can specify where to find the hbm files (however I
think these have to be in the classpath)
See this code in XWiki.java
private static String getConfigPath() throws NamingException
{
if (configPath == null) {
try {
Context envContext = (Context) new InitialContext
().lookup("java:comp/env");
configPath = (String) envContext.lookup
(CFG_ENV_NAME);
} catch (Exception e) {
// Allow a config path from WEB-INF
if (log.isInfoEnabled())
log
.info("xwiki.cfg taken from /WEB-INF/
xwiki.cfg because the XWikiConfig variable is not set in the
context");
configPath = "/WEB-INF/xwiki.cfg";
}
}
return configPath;
}
Ludovic
Vincent Massol a écrit :
---------------------------------------------------------------------
---
--
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
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files
from the generated WAR.
What I mean by configuration files: xwiki.cfg,
hibernate.cfg.xml, xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made
configurations for XWiki: for HSQLDB, for MySQL, for Oracle,
with a minimal list of plugins configured, with all plugins
enabled, with virtual wiki set up, etc. It's going to be way
better to release a single WAR that is the same for all configs
and a set of config files separately. This also makes it much
easier in the build process.
2) It's currently a little bit of a pain for users when they
upgrade their xwiki installation to a newer version. They have
to remember to save their config files, to unpack the XWiki WAR,
modify the configuration files, etc. What if an upgrade was a
simple as dropping the new WAR file in the webapps/ directory of
your servlet container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say
for example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the
web.xml file (as an init parameter)
2) if not found, it checks if the files can be found at the
root of the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured
directory structure which uses the system property strategy for
finding the configuration directory.
<further future - but not too far as it's the best solution I
think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc).
It generate the files that can be downloaded by the users.
Actually this can even be implemented as a XWiki
Application... ;-) Eating our dog food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the
first time XWiki is started. This is really by far the best I
believe.
</further future>
WDYT?
Thanks
-Vincent
-------------------------------------------------------------------
-----
--
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
--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(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
20 Apr
20 Apr
9:17 a.m.
New subject: [xwiki-dev] [Proposal] Separate xwiki configuration from the XWiki WAR
Ok, I missed 2 important points in the proposal below:
1) where do we put the required JARs for both the JDBC drivers and
for the plugins?
2) do we want to benefit from app server features like clustering, etc.?
For 1), one option would be to create a lib/ directory in the xwiki
configuration directory and inside XWiki use a URLClassloader that
inherits from the webapp classloader (or the context classloader) and
adds this lib/ directory to the mix.
For 2), that's a bigger issue. If we want to benefit from all app
server features like session persistence, transparent clustering, etc
we need to abide by the container rules I think. I'm not sure but I
think we might have an issue by doing our own file access/io to an
"external" directory. That said this is what JIRA does for example so
we might want to check this out. I think the official J2EE solution
is to store the configuration into JNDI. That won't solve issue 1) I
think.
I'd like your input please. It's possible that point 2) isn't an
issue in practice.
I still believe it would be neat to have a common WAR and separate
configurations. Hmm.... An another option would be to package the
configuration into a zip/jar and have the user expand it over the
xwiki WAR. This should cater for issues 1) and 2) above. However it
doesn't solve the easy upgrade (see point 2) below in my original
mail) but maybe that's a lesser problem.
Of course that last solution is to provide already made WARs for
specific configurations but that's harder in the build (but doable -
I have been able to implement this in the m2 build). Maybe this
combined with the configuration wizard would be good enough? It's
still less good I think than if were able to release separately the
WAR from the configuration.
WDYT?
Thanks
-Vincent
On Apr 19, 2007, at 11:52 PM, Vincent Massol wrote:
Hi,
For XWiki 1.1 I'd like to separate XWiki's configuration files from
the generated WAR.
What I mean by configuration files: xwiki.cfg, hibernate.cfg.xml,
xwiki.hbm, feeds.hbm and possibly some others.
Rationale:
1) It would be nice to release different already made
configurations for XWiki: for HSQLDB, for MySQL, for Oracle, with a
minimal list of plugins configured, with all plugins enabled, with
virtual wiki set up, etc. It's going to be way better to release a
single WAR that is the same for all configs and a set of config
files separately. This also makes it much easier in the build process.
2) It's currently a little bit of a pain for users when they
upgrade their xwiki installation to a newer version. They have to
remember to save their config files, to unpack the XWiki WAR,
modify the configuration files, etc. What if an upgrade was a
simple as dropping the new WAR file in the webapps/ directory of
your servlet container? :)
Thus I'd like to propose the following strategy:
* XWiki looks for where the config files are stored using the
following algorithm:
1) first it checks if a system property has been defined (say for
example "xwiki.configuration.directory")
1) if not, it checks if a location has been specified in the
web.xml file (as an init parameter)
2) if not found, it checks if the files can be found at the root
of the classpath (e.g. "/xwiki.cfg")
* The standalone distribution contains an already configured
directory structure which uses the system property strategy for
finding the configuration directory.
<further future - but not too far as it's the best solution I think>
We should propose a configuration wizard application which is in
charge of generating xwiki configuration files. I propose the
following distribution channels:
- as a webapp wizard configured on xwiki.org. Users use forms to
select what they want (which plugin, virtual wiki or not, etc). It
generate the files that can be downloaded by the users. Actually
this can even be implemented as a XWiki Application... ;-) Eating
our dog food they said...
- as a webapp wizard released inside the default WAR and that is
activated automatically if no configuration is found, i.e. the
first time XWiki is started. This is really by far the best I believe.
</further future>
WDYT?
Thanks
-Vincent
--
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
6411
days inactive
6413
days old
5 comments
2 participants
participants (2)
-
Ludovic Dubost -
Vincent Massol