| [eclipselink-dev] Maven Updates |
|
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 |