February 2008 - xwiki-devs@xwiki.org

[xwiki-devs] Fwd: [ANN] Maven Stage Plugin 1.0-alpha-1 Released
by Vincent Massol 25 Feb '08

25 Feb '08

fyi. We should probably do our releases through a staged process too. This allows: 1) giving binaries to people so that they can test 2) voting on something tangible and not on sources which can be modified before they're really released 3) ability to rollback a release if something is found faulty during the release -Vincent Begin forwarded message: > From: "Wendy Smoak" <wsmoak(a)apache.org> > Date: February 23, 2008 4:38:42 AM CEST > To: announce(a)maven.apache.org > Subject: [ANN] Maven Stage Plugin 1.0-alpha-1 Released > Reply-To: users(a)maven.apache.org > Reply-To: wsmoak(a)apache.org > > The Maven team is pleased to announce the first release of the Maven > Stage > Plugin, version 1.0-alpha-1. > > http://maven.apache.org/plugins/maven-stage-plugin/ > > This plugin assists with staging and promoting releases by allowing > you to > copy artifacts from one repository to another. It currently supports > copying from http|https to scp urls. > > You can run 'mvn -up stage:copy ... ' to get the latest version of the > plugin. > > (Nothing was closed in JIRA for this initial release, so there are no > release notes.) > > Enjoy, > -- > Wendy Smoak > on behalf of the Maven team >

1 0

[xwiki-devs] XWiki Attachments
by Kamna Jain 25 Feb '08

25 Feb '08

Hi, I was trying to compare XWiki with some of the functionality of MediaWiki. One of my concerns about attchements is the security. For example,Do the page access rights in XWiki, apply also to the attachements of that page? In mediawiki, there is special page called File list where one can go and see the entire list of files uploaded to the wiki. But, if we want to allow access restrictions to those, this should not be allowed. So, does XWiki take care of this issue? Not allowing restricted users from viewing confodential attachemnts at all. Also, what is the syntax of XWiki and how is it different from Mediawiki if at all it is? Thanks

3 2

Re: [xwiki-devs] [xwiki-notifications] r7930 - xwiki-platform/xwiki-tools/trunk/xwiki-license-resources/src/main/resources/META-INF
by Sergiu Dumitriu 25 Feb '08

25 Feb '08

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/

2 1

Re: [xwiki-devs] [xwiki-notifications] r7914 - xwiki-platform/xwiki-plugins/trunk/watchlist/src/main/java/com/xpn/xwiki/plugin/watchlist
by Vincent Massol 25 Feb '08

25 Feb '08

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

2 3

[xwiki-devs] Has anyone used the new Toucan skin?
by Vincent Massol 25 Feb '08

25 Feb '08

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

1 0

[xwiki-devs] Upgrade Packager module dep to Core 1.3-SNAPSHOT
by Vincent Massol 25 Feb '08

25 Feb '08

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

1 0

[xwiki-devs] Single SVN repository vs several
by Vincent Massol 25 Feb '08

25 Feb '08

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

5 5

[xwiki-devs] Cleaning JIRA release dates
by Vincent Massol 25 Feb '08

25 Feb '08

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

3 2

[xwiki-devs] Testing the Watchlist feature
by Vincent Massol 24 Feb '08

24 Feb '08

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

2 1

[xwiki-devs] [VOTE] Bring forward XE 1.3 final + create branch
by Vincent Massol 24 Feb '08

24 Feb '08

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

3 3