Re: [eclipselink-dev] Maven Updates

[Tom Ware <tom.ware@xxxxxxxxxx>]

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