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
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
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 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
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:
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
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
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
+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
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
I do not agree with needing to see this in the artifact name. I can see
putting it in the metadata (pom, manifest, etc) in addition to Jira.
'draft' does in deed fit into the chronology scheme defined by JBoss.
Except that 'draft' is not defined as a valid value.
Here is another thing to cons
On 26 July 2013 18:51, Hardy Ferentschik wrote:
>
> On 26 Jan 2013, at 7:26 PM, Steve Ebersole wrote:
>
>> I just released the "Final" JPA API jar. It is still using the old
>> naming scheme in terms of repo artifacts; so this one is:
>>
>> groupId : org.hibernate.javax.persistence
>> artifactId
Well the problem comes up in versions like '1.0.0.Draft-7plus', which
was Draft-7 + some stuff we had just discussed in the EG. Or what
about cases where we are combining work from a few drafts? All in all,
its not great.
What I was thinking instead is to use Alpha/Beta/CR and in the Jira
no
On 26 Jan 2013, at 7:26 PM, Steve Ebersole wrote:
> I just released the "Final" JPA API jar. It is still using the old
> naming scheme in terms of repo artifacts; so this one is:
>
> groupId : org.hibernate.javax.persistence
> artifactId : hibernate-jpa-2.1-api
> version : 1.0.0.Final
nice
I just released the "Final" JPA API jar. It is still using the old
naming scheme in terms of repo artifacts; so this one is:
groupId : org.hibernate.javax.persistence
artifactId : hibernate-jpa-2.1-api
version : 1.0.0.Final
I think moving forward we will move to a slightly different scheme. The
ahahah, touché.
On 14 déc. 2009, at 18:39, Steve Ebersole wrote:
> Well we can also do what you suggest and you can be the one fielding bug
> reports about some other providers jar if you wish ;)
>
> On Mon, 2009-12-14 at 17:38 +0100, Emmanuel Bernard wrote:
>> If you guys like that. But you wil
Well we can also do what you suggest and you can be the one fielding bug
reports about some other providers jar if you wish ;)
On Mon, 2009-12-14 at 17:38 +0100, Emmanuel Bernard wrote:
> If you guys like that. But you will be the ones answering the questions:
> - why is Hibernate not standard
>
If you guys like that. But you will be the ones answering the questions:
- why is Hibernate not standard
- why do I need an hibernate specific jar to use JPA 2
:)
On 14 déc. 2009, at 16:02, Hardy Ferentschik wrote:
> I like the idea of having 'hibernate' in the actual jar name as well. When
>
I like the idea of having 'hibernate' in the actual jar name as well. When
you are
building a project the dependencies are clear. But when you just look at
an artifact
like for example a war file it helps a lot if the jar file names are a
little more descriptive.
We also have hibernate-core a
Shizzle, that explains it. I forgot to commit after releasing :(
Done now.
Same for jpamodelgen too btw. I cut a Beta-2 release in order to align
the jpa api jars
On Mon, 2009-12-14 at 11:29 -0300, Hardy Ferentschik wrote:
> In pom.xml is still uses file://${maven.repository.root} and looking
When the user simply has the jar file "in hand".
On Mon, 2009-12-14 at 15:30 +0100, Emmanuel Bernard wrote:
> Since jpa-api is not a standard name, people will search
> javax.persistence and they will see the group is prefix.
> When is the artifactID not next to the groupId? I don't remember where
Since jpa-api is not a standard name, people will search javax.persistence and
they will see the group is prefix.
When is the artifactID not next to the groupId? I don't remember where that
could happen in ivy or maven but I am no expert here.
On 14 déc. 2009, at 15:22, Steve Ebersole wrote:
>
In pom.xml is still uses file://${maven.repository.root} and looking at
the gradle build file
it also seems to use file based deployment
file://${jbossReleaseRepositoryRoot}
Webdav is used for the snapshot repository. My understanding was webdav
was not working yet for the
main repository du
I am thinking of users here. Since there will be multiple jpa api jars out
there I liked the idea of the jar name itself encoding the fact that this is
the one from hibernate. I think this is more user friendly. I hear what you
are saying though about the ability to bootstrap any/all provider
Synching from where? That project is set up for webdav deployment. Let me
check when I get to my computer...
-- Sent from my Palm Prē
st...@hibernate.org
http://hibernate.orgHardy Ferentschik wrote:
I think I found the answer to my question in another email:
"the syncing to repository.jboss
I think I found the answer to my question in another email:
"the syncing to repository.jboss.org is currently broken" :(
On Mon, 14 Dec 2009 10:54:15 -0300, Hardy Ferentschik
wrote:
> just tried to build core, but the following dependency seems to be
> missing
> :
>
> org.hibernate.javax.p
Hi
just tried to build core, but the following dependency seems to be missing
:
org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.0-CR-1
Looking at the svn log for the jpa api project it seems that Steve already
went
through the release process for this dependency.
The question
javax.persistence is owned by "Sun" as spec lead.
And more concretely, they don't publish the spec jars to maven repos under an
open source license. So our lawyers asked us to use a clean code.
Emmanuel
On 14 déc. 2009, at 11:18, Sanne Grinovero wrote:
> out of curiosity, why not drop org.hibe
out of curiosity, why not drop org.hibernate?
javax.persistence:jpa-2.0-api:1.0.0-SNAPSHOT
are there more api vendors ?
Cheers,
Sanne
2009/12/14 Emmanuel Bernard :
> I would use
> org.hibernate.javax.persistence:jpa-2.0-api:1.0.0-SNAPSHOT
>
> Because while there is code written by us, it's not s
I would use
org.hibernate.javax.persistence:jpa-2.0-api:1.0.0-SNAPSHOT
Because while there is code written by us, it's not specific to Hibernate and
can bootstrap all providers on the market.
On 11 déc. 2009, at 22:24, Steve Ebersole wrote:
> Of course that should be
> org.hibernate.javax.persi
Of course that should be
org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.0-SNAPSHOT
;)
On Fri, 2009-12-11 at 14:59 -0600, Steve Ebersole wrote:
> I think there is a consensus we need to rename our JPA api jar. The
> main concern is that we should be capturing the spec version in the
>
I think there is a consensus we need to rename our JPA api jar. The
main concern is that we should be capturing the spec version in the
artifact name but that the versioning should be its own thing since
there is in fact Hibernate specific code in the classes that we will
have need to maintain and
32 matches
Mail list logo
