Hi all,
Emmanuel and I are wondering which prefix should be used for log messages
created by the parser component ("project code" in JBoss logging
nomenclature).
I can see the following possibilities:
1) Use HHH-... as in ORM, using a reserved interval of ids
2) Use a new prefix such as HQLPARSE
My vote goes to #2 as long as we use a shorter code. HQL-1 doesn't
looks too bad.
In case we incorporate this in ORM I'd change them to HHH- but we can
discuss that if/when that happens.
On 27 August 2013 10:33, Gunnar Morling wrote:
> Hi all,
>
> Emmanuel and I are wondering which prefix sh
My initial reaction was to go for 1. but I forgot that the parser is now
reused by ISPN. I'd go for 2. then.
Emmanuel
On Tue 2013-08-27 11:33, Gunnar Morling wrote:
> Hi all,
>
> Emmanuel and I are wondering which prefix should be used for log messages
> created by the parser component ("project
> My vote goes to #2 as long as we use a shorter code. HQL-1 doesn't
looks too bad.
> In case we incorporate this in ORM I'd change them to HHH- but we can
discuss that if/when that happens.
+1
HQLP as a code perhaps.
On Tue, Aug 27, 2013 at 12:20 PM, Sanne Grinovero wrote:
> My vote goes
I prefer HHH or HQL as well.
On 08/27/2013 06:20 AM, Sanne Grinovero wrote:
> My vote goes to #2 as long as we use a shorter code. HQL-1 doesn't
> looks too bad.
>
> In case we incorporate this in ORM I'd change them to HHH- but we can
> discuss that if/when that happens.
>
> On 27 August 201
Cool, thanks everyone for your feedback.
Let's go for HQL in all the parser modules then. I'll register that prefix
at https://community.jboss.org/wiki/HowToLogInJBossProjects.
--Gunnar
2013/8/27 Steve Ebersole
> I prefer HHH or HQL as well.
>
>
> On 08/27/2013 06:20 AM, Sanne Grinovero wrot
My "concern" with using HQL as the key is when we move this to be a
central piece of ORM. ORM already is registered to use HHH for its
KEY. The "concern" is where that distinction lies.
Its more a concern with the JBoss Logging idea that everything is
distinct little units that can easily fit
I am contemplating duplicating[1] our existing JPA API jars to use a
better GAV naming scheme, specifically the GAV naming scheme we plan on
adopting for any new JPA specs. We have used completely different
naming scheme for 1.0 then we did for 2.0 and 2.1. And even for 2.0 and
2.1 we used th
+1 to have a suffix not related tot he draft. Like you I have pushed
spec jars that did not reflect eh state of a draft necessarily.
BTW, why retrofit that scheme? Why not just apply it for 2.1?
Emmanuel
On Tue 2013-08-27 9:57, Steve Ebersole wrote:
> I am contemplating duplicating[1] our exist
On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard wrote:
> +1 to have a suffix not related tot he draft. Like you I have pushed
> spec jars that did not reflect eh state of a draft necessarily.
>
> BTW, why retrofit that scheme? Why not just apply it for 2.1?
Well applying it for 2.1 is in fact
On Tue 2013-08-27 10:22, Steve Ebersole wrote:
> On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard wrote:
> >+1 to have a suffix not related tot he draft. Like you I have pushed
> >spec jars that did not reflect eh state of a draft necessarily.
> >
> >BTW, why retrofit that scheme? Why not just
Sounds reasonable to me.
One question only: It is guaranteed that the JPA spec itself never will do
a micro update, right? I.e. the spec would never be updated from say 2.2 to
2.2.1 (but to 2.3 in this case)?
2013/8/27 Steve Ebersole
> I am contemplating duplicating[1] our existing JPA API jar
Well thats the beauty of duplicating (in theory). Nothing really to
fight. Now if we were doing relocation, yes I'd agree with you :)
On 08/27/2013 10:28 AM, Emmanuel Bernard wrote:
> On Tue 2013-08-27 10:22, Steve Ebersole wrote:
>> On Tue 27 Aug 2013 10:16:38 AM CDT, Emmanuel Bernard wrote:
I don't ever foresee that happening. I don't know that it is
"guaranteed" anywhere though.
On 08/27/2013 10:29 AM, Gunnar Morling wrote:
> Sounds reasonable to me.
>
> One question only: It is guaranteed that the JPA spec itself never
> will do a micro update, right? I.e. the spec would never b
Technically the spec could go in what is called maintenance mode. In
which case the spec lead could use micro or some prefix like M1.
But we don't know if that will happen for JPA nor which one will be
chosen.
Emmanuel
On Tue 2013-08-27 10:55, Steve Ebersole wrote:
> I don't ever foresee that hap
I see.
The reason I'm asking is that there theoretically could be a collision
between the version of such a maintenance release of the spec and a
previous bug fix release of our spec API JAR which e.g. would then both
have the version "2.2.1".
Not sure whether one should be prepared for such a ca
One option is a special qualifier. 2.2.1.Final (our bugfix) versus
2.2.1.Maintence (spec maintenance). Could still lead to "bad sorting",
but does avoid collisions.
Also note that since 1.0 we have never needed a bugfix release. For
what its worth...
On Tue 27 Aug 2013 11:24:52 AM CDT, Gun
17 matches
Mail list logo
