Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Maven Updates

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.


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! :-(




eclipselink-dev mailing list

Back to the top