vmassol (SVN) wrote:
> Author: vmassol
> Date: 2008-02-25 15:40:53 +0100 (Mon, 25 Feb 2008)
> New Revision: 7930
>
> Modified:
> xwiki-platform/xwiki-tools/trunk/xwiki-license-resources/src/main/resources/META-INF/NOTICE.vm
> Log:
> XTLICENSE-1: Add a remote resources JAR that includes XWiki License/Notice files
>
> * Fixed problem with missing EOL (not sure why but this fixes it).
>
That's how velocity works, #end at the end of the line eats the \n
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi JV,
On Feb 22, 2008, at 12:07 PM, jvdrean (SVN) wrote:
> Author: jvdrean
> Date: 2008-02-22 12:07:00 +0100 (Fri, 22 Feb 2008)
> New Revision: 7914
>
> Modified:
> xwiki-platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/
> xwiki/plugin/watchlist/WatchListJob.java
> xwiki-platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/
> xwiki/plugin/watchlist/WatchListPlugin.java
> xwiki-platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/
> xwiki/plugin/watchlist/WatchListPluginApi.java
> Log:
> XPWATCHLIST-12 : Global user can't watch sub-wiki's documents
>
[snip]
> + /**
> + * @return the full list of all database names of all defined
> virtual wikis. The database names
> + * are computed from the names of documents having a
> XWiki.XWikiServerClass object
> + * attached to them by removing the "XWiki.XWikiServer"
> prefix and making it lower case.
> + * For example a page named
> "XWiki.XWikiServerMyDatabase" would return "mydatabase" as
> + * the database name.
> + */
> + public List getVirtualWikisDatabaseNames(Context context, XWiki
> xwiki) throws XWikiException
> + {
> + List databaseNames = new ArrayList();
> +
> + String database = context.getDatabase();
> + try {
> + context.setDatabase(context.getMainWikiName());
> +
> + String hql =
> + ", BaseObject as obj, StringProperty as prop where
> obj.name=doc.fullName"
> + +
> + " and obj.name <>
> 'XWiki.XWikiServerClassTemplate' and
> obj.className='XWiki.XWikiServerClass' "
> + + "and prop.id.id = obj.id ";
> + List list = xwiki.searchDocuments(hql);
> +
> + for (Iterator it = list.iterator(); it.hasNext();) {
> + String docname = (String) it.next();
> + if (docname.startsWith("XWiki.XWikiServer")) {
> +
> databaseNames.add(docname.substring("XWiki.XWikiServer".length())
> + .toLowerCase());
> + }
> + }
> + } finally {
> + context.setDatabase(database);
> + }
> +
> + return databaseNames;
> + }
This method looks like a duplicate of the code in the XWiki class. Why
is that?
Thanks
-Vincent
Hi,
Has anyone already tried using Toucan 1.0 with XE 1.3M2?
Since we're going to release Toucan 1.1 today or tomorrow and XE
1.3RC1 today or tomorrow it would be great to get some feedback ASAP
if anything is not working as expected with the Toucan skin.
Thanks
-Vincent
Hi,
Just to let you know that I'm upgrading the Packager dep on XWiki Core
from 1.1.x to 1.3-SNAPSHOT. The main reason for the upgrade is to fix
this issue:
http://jira.xwiki.org/jira/browse/XWIKI-2134
For products who need to use an older version of the core, there are 2
solutions:
1) Use a version on packager up to 1.8 since starting from 1.9 it'll
depend on core 1.3
2) Branch the packager module
Thanks
-Vincent
Hi,
We need to decide if we want to have a single SVN repository or
several. Right now we have 4:
- main xwiki: XE, XEM, Watch, Curriki
- chronopolys
- xwiki workspaces
- sandbox
I prefer to have a single one for the following reasons:
1) Simpler Admin
2) Consolidate history
3) Ability to move sources from one project to another. For example
the fact the sandbox is in a separate repo is a real pain since it's
not possible to perform a svn move so we loose the history when we
move things around
4) Complex to configure. You have to configure all your tools to point
to several repos (IDE, etc)
5) Hard to configure external tools and no consolidated search,
stats,etc. For example: ohloh, sourcekibitzer
Note that Apache has a single repo for all its projects so it's not
like this is something that is weird and that hasn't been done before.
To be honest I don't see a single advantage to have several repos.
However we would need to configure the SVN hooks to send svn commit
emails to different mailing lists and do the user authentication based
on *.xwiki.org mapped to directories in SVN, but that's not a problem.
WDYT?
Thanks
-Vincent
Hi,
Some projects have wrong dates planned for their schedules:
* XWiki Workspaces: 1.0M1 planned for 4th of Feb 2008.
* Chronopolys 1.0 planned for 21st of Feb 2008.
They need to be fixed and rescheduled.
Thanks
-Vincent
Hi JV,
We need to add functional tests for the Watchlist feature. Do you
think you could make sure to add tests for it?
I think we have 2 possible approaches:
1) unit testing, which means we catch the email before it's sent and
verify that it contains the correct things.
2) functional testing. This can be done very easily using Selenium and
using a tool like Dumbster inside the Selenium test. For an example of
using Dumbster, see
http://quintanasoft.com/dumbster/#Examples
Note that Dumbster is already in the central maven repo so it should
be dead easy to use.
Another possible tool to use is James (http://james.apache.org/)
I'd recommend doing 2).
WDYT?
Thanks
-Vincent
Hi,
I'd like to bring forward the release dates for XE 1.3 final, as
follows:
* 1.3RC1 - 25/02
* 1.3Final - 3/03
I'd also like to create a branch for 1.3 since it's now in RC stage
and trunk will become 1.4-SNAPSHOT so that committers eager to work on
1.4 can start doing so and so that we're not tempted to push non bug
changes in 1.3...
The reasons:
1) We're ready to release it barring any regression we have introduced
(which will be fixed in 1.3RC1)
2) Some of us are eager to work on 1.4 (like JV who's working on
performance improvements for ex) :)
3) I'd like to drop support for 1.2 ASAP since it's hard to support
several branches at once. When 1.3 is released it means we will be
supporting 1.3 and 1.4 but no longer 1.2 (since our standard rule is
to support 2 versions - Of course anyone is free to support whatever
he wants but this is our general rule to make it easy to progress in
our devs).
4) 1.3 hasn't had any major changes since 1.2 and thus should be
pretty stable
Here's my +1 to both the new dates and the branch creation.
Thanks
-Vincent
Hi Thomas,
On Feb 21, 2008, at 3:07 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2008-02-21 15:07:45 +0100 (Thu, 21 Feb 2008)
> New Revision: 7902
>
> Modified:
> xwiki-platform/xwiki-tools/trunk/xwiki-configuration-resources/src/
> main/resources/xwiki.cfg.vm
> Log:
> Improve LDAP default configuration
>
> Modified: xwiki-platform/xwiki-tools/trunk/xwiki-configuration-
> resources/src/main/resources/xwiki.cfg.vm
> ===================================================================
> --- xwiki-platform/xwiki-tools/trunk/xwiki-configuration-resources/
> src/main/resources/xwiki.cfg.vm 2008-02-21 14:06:38 UTC (rev 7901)
> +++ xwiki-platform/xwiki-tools/trunk/xwiki-configuration-resources/
> src/main/resources/xwiki.cfg.vm 2008-02-21 14:07:45 UTC (rev 7902)
> @@ -84,15 +84,15 @@
> #-------------------------------------------------------------------------------------
>
> #-# new LDAP authentication service
> -#
> xwiki
> .authentication
> .authclass=com.xpn.xwiki.ldap.authentication.XWikiLDAPAuthServiceImpl
> +#
> xwiki
> .authentication
> .authclass=com.xpn.xwiki.user.impl.LDAP.XWikiLDAPAuthServiceImpl
>
> #-# Turn LDAP authentication on - otherwise only XWiki authentication
> #-# 0 : disable
> #-# 1 : enable
> -xwiki.authentication.ldap=0
> +# xwiki.authentication.ldap=1
Why is LDAP authentication on by default?
I would have assumed it to be off by default since the default
authentication mechanism is to use xwiki's DB. I know the new LDAP
impl will try XWiki's DB if it can't log on LDAP but that's not a good
thing to do by default since everyone will incur some overhead and the
fact that LDAP is on by default is misleading in this case.
Note: I may have missed something since I've been off for 2 days and
only unpiling my emails now ;)
Thanks
-Vincent
Hi devs,
I've seen that lots of bugs have been fixed and several improvements
introduced. For most of them the issues have been closed without tests
and this is really not good. We've decided that the 1.3 release would
be the release when we start adding tests and even though some efforts
were made for 1.3M2 this is not regressing in 1.3RC1 and it's not good.
Could those who've been doing commits recently try to spend some more
time on the tests please?
Note: A special congrats to Thomas who's done the LDAP integration
tests :)
Thanks
-Vincent