Where did the jacc-1_0-fr.jar come from?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the w
What I mean is that no advertised feature of Hibernate depends upon
Proxool.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gavin
King
Sent: Tuesday, February 07, 2006 11:25 PM
To: Scott M Stark; Hibernate development
Subject: RE: [Hibernate] Is Proxol a
Yep, some users are using it.
But it is completely optional and non-default, so I'm not sure if that
license requirement would be triggered.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott
M Stark
Sent: Tuesday, February 07, 2006 11:20 PM
To: Hibern
Is the Proxool library actually used? It uses the old bsd style license
that has a silly requirement regarding all advertising acknowledgment:
http://proxool.sourceforge.net/licence.html
3. All advertising materials mentioning features or use of this
software must display the following acknow
Steve and Emmanuel are already working on this problem.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bill
Burke
Sent: Tuesday, February 07, 2006 7:15 PM
To: Hibernate development
Subject: [Hibernate] default HEM key generator
Can we have a default HEM
Can we have a default HEM key generator that will not force an insert
when using FlushMode.NEVER? Like Table or Sequence or some other
hibernate specific generator?
I've been working through some example applications for my book and am
finding that I have to modify pre-existing entity code 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
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
On Tue, 07 Feb 2006 11:35:58 +0100, Thomas Heute <[EMAIL PROTECTED]> wrote:
Tried and fixed the templates.
Thanks !
care to share if/what issues there were ? I don't see the commits ?
/max
On Monday 06 February 2006 10.09, Max Rydahl Andersen wrote:
It's done - tools head now has freema
so where do you want the name applied ?
in the eclipse plugins it make sense for the jar's since that is the part
being used to identify it + the plugin.xml/MANIFEST.MF osgi version part.
/max
This has nothing to do with the actual jar names. The version in the jar
name is a poor convention a
Yes, I plan to start using these conventions starting with 3.2.
I'm not a big fan of all minor releases needing to append '.ga' (i.e.
3.1.3.ga.jar). I really wish there was a way to define ordering amongst
"qualifiers".
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
This has nothing to do with the actual jar names. The version in the jar
name is a poor convention as it propagates the version to users
unnecessarily, and is not verifiable via a signed manifest. The jars
checked into the repository should not have any explicit version
information in the name. I d
I'm not a big fan of all minor releases needing to append '.ga' (i.e.
3.1.3.ga.jar). I really wish there was a way to define ordering amongst
"qualifiers".
AFAIK these conventions are for package names and not necessarily
library names?
it's the version branded into the application - meani
On Feb 7, 2006, at 6:51 PM, Steve Ebersole wrote:
Yes, I plan to start using these conventions starting with 3.2.
I'm not a big fan of all minor releases needing to append '.ga' (i.e.
3.1.3.ga.jar). I really wish there was a way to define ordering
amongst
"qualifiers".
AFAIK these conven
JBoss finalized some naming conventions for release packages, and
both Hibernate and NHibernate packages should follow these
conventions. The benefit of this is stability and the ability to
compare packages. As far as I can see, nothing much changes for
Hibernate except that some of the con
21 matches
Mail list logo