Hibernate 3.5.0-Final release

Looks like it didn't get to JBoss Maven repo yet: http://repository.jboss.org/maven2/org/hibernate/hibernate-core/3.5.0-Final/ shows empty directory. I hope it will be available soon?

BTW: why the change of naming convention? why Final, not GA?

Grzegorz wrote on Mar 31, 2010 22:30:
Looks like it didn't get to JBoss Maven repo yet

I have it committed to the SVN that backs the repo. There is a synch process that occurs. It may just take a few minutes.

Grzegorz wrote on Mar 31, 2010 22:30:
BTW: why the change of naming convention? why Final, not GA?

Its the JBoss convention du jour: http://community.jboss.org/docs/DOC-10725

Far better read only / immutable support. See the new chapter added to the core reference manual dedicated to the subject.

I don't find the documentation about support for immutable objects, where is it?

Felipe, Hibernate Core documentation on website still says 3.3.2.GA; that's why. Anyone going to publish the 3.5 documentation?

I've just uploaded the 3.5 docs (except for core javadoc). you might need to refresh in your browser.

I seem to get the following error, for the HTML documentation as well as for the PDF

You don't have permission to access /hibernate/stable/core/reference/en/html/ on this server.

Nice work.

One suggestion: the Hibernate core reference manual gives a 403 forbidden page My Link

Geoffrey De Smet wrote on Apr 01, 2010 11:42:
Nice work. One suggestion: the Hibernate core reference manual gives a 403 forbidden page My Link

It works now. Thanks for finding it. Tip: do not create symlinks from a non existing file :)

Its the JBoss convention du jour: http://community.jboss.org/docs/DOC-10725

Damned, Emmanuel seems to have a strong French influence on you! ;)

Congrats for the major release, that was a big piece!

Cheers,

sacha

Felipe Cypriano wrote on Mar 31, 2010 23:32:
Far better read only / immutable support. See the new chapter added to the core reference manual dedicated to the subject. I don't find the documentation about support for immutable objects, where is it?

http://docs.jboss.org/hibernate/core/3.5/reference/en-US/html_single/#readonly

I am still not seeing the artifacts for 3.5.0-Final, just the .pom files. As a matter of fact, there are no artifacts for any version above 3.2.0-ga. Any ideas?

Igor wrote on Apr 01, 2010 17:20:
I am still not seeing the artifacts for 3.5.0-Final, just the .pom files. As a matter of fact, there are no artifacts for any version above 3.2.0-ga. Any ideas?

Hmm, you mean like http://repository.jboss.org/maven2/org/hibernate/hibernate-core/3.5.0-Final/hibernate-core-3.5.0-Final.jar ??

How could I get the javadoc for offline use.

ZhangJianPing wrote on Apr 02, 2010 01:58:
How could I get the javadoc for offline use.

Note quite sure yet. Lets wait and see what JBoss.org says in regards to the numerous outstanding questions wrt the doc server. In the interim you could utilize wget or similar.

Hello great news! But I saw a mistake in the annotation guide,

in configuration it is

Copy hibernate-annotations.jar, lib/hibernate-comons-annotations.jar and lib/hibernate-jpa-2.0-api.jar from the distribution to your classpath as well.

but these jars are no where to found (except hibernate-jpa-2.0-api-1.0.0.Final.jar and not in lib but jpa folder).

And I realised the missing jar files (hibernate-annotations.jar, lib/hibernate-comons-annotations.jar) must be bundled inside the hibernate core jar (hibernate3.jar) itself right?

Please can you tell me if I am wrong? If I am right can the reference be updated? I think the author forgot to update this part.

Cheers, IRNBRU

irnbru wrote on Apr 04, 2010 14:08:
Please can you tell me if I am wrong? If I am right can the reference be updated? I think the author forgot to update this part. Cheers, IRNBRU

http://opensource.atlassian.com/projects/hibernate/browse/HHH-5069

Here is the link : http://sourceforge.net/projects/hibernate

I just download it, and it seams that Annotations is incomplete!

I cannot find @ElementCOllection annotation or @MapKeyEnumerated. It doesn't correspond with the documentation.

Re: problems with Annotations: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4955

The announcement claims that core, annotations and entitymanager have been unified, yet they still exist as separate artifacts in Maven repo, and there doesn't seem to be any unified JARs available anywhere but in the release bundles. Am I missing something, or the Maven repo simply got low priority during the release?

Alex Savitsky wrote on Apr 19, 2010 21:58:
The announcement claims that core, annotations and entitymanager have been unified, yet they still exist as separate artifacts in Maven repo, and there doesn't seem to be any unified JARs available anywhere but in the release bundles. Am I missing something, or the Maven repo simply got low priority during the release?

One of these days I will be able to not have to direct people here: http://in.relation.to/Bloggers/ClarificationAboutAnnotationsAndEntityManager

Having trouble figuring out this blog/wiki software to do partial quotes of your comment and there is so much in the comment that i don't think my simply commenting to the whole is beneficial. So I'll respond to the parts...

JVerstry wrote on Aug 04, 2010 17:25:
If by the above you suggest that one should use a hibernate-core-xxx.jar instead of a hibernate-xxx.jar, then I can tell:

The question of hibernate-core-xxx.jar instead of a hibernate-xxx.jar is completely different from and unrelated to the rest of the things you go on to discuss. hibernate-xxx.jar simply does not exist. Yes there is a org.hibernate:hibernate module (maven terms) but it is only the aggregator (hibernate is a multi-module project). Its packaging is pom and so it produces no jar. Been that way ever since Hibernate has been using Maven...

JVerstry wrote on Aug 04, 2010 17:25:
a) Using -Final instead of -GA is not a good idea, because it is not standard naming (see http://continuum.apache.org/development/release.html). IDE's such as NetBeans don't get that 'Final' means 'GA' and don't propose hibernate-core version 3.5.1-Final in the list of available version from the maven repository.

Have you stopped to consider this is a NetBeans limitation? Using Final is the convention of the JBoss community. Many many many projects use it. Personally I find the whole concept of needing a qualifier for GA/Final/your-term-of-choice releases ludicrous. But thats my opinion, which is outweighed by buying into a convention in this case.

JVerstry wrote on Aug 04, 2010 17:25:
b) I saw your http://in.relation.to/Bloggers/ClarificationAboutAnnotationsAndEntityManager note. I believe it would be great if the documentation available at http://docs.jboss.org/hibernate/stable/annotations/reference/en/html_single/ in section 1.1 were updated too, because it is confusing:

• Download and unpack the Hibernate Core distribution from the Hibernate website. Hibernate 3.5 and onward contains Hibernate Annotations.
• Alternatively add the following dependency in your dependency manager (like Maven or Ivy).

There is no such thing as 'alternatively' for maven users, these dependencies MUST be added.

First, I'll agree that the 3.5 docs are currently confusing in regards to annotations and setup.

As for the alternatively, not everyone uses Maven. The second point is a counter-point to the first. The first point is however (unfortunately) poorly worded. The focus of the first point is the release bundles (SourceForge downloads). Essentially it is trying to say you can either (a) get everything from the distribution bundles (3.5 onward it would be the same bundle) or (b) use a dependency manager (ivy and maven are 2 possible choices). In fact in 3.6 we totally consumed hibernate-annotations into hibernate-core, source, docs and all.

JVerstry wrote on Aug 04, 2010 17:25:
Moreover, there are currently several issues in Hibernate's maven repositories. I have summarized this in a post following the Sonatype repository announcement (see https://forum.hibernate.org/viewtopic.php?f=1&t=1005998).

Yep, I responded there earlier today.

JVerstry wrote on Aug 04, 2010 17:25:
I hope this can be solved soon, because right now, only hibernate-3.2.7.ga and declaring subsequent dependencies such as hibernate-annotations-3.4.0.GA work smoothly from a maven process perspective.

People use this stuff smoothly every day. I suspect what you are missing is a clear picture of the function of the modules/artifacts. Simply declaring a dependency on hibernate-core is not going to transitively suck in hibernate-annotations (in 3.5) nor hibernate-entitymanager (in 3.5 nor 3.6) not any other modules. Thats not the intent of modules and that expectation is backwards. hibernate-core does not depend on hibernate-annotations; its quite the opposite. If you want to use hibernate with annotations in 3.5 you have to declare both hibernate-core and hibernate-annotations in your pom (technically you could just specify hibernate-annotations since that would transitively suck in hibernate-core, but I'd have to suspect that you actually use hibernate-core in your classes and your not declaring a direct dependency on hibernate-core is considered bad practice even by the Maven community). That is the intended way it works. Its the way that makes sense when you actually sit down and think about it. And it is not going to change.

I guess we are both stating our point of views here.

I suspect what you are missing is a clear picture of the function of the modules/artifacts.

I am a newbie to Hibernate. I did a fair amount of research to get such a clear picture and could not find such documentation on JBoss's site or on forums and blogs. Information is often contradictory, conflicting, if not incomplete. I think the frustration is very legitimate here.

(...) but I'd have to suspect that you actually use hibernate-core in your classes and your not declaring a direct dependency on hibernate-core is considered bad practice even by the Maven community. That is the intended way it works. Its the way that makes sense when you actually sit down and think about it.

I think you are misunderstanding the Maven philosophy in general (and you can check this on Sonatype's guide available online).

a) The whole purpose of delivering maven artifacts with corresponding pom.xml is to free the developers from having to think about which dependency to include or not. If an artifact depends on other artifacts, that should be declared in its pom.xml and maven will automatically fetch dependencies, even transitively if necessary.

Hence, if one needs to use annotations, one should only have to declare that dependency in its project pom.xml. If annotations depend on core, then that should be declared in annotation's pom.xml, so that maven can fetch core if annotation is used. It would not be considered bad practice at all by the maven community, in fact quite the opposite.

b) Maven is a system that works by defaults. If the user does not declare or configure something specific, it is assumed that the user means using the default. If you consider the wording and content of the available Hibernate maven documentation, then there is no way one can properly understand your maven implementation and transition on annotations modules etc..

The tone of your answer to Igor and your exasperation at Alex's question is only the product of your own lacking. It is totally undue.

Your link (http://in.relation.to/Bloggers/ClarificationAboutAnnotationsAndEntityManager) says that you aim at getting rid of a compatibility matrix and hope that it clarifies. You mention that Hibernate is still modularized, because the intention 'is to isolate the dependences for each module'. You also mention that what is delivered on SourceForge is a single jar.

It looks to me like the way you have re-organized this project is over-federated and cumbersome. Something that looks too much like ant and not using maven features well enough.

Isolating dependences to each module is equivalent to saying 'life on their own' in the development process. In that case, there is no need for some kind of federation. Each module just needs to declare its dependencies to other modules (by specifying a version if necessary). They can each carry on living as a project on their own, independently of the life cycle of each other.

In order to create a big fat .jar containing everything, one can use the assembly plugin in a separate project having dependencies to each sub-project (for example). If targeting the JDK version for compilation is necessary, the maven-compiler-plugin is available for configuration. That is the proper way to get rid of the compatibility matrix with maven. There is no need for parenting à la Ant; maven will do its job perfectly well if dependencies across modules are well defined.

About naming conventions, JBoss has the right to use its own convention for sure, but I still believe the choices it made are alienating.

To summarize it, I think Hibernate needs to come clean with its maven act by providing proper documentation:

i) Describing all produced module/artifacts for each released version.

ii) Describing deviations from standard use of Maven.

iii) Explaining the pom.xml organization (and eventual parenting).

iv) Specifying which module/artifact should be included in user's projects for each release of Hibernate, especially over the transition.

JVerstry

JVerstry wrote on Aug 05, 2010 07:49:
I am a newbie to Hibernate. I did a fair amount of research to get such a clear picture and could not find such documentation on JBoss's site or on forums and blogs. Information is often contradictory, conflicting, if not incomplete. I think the frustration is very legitimate here.

As I already stated, I agree that this could be documented better. Since you searched our blogs, I am sure you ran across http://in.relation.to/9384.lace

JVerstry wrote on Aug 05, 2010 07:49:
(...) but I'd have to suspect that you actually use hibernate-core in your classes and your not declaring a direct dependency on hibernate-core is considered bad practice even by the Maven community. That is the intended way it works. Its the way that makes sense when you actually sit down and think about it. I think you are misunderstanding the Maven philosophy in general (and you can check this on Sonatype's guide available online). a) The whole purpose of delivering maven artifacts with corresponding pom.xml is to free the developers from having to think about which dependency to include or not. If an artifact depends on other artifacts, that should be declared in its pom.xml and maven will automatically fetch dependencies, even transitively if necessary. Hence, if one needs to use annotations, one should only have to declare that dependency in its project pom.xml. If annotations depend on core, then that should be declared in annotation's pom.xml, so that maven can fetch core if annotation is used. It would not be considered bad practice at all by the maven community, in fact quite the opposite.

BS. Sorry, no other way to say that. This statement is utter BS.

First, the pom for hibernate-annotations, in fact, does declare a dependency on hibernate-core. And it does so in such a way that when your project declares a dependency on hibernate-annotations, hibernate-core is automatically a dependency as well. This is what is called transitivity since you want to discuss the philosophy of maven, at least gets its terms right.

Second, this is not at all the intent of Maven. Dependencies that your code depends on to compile should always be explicitly declared. Hell Maven even provides a plugin mojo that will tell you this. Transitivity is intended for runtime dependencies; that is it is meant to pull along dependencies that your dependencies need in order to run properly.

JVerstry wrote on Aug 05, 2010 07:49:
b) Maven is a system that works by defaults. If the user does not declare or configure something specific, it is assumed that the user means using the default. If you consider the wording and content of the available Hibernate maven documentation, then there is no way one can properly understand your maven implementation and transition on annotations modules etc..

Is there even a point here? Defaults? Huh?

JVerstry wrote on Aug 05, 2010 07:49:
Isolating dependences to each module is equivalent to saying 'life on their own' in the development process. In that case, there is no need for some kind of federation. Each module just needs to declare its dependencies to other modules (by specifying a version if necessary). They can each carry on living as a project on their own, independently of the life cycle of each other.

Yep, Hibernate should pull in every possible dependency in big ball of wax because someone simply cannot fathom that the hibernate-c3p0 module represents an integration between Hibernate and c3p0; that the hibernate-proxool module represents an integration between Hibernate and Proxool; and lord knows everyone need both c3p0 and proxool (both JDBC connection pools) as part of their project dependency tree at all times simply because they use Hibernate, even though they may not use either c3p0 nor proxool. I'm sorry, but are you even listening to yourself?

JVerstry wrote on Aug 05, 2010 07:49:
In order to create a big fat .jar containing everything, one can use the assembly plugin in a separate project having dependencies to each sub-project (for example). If targeting the JDK version for compilation is necessary, the maven-compiler-plugin is available for configuration. That is the proper way to get rid of the compatibility matrix with maven. There is no need for parenting à la Ant; maven will do its job perfectly well if dependencies across modules are well defined.

First, as I already stated above the inter-module dependencies are well defined. As for the rest of this, sorry, I really have no idea what your point is supposed to be here. You want Hibernate to produce a big fat .jar? The jar is trivial (in fact we do it already for the release bundle). The difficulty is the pom; since you are a maven rah-rah guy you should know the most uber of maven uber-rules: one module means one artifact

JVerstry wrote on Aug 05, 2010 07:49:
ii) Describing deviations from standard use of Maven.

Um, what is our deviation here exactly?

I don't know what entitles you to use strong language.

As I already stated, I agree that this could be documented better. Since you searched our blogs, I am sure you ran across http://in.relation.to/9384.lace

As a matter of fact, I did not come across that link, because I was googling for 3.5 and 3.6 documentation. There is not even a link on Hibernate's front page or menus, or documentation. Yet, this is critical information, not only for Maven users.

Um, what is our deviation here exactly?

There are two deviations. One is how you think people should interpret your implementation of Maven.

Considering that there is no clear or complete information about Hibernate's implementation of Maven, the Maven philosophy says no info equals default behavior. This is how the situation should be interpreted by users. And this is precisely what led them to ask questions following your posts, because it does not make sense.

You mentioned 'Hibernate 3.5.0-Final release', 'Integration of hibernate-annotations, hibernate-entitymanager and hibernate-envers into the core project' and 'The artifacts have all been published to the JBoss Maven repository' without explaining how you have implemented maven. It is a recipe for confusion for any maven user.

I am sorry, but you are responsible for your communication and how it will be understood by maven users, that is, according to maven well established principles. I guess you would only expect the same about people willing to use Hibernate.

Now, by defining a '-final' extension to specify the final release of a release version, you deviate from standard expectations too. Read: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution. It specifically says: 'the qualifier section is optional (and is SNAPSHOT, alpha-1, alpha-2)'. This does not include '-final'.

Hence, your hypothesis that NetBeans would contain a bug is false.

Moreover, if a user implements a maven project and systematically wants to use the latest final version of an Hibernate module, not using standard version naming is not going to help any system pick that latest version from any repository. Just test it yourself if you are not convinced.

JBossProjectVersioning mentions that it follows 'OSGi conventions for release names'. My question is, why would JBoss not follow Maven standards when it uses Maven?

The bottom line on that '-final' issue is that easiest solution, which would be compatible both for maven and OSGi, would be to remove the '-final' extension on any final release.

I am just trying to keep you honest here.

I sincerely hope the Hibernate community will update its mavenization documentation soon and make it easily accessible to all Hibernate users.

You asked what gives me the right to use strong language. And then you follow up with this. This is a perfect example. You make your arguments and use these facts to back them up, yet your facts are consistently incorrect. Its frustrating to have to sit here and do your homework for you because you find it easier to turn your belief into an statement of fact.

JVerstry wrote on Aug 05, 2010 13:54:
Moreover, if a user implements a maven project and systematically wants to use the latest final version of an Hibernate module, not using standard version naming is not going to help any system pick that latest version from any repository. Just test it yourself if you are not convinced.

'standard version naming'... huh? You even continue on to point out that Maven does not care about a qualifier. So what standard are you talking about? OSGI? Well lets look at OSGI and the -Final point...

JVerstry wrote on Aug 05, 2010 13:54:
The bottom line on that '-final' issue is that easiest solution, which would be compatible both for maven and OSGi, would be to remove the '-final' extension on any final release.

See this is what I am talking about. A conclusion based on a statement of fact that is completely factually incorrect. In OSGI, artifact names are sorted alphabetically on any qualifier if the other parts are equal. So lets take your example and say I have 1.1.1.Beta1, 1.1.1 and 1.1.1.SP1. What does OSGI say is the ordering here? I can tell you its not what you seem to think it will be.

JVerstry wrote on Aug 05, 2010 13:54:
Now, by defining a '-final' extension to specify the final release of a release version, you deviate from standard expectations too. Read: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution. It specifically says: 'the qualifier section is optional (and is SNAPSHOT, alpha-1, alpha-2)'. This does not include '-final'.

Ohhhhhh. So only qualifiers listed in a one-off page from a project that you state does not care about qualifiers can be used as valid qualifiers. Ok. It also does not list 'beta'; is 'beta' not valid?

JVerstry wrote on Aug 05, 2010 13:54:
JBossProjectVersioning mentions that it follows 'OSGi conventions for release names'. My question is, why would JBoss not follow Maven standards when it uses Maven?

Why would we care what you use to build? Just because Hibernate is built with Maven (for now) only projects using Maven should be able to use it? Really?!?

JVerstry wrote on Aug 05, 2010 13:54:
There are two deviations. One is how you think people should interpret your implementation of Maven.

Oh! I forgot we reimplemented Maven. Yep we should document that. For sure.

JVerstry wrote on Aug 05, 2010 13:54:
And this is precisely what led them to ask questions following your posts, because it does not make sense.

See I'd argue that they did not know about the JBoss Maven repository (or the change to it a few months ago) is what led them to ask those questions... But that or they are confused over how we reimplemented Maven. I can see how either would be confusing

For maven users willing to use annotations, here is a sample pom.xml that works with the latest 3.5 release:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>my.test</groupId>
  <artifactId>HiberTest</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>

  <name>HiberTest</name>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <configuration>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-annotations</artifactId>
            <version>3.5.4-Final</version>
            <type>jar</type>
        </dependency>
      <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-core</artifactId>
            <version>3.5.4-Final</version>
      </dependency>
  </dependencies>

  <repositories>
      <repository>
          <url>https://repository.jboss.org/nexus/content/groups/public/</url>
          <id>Hibernate Repository</id>
      </repository>
  </repositories>

</project>

Contrary to what you would expect from any maven module/artifact, including hibernate-annotations in your pom.xml only is not enough to be able to add annotations in your classes. One must explicitly include hibernate-core to be able to import the @Entity annotation in this simple Java class (for example):

package my.test.hibertest;

import java.io.Serializable;
import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public class Users implements Serializable {

    @Id
    private long ID;
    private String Name = "";

    public long getID() { return ID; }
    public void setID(long inID) { this.ID = inID; }

    public String getName() { return Name; }
    public void setName(String inName) { this.Name = inName; }

}

This is documented nowhere and very counter intuitive.

@Steve:

In OSGI, artifact names are sorted alphabetically on any qualifier if the other parts are equal. So lets take your example and say I have 1.1.1.Beta1, 1.1.1 and 1.1.1.SP1. What does OSGI say is the ordering here? I can tell you its not what you seem to think it will be.

Are you saying that because artifact naming might be an issue with OSGi, it is ok to break maven conventions? Like suddenly changing GA for -final? If you need to create OSGi bundles out of Hibernate code, then you can do it in Maven without breaking conventions.

For example, create a project importing all the required dependencies. Add in your OSGi specific java code (services, bundle activators et tutti quanti...). Give the final artifact the name you need under the project's coordinates with:

<finalName>MyArtifactName-final</finalName>

Then configure maven-bundle-plugin in your pom.xml (assuming you are using this plugin, for example).

If you have some concerns about the size of the generated .jar - because you need to include many dependencies - you could trim it with the proguard-maven-plugin using proper configuration. It would come out slick.

That way, you would not need to impose your OSGi conventions on maven unnecessarily. You wouldn't break maven naming conventions which were correct until hibernate-core-3.3.2.GA or hibernate-3.2.7.ga (for example).

Just last one question: what would happen to the OSGi sorting if you used -ga instead of -final?

The 'Current Release Version Conventions (including qualifiers) - Post January 8, 2010' section on http://community.jboss.org/wiki/JBossProjectVersioning mentions that you use:

major.minor.micro.Alpha[n]
major.minor.micro.Beta[n]
major.minor.micro.CR[n]
major.minor.micro.Final

and

major.minor.micro.TIMESTAMP-Mn
major.minor.micro.CR[n]
major.minor.micro.Final

Does using

major.minor.micro.GA

would really break the order? Have you tested it? G would come out before A B or C? Or would it come alphabetically for OSGi as you have mentioned it yourself?

I hope you get my point this time (and all others too) !!!

Dude this is really my last response to you.

Again you illustrate just how little you know. javax.persistence.Entity is in no way associated with hibernate-core. That is a JPA annotation. So not only is it not even part of hibernate-core, it is not even part of any dependency of hibernate-core. It is part of org.hibernate.javax.persistence:hibernate-jpa-2.0-api (the JPA api) which is a direct dependency of hibernate-annotations.

Considering you know so much about Maven to be able to speak to their intent on numerous issues perhaps you could actually take a look at the poms in question and see what it is they do rather than pontificate on what you think they do? https://repository.jboss.org/nexus/content/groups/public/org/hibernate/hibernate-annotations/3.5.4-Final/hibernate-annotations-3.5.4-Final.pom. Hmm, odd. I see a dependency on org.hibernate:hibernate-core:3.5.4-Final there. I see a dependency on org.hibernate.javax.persistence:hibernate-jpa-2.0-api there. So perhaps you can please stop with this nonsense? But of course you wont.

( why does most of your discussion here remind me so much of stories of the ancient greeks before socrates who would pontificate on the number of teeth in a persons mouth based on mathematical formulas or philosophical proofs rather than actually just counting them? )

Are you saying that because artifact naming might be an issue with OSGi, it is ok to break maven conventions? Like suddenly changing GA for -final? If you need to create OSGi bundles out of Hibernate code, then you can do it in Maven without breaking conventions.

You kill me. You really do. You go on and on about how Maven does not care about qualifiers. Then you go on and on about how Hibernate is using qualifiers that are not in the Maven qualifier convention. Just admit it; you are confused (about Maven and OSGI, not just Hibernate). Then we can move on. Unfortunately here you cannot simply edit your comments like on that forum post to make your sadly inaccurate statements go away.

I really hope you'll see the light this time; not holding my breath mind you, but really hoping.

Steve, I did see the light indeed...

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>

    <groupId>my.conviction.is</groupId>
    <artifactId>GoingForSomethingThatWorks</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
            <dependency>
                <groupId>org.apache.openjpa</groupId>
                <artifactId>openjpa-all</artifactId>
                <version>2.0.0</version>
            </dependency>
    </dependencies>

    <build>
      <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                    <encoding>UTF-8</encoding>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

All my code compiled at the 2nd attempt, and only because I forgot to remove some Hibernate imports.

All became so bright after reading this: http://openjpa.apache.org/quick-start.html and that: http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/main.html.

And yes, I will admit, I sincerely regret that posts cannot be edited here...

It has been a pleasure discussing with you and I wish you well with your endeavors !!!

Cool, I'm glad you found something that worked for you. Enjoy.