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
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
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 -
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
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]
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
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
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
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 06,
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
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
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 Of
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
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
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
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
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
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
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:
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
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
21 matches
Mail list logo
