Great job everyone!
Ruel Loehr wrote:
Two versions of JBossAS were released today. The released versions
include JBossAS 3.2.8 and JBossAS 4.0.4RC1.
These releases can be downloaded from the following location:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16
BEGIN:VCALENDAR
METHOD:REPLY
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-06.00) Central Time (US & Canada)
X-MICROSOFT-CDO-TZID:11
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-
BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft CDO for Microsoft Exchange
VERSION:2.0
BEGIN:VTIMEZONE
TZID:(GMT-06.00) Central Time (US & Canada)
X-MICROSOFT-CDO-TZID:11
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0600
RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY
Two versions of JBossAS were released today. The released
versions include JBossAS 3.2.8 and JBossAS 4.0.4RC1.
These releases can be downloaded from the following
location:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942
Thank you,
Ruel Loehr
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-4.0-compatibility-matrix?log=log20060207174433
BUILD FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-common.xml:228: The following error occurred while executing this line: /services/cruisecontrol/w
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite-1.5?log=log20060207151724
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-jboss-remoting.xml:96: The following error occurred while executing this line: /services/cruisecontrol/wo
anyone who knows the resolution for this one ?
An error occurred synchronizing /org.jbpm.ui.test: The server reported
an error while performing the "cvs status" command.
The server reported an error while performing the "cvs status" command.
org.jbpm.ui.test: cvs status: failed to
On Tue, 07 Feb 2006 20:55:52 +0100, Scott M Stark <[EMAIL PROTECTED]>
wrote:
fixing the antlr exception svuid won't help us if the client
is using an older version, right ?
It will if the serialVersionUID is set to the implicit value from the
previous version. This can be done if the version
> fixing the antlr exception svuid won't help us if the client
> is using an older version, right ?
>
It will if the serialVersionUID is set to the implicit value from the
previous version. This can be done if the version is still serializable
compatible.
> calling printStackTrace() on every exc
fixing the antlr exception svuid won't help us if the client is using
an older version, right ?
calling printStackTrace() on every exception sounds overkill for me...and
will turn basic logging into something very verbose.
I understand the issue, but don't find the suggested solutions any good
I added a Practices and Jar Manifest Headers section to the
JBossProductVersioning page to discuss issues such as how nightly builds
could be versioned. The headers section still needs to be completed.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf
The problem is the source of the cause not providing a stable api for
the exception, not the inclusion of the cause itself. The solution is to
fix the antlr exceptions to specify the serialVersionUID to avoid
trivial changes showing up as version incompatibilities.
You can always work around this
View results here -> http://cruisecontrol.jboss.com/cc/buildresults/jboss-cache-testsuite?log=log20060207130330
TESTS FAILEDAnt Error Message: /services/cruisecontrol/work/scripts/build-JBossCache.xml:96: The following error occurred while executing this line: /services/cruisecontrol/work/scripts/
On Tue, 07 Feb 2006 19:24:38 +0100, Scott M Stark <[EMAIL PROTECTED]>
wrote:
I'm a little concerned that this will lead to unnecessary coupling of
client and server versions of antlr then. How often does an antlr
exception as a cause show up in practise as an exception seen by an
external clie
I'm a little concerned that this will lead to unnecessary coupling of
client and server versions of antlr then. How often does an antlr
exception as a cause show up in practise as an exception seen by an
external client?
> -Original Message-
> From: Max Andersen
> Sent: Monday, February 0
Any place the version is actually used. This is the manifest headers
(these should also be spelled out and standardized including the osgi
conventions for projects that need to comply with these headers), the
repository component-info.xml, and the project build files. Really only
the project build
It cannot be resolved as a version in between a Beta and GA release
using the osgi bundle version comparision as discussed in this thread.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=75175
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Beha
Any reason we can't keep the RC instead of switching to CR? They mean
the same and we've been using RC for, what, years?
Scott M Stark wrote:
I have not seen any outcry over the version convention thread so I have
updated the product version page to summarize the conclusion reached.
Getting pr
I have not seen any outcry over the version convention thread so I have
updated the product version page to summarize the conclusion reached.
Getting projects aligned to this convention is something all leads need
to work on.
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossProductVersioning
xx
19 matches
Mail list logo
