[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [eclipselink-dev] Maven Updates
|
Following up on adding the api jar to java.net...The jar has been
published in java.net maven repo as of
yesterday.(http://download.java.net/maven/2/org/eclipse/persistence/javax.persistence/)
On 1/13/2010 12:03 PM, Tom Ware wrote:
Hi Markus,
Please feel free to enter a bug requesting that repositories be
split. It seems like a reasonable update for us to make.
I'll make a few updates to the page to indicate the various ways to
get bundles.
For the group id issue - due to the way the specification is
designed, there are implementations in the javax.persistence classes
(i.e. code that will be run, rather than just interfaces - e.g.
Persistence.class, ProviderResolverHolder.class + some Provider
resolves) The javax.persistence jar we produce is truly an
EclipseLink version of javax.persistence. I would expect that
different implementers of javax.persistence have different code in
several of the classes because of the way the spec classes are
defined. For that reason, it seems as if the eclipselink group is a
reasonable place for that bundle.
-Tom
Markus Karg wrote:
Tom and Mitesh,
thank you for the updates. Cannot answer in-thread since I was not
subscribed at the time you moved the thread to the mailing list. Sorry.
First about my original question: Tom, there still is the problem
that SNAPSHOTs and releases are in the same repo. The problem is that
this prevents people from using the version ranges feature (i. e.
automatic pulling of bug fixes inside of the range of a stable API,
e. g. 1.1.0…1.1.99), so everybody must modify his pom.xml when
EclipseLink fixed another bug. This is a real drawback, and it foils
one of Maven 2's biggest features - automatic bug fix pulling. Why
not following Maven's best practice and putting SNAPSHOTs and
releases into different repos? Maybe you didn't know, but SNAPSHOTs
are not just used when -SNAPSHOT is explicitly given, but also when
one requests "[1.0.0, 1.1.0)", as a SNAPSHOT is *in* this range! Or
in other words: YOU REPO IS JUST WRONG. ;-)
Unfortunately what your nice page overhaul does not tell, and what I
actually wanted to know, is: How to tell Maven that I want to get the
*latest RI* of JPA 2.0 always (not just an outdated or buggy 2.0.0,
but the actually last bug fixed JPA 2.0)? I mean, I don't care
whether this is named 2.0, 2.1 or even 3.0. So, can I rely on the
fact that a JPA 2.0 implementation will always be named "-2.x"? Is
that guaranteed by your project management? This is much more
interesting than a long list of what version so far had been released
(who cares about outdated JPA 2.0 pre-releases?). Sorry for being so
clear, but I just want to get the answer I *really* need.
For the bundes: It is unclear what core and bundles mean. See, I want
to get JPA 2.0 API + RI. Nothing else. Where on that page do I find
the information whether I need "eclipselink", "…core", "…jpa",
"javax.persistence"… (the latter is named as "EclipseLink version" --
well, I don't want to get any versions, I want just the API as I dont
want to RUN that stuff, I just want to COMPILE AGAINST it…)? See,
what I am seeking is a clear answer like this:
= JPA 2.0 =
JPA 2.0 API: <artifactId>which one of the listed ones?</artifactId>
<version >[2.0.0, last jpa 2.0 bugfix possible in your schema]</version>
JPA 2.0 RI: <artifactId>which one of the listed ones?</artifactId>
<version>[2.0.0, last jpa 2.0 bugfix possible in your schema]</version>
It would be really, really great to get exactly that in exactly that
clarity! :-)
For the "there is always an implementation in JPA" issue: Well, this
is rather bad, actually. I mean, I just want to get the API to
compile against it. I understand that it must containt some code. But
as it is just the API, it must never be executed. In fact, I will
never run it (we run on a GlassFish only, but we develop without
using JUnit Mockups). So is there a need to keep THE API jar in the
eclipselink groupId? I mean, hey, this is the one and only official
and original JPA API jar. Shouldn't it be found in a javax groupdId
instead? I mean, there is only one Java, so why splitting Java EE's
namespace into pieces? This makes it a lot more complex for
programmers to use the APIs, without selecting a (here: not even
used) implementation… Really, really unneccesary
overcomplexification! :-(
Regards
Markus
------------------------------------------------------------------------
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev