Hi,
MadOtis on IRC told me that users he had created with a staged RC1
version cannot see the Main/WebHome page even though they have the
correct rights set up. Only new users created with the new RC1 can.
I haven't reviewed the last changes we did in the released RC1 but we
need to verify if this is a problem with users created in past betas
and if so add some instructions in the release notes for migrating
old users so that they work.
Sergiu, maybe you know what the issue is?
Thanks
-Vincent
Hi committers,
I see that we're now quite good at putting jira references in our
first commits. That's good! However sometimes when we make a mistake,
or forget something to commit, we don't put again the reference to
the JIRA issue in the subsequent commits.
It would be better if we were always putting the reference to JIRA.
For example, I fixed something related to XWIKI-49 this morning and I
used the following format:
"
XWIKI-49: PDF generation failed with vietnamese characters encoded in
UTF-8
* Replaced SNAPSHOT by a timestamped version so that the build can be
reproduced and so that we can perform a release of RC2 tomorrow.
* Moved out the JTidy <dependency> as it was now wrongly in the
"custom xwiki repository" section.
* Removed JTidy from our custom XWiki repository
"
Why do we need this?
Because it then makes it very easy later on to find what happened
related to a JIRA issue. We had this need for example when we were
trying to find out the difference between 2 branches (you may
remember, I spent a whole day on that a month ago). Thanks to the
Subversion plugin in JIRA we can see what happens related to an
issue. For example:
http://jira.xwiki.org/jira/browse/XWIKI-49?
page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-
tabpanel
However that only works if we have put a reference to the jira issue
in the commit log.
Thanks
-Vincent
Hi Sergiu,
Just to let you know it's dangerous to depend on a snapshot version
as it means anytime they update their snapshot we'll get the update
so our build can start to fail at any time. Also, we cannot release
XWiki if we have snapshot versions (at least that's the maven
strategy and maven will even prevent you from doing a release) so
we'll need to fix before we release 1.1 B1.
I see Hibernate has used some timestamped versions, maybe we could do
the same or use their versions:
http://repo1.maven.org/maven2/org/hibernate/jtidy/
Thanks
-Vincent
On Apr 24, 2007, at 4:25 AM, Sergiu Dumitriu wrote:
> Author: sdumitriu
> Date: 2007-04-24 04:25:11 +0200 (Tue, 24 Apr 2007)
> New Revision: 2972
>
> Modified:
> xwiki/trunk/pom.xml
> Log:
> Adding the JTidy maven repository to the list of known repos.
>
>
>
> Modified: xwiki/trunk/pom.xml
> ===================================================================
> --- xwiki/trunk/pom.xml 2007-04-24 01:57:38 UTC (rev 2971)
> +++ xwiki/trunk/pom.xml 2007-04-24 02:25:11 UTC (rev 2972)
> @@ -55,6 +55,14 @@
> <enabled>true</enabled>
> </releases>
> </repository>
> + <repository>
> + <id>jtidy</id>
> + <name>JTidy Maven2 Remote Repository</name>
> + <url>http://jtidy.sourceforge.net/snapshots/</url>
> + <releases>
> + <enabled>true</enabled>
> + </releases>
> + </repository>
> </repositories>
> </project>
>
> \ No newline at end of file
Ludovic,
Do we already have an issue associated with this?
Thanks
-Vincent
On Apr 24, 2007, at 3:39 AM, Ludovic Dubost wrote:
> Author: ludovic
> Date: 2007-04-24 03:38:37 +0200 (Tue, 24 Apr 2007)
> New Revision: 2970
>
> Modified:
> xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/user/
> impl/xwiki/MyPersistentLoginManager.java
> Log:
> Fixed regression on cleanup impacting rememberme cookie
>
>
> Modified: xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/
> user/impl/xwiki/MyPersistentLoginManager.java
> ===================================================================
> --- xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/user/
> impl/xwiki/MyPersistentLoginManager.java 2007-04-24 01:36:29 UTC
> (rev 2969)
> +++ xwiki/branches/XWIKI_1_0/core/src/main/java/com/xpn/xwiki/user/
> impl/xwiki/MyPersistentLoginManager.java 2007-04-24 01:38:37 UTC
> (rev 2970)
> @@ -38,7 +38,7 @@
> * Class responsible for remembering the login information between
> requests. It uses (encrypted)
> * cookies for this. The encryption key is stored in xwiki.cfg,
> xwiki.authentication.encryptionKey
> * parameter.
> - *
> + *
> * The cookies used are:
> * <dl>>
> * <dt>username</dt>
> @@ -54,7 +54,7 @@
> * xwiki.authentication.useip . The secret parameter is specified in
> * xwiki.authentication.validationKey</dd>
> * </dl>
> - *
> + *
> * @version $Id: $
> */
> public class MyPersistentLoginManager extends
> DefaultPersistentLoginManager
> @@ -97,7 +97,7 @@
>
> /**
> * Setter for the {@link #cookieDomains} parameter.
> - *
> + *
> * @param cdlist The new value for {@link #cookieDomains}.
> * @see #cookieDomains
> */
> @@ -108,7 +108,7 @@
>
> /**
> * Setter for the {@link #cookiePath} parameter.
> - *
> + *
> * @param cp The new value for {@link #cookiePath}.
> * @see #cookiePath
> */
> @@ -119,7 +119,7 @@
>
> /**
> * Setup a cookie: expiration date, path, domain + send it to
> the response.
> - *
> + *
> * @param cookie The cookie to setup.
> * @param sessionCookie Whether the cookie is only for this
> session, or for a longer period.
> * @param cookieDomain The domain for which the cookie is set.
> @@ -140,7 +140,7 @@
>
> /**
> * Remember a specific login using cookies.
> - *
> + *
> * @param request The servlet request.
> * @param response The servlet response.
> * @param username The username that's being remembered.
> @@ -177,7 +177,7 @@
> setupCookie(passwdCookie, sessionCookie, cookieDomain,
> response);
>
> // Remember me
> - Cookie rememberCookie = new Cookie(COOKIE_REMEMBERME,
> sessionCookie + "");
> + Cookie rememberCookie = new Cookie(COOKIE_REMEMBERME, !
> sessionCookie + "");
> setupCookie(rememberCookie, sessionCookie, cookieDomain,
> response);
>
> if (protection.equals(PROTECTION_ALL) || protection.equals
> (PROTECTION_VALIDATION)) {
> @@ -202,7 +202,7 @@
> /**
> * Sets the maximum age for cookies. The maximum age is
> configured in xwiki.cfg using the
> * xwiki.authentication.cookielife parameter (number of days).
> The default age is 14 days.
> - *
> + *
> * @param cookie The cookie for which the expiration date is
> configured.
> */
> private void setMaxAge(Cookie cookie)
> @@ -218,7 +218,7 @@
>
> /**
> * Adds a cookie to the response.
> - *
> + *
> * @param response The servlet response.
> * @param cookie The cookie to be sent.
> */
> @@ -235,7 +235,7 @@
> * Compute the actual domain the cookie is supposed to be set
> for. Search through the list of
> * generalized domains for a partial match. If no match is
> found, then no specific domain is
> * used, which means that the cookie will be valid only for
> the requested domain.
> - *
> + *
> * @param request The servlet request.
> * @return The configured domain generalization that matches
> the request, or null if no match is
> * found.
> @@ -261,10 +261,10 @@
> /**
> * Get validation hash for the specified parameters. The hash
> includes a secret password, and
> * optionally binds the cookie to the requester's IP.
> - *
> + *
> * The hash secret is configured using the
> xwiki.authentication.validationKey parameter. The IP
> * binding is enabled using the xwiki.authentication.useip
> parameter.
> - *
> + *
> * @param username The remembered username.
> * @param password The remembered password.
> * @param clientIP The client IP of the request.
> @@ -319,7 +319,7 @@
> /**
> * Encrypt a string. The encryption is password-based. The
> password can be configured using the
> * xwiki.authentication.encryptionKey parameter.
> - *
> + *
> * @param clearText The text to be encrypted.
> * @return clearText, encrypted.
> * @todo Optimize this code by creating the Cipher only once.
> @@ -351,7 +351,7 @@
>
> /**
> * Forget a login by removing the authentication cookies.
> - *
> + *
> * @param request The servlet request.
> * @param response The servlet response.
> */
> @@ -369,7 +369,7 @@
> * Given an array of cookies and a name, this method tries to
> find and return the cookie from
> * the array that has the given name. If there is no cookie
> matching the name in the array, null
> * is returned.
> - *
> + *
> * @param cookies The list of cookies sent by the client.
> * @param cookieName The name of the cookie to be retrieved.
> * @return The requested cookie, or null if no cookie with the
> given name was found.
> @@ -389,7 +389,7 @@
>
> /**
> * Remove a cookie.
> - *
> + *
> * @param request The servlet request.
> * @param response The servlet response.
> * @param cookieName The name of the cookie that must be removed.
> @@ -411,7 +411,7 @@
>
> /**
> * Check if a text is supposed to be an affirmative value
> ("true", "yes" or "1").
> - *
> + *
> * @param text The text to check.
> * @return true if the text is one of "true", "yes" or "1",
> false otherwise.
> */
>
>
>
> --
> You receive this message as a subscriber of the xwiki-
> commits(a)objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-commits-unsubscribe@objectweb.org
> For general help: mailto:sympa@objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/
> wws
Hi,
We have lots of jira tasks scheduled for 1.1 but I don't think that's
right. According to our new strategy we're only scheduling issues
that we know we want to do in a given release. I think we've used 1.1
in the past as a way to say "later". But we have "future" for this
now. So I'd like to move all the tasks in 1.1 into "Future" if that's
ok with you.
Let me know.
Note: We also need to continue moving the issues that have no "fix
for" set (unscheduled issues). There are 76 of these.
Thanks
-Vincent
Hi everyone,
As release manager of the 1.0 version I'd like everyone's input on
any important pending issues that you may know and that would need to
be in the 1.0 release. As you've seen we've released RC1 yesterday.
We'd now like to release the 1.0 version in one or two weeks
depending on issues that need to be fixed.
I've already listed one issue in JIRA for 1.0:
* XWIKI-1107: XML content inside {code} macro is rendered in the
WYSIWYG editor
http://jira.xwiki.org/jira/browse/XWIKI-1107
Any other?
Thanks
-Vincent
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