Re: [hibernate-dev] Can we have an update on Maven central repository syncing?
Emmanuel Bernard wrote: Yes but central is full of broken JBoss stuff at un normalized artifact ids. So you're screwed either way. The only viable solution is to use sonar or artifactory and define the rules you wish. Personally I'm only using Hibernate itself, and no additional JBoss stuff, so I just want to be able to use Hibernate from central in the same way I do all my other dependencies. Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Envers in Hibernate
Adam Warski wrote: Hello, Though I'd have to do some adaptation changes. As I was originally targeting Envers to support JPA mappings, I assumed that it will be working in an enviroment with Hibernate Annotations/EntityManager. So I used ReflectionManager to read the @Versioned annotations. In a pure Hibernate environment, this will not work. I don't think that making Envers a module in Core means that you cannot use Hibernate Annotations/EnityManager. In fact these two projects are about to be moved back into Core. As their own (maven) modules of course. Ah, ok. Then Envers would have a dependency on the annotations module (+ users would have to use AnnotationConfiguration instead of Configuration). Makes sense, as you configure Envers through annotations (mark classes as versioned/historized), so you probably also use Annotations/EntityManager then, not pure Hibernate. Personally, I'm still a fan of plain Hibernate non-JPA config. Could the integration be done with a mind to making it possible to configure Envers via a standard Configuration in a future release? Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 3.3 and maven-eclipse-plugin
Chris Bredesen wrote: Max Bowsher wrote: Chris Bredesen wrote: and it creates them with the assumption that the project names are the same as the artifact ID. This is in fact not the case. It should be the case, and is for me. What is it for you, and have you any idea why it's different? The project dependency in cache-ehcache, for example, is created as depending on 'hibernate-core' and 'hibernate-testing'. The physical directories that these projects are located in are 'core' and 'testing' respectively. When I remove the errant project deps and open the dialog to re-add them, I'm given 'core' and 'testing' as possibilities and those work fine. No I sure don't know why they're different, hence this email :) I don't know why maven would assume a project is named after its directory and not its artifactId. I can tell you this was not a problem in the earlier days when 3.3 was trunk. I wonder what changed? The maven-eclipse-plugin has always assumed that the eclipse project name is equal to the artifactId (unless you configure it otherwise) - this isn't really an assumption, since this is the project name that it writes to the .project file. There does exist a corner case however - once you import a project into Eclipse, Eclipse no longer cares about the name value in the on-disk .project file. I suppose you had the relevant directories added to Eclipse using manually created rather than plugin-generated projects. If you delete the projects from the Eclipse workspace and re-import what the plugin generates, it should correctly name them hibernate-core and hibernate-testing. Have you built recently? Just now. I'm using Maven 2.0.8-SNAPSHOT...will try with 2.0.9. Why would you be using such an old snapshot? Or a snapshot at all? Not that I think it's the problem in this case. Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Re: Hibernate Search: approval for changes, commit conventions?
Sanne Grinovero wrote: I knew about the requirement to change the UID, but really hadn't a clue about the default behaviour: I thought it was unspecified and I really dislike that word. The default behaviour is semi-specified - specifically, it's based on a SHA1 hash of: class name and modifiers implemented interface names field names, types and modifiers (excluding 'private static' and 'private transient' fields) presence of a static initializer constructor signatures and modifiers (excluding private constructors) method names, signatures and modifiers (excluding private methods) The unspecified bit creeps in because it's not specified precisely what synthetic members and classes used to implement language features like class literals and inner classes should be named, so different compiler implementations are free to make different choices, giving different generated UIDs. Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Annotations, EntityManager and Validator compatible with Core 3.3.x
Emmanuel Bernard wrote: The Hibernate team is pleased to announce the synchronized release of: - Hibernate Annotations 3.4.0 CR1 - Hibernate EntityManager 3.4.0 CR1 - Hibernate Validator 3.1.0 CR1 - Hibernate Commons Annotations 3.1.0 CR1 As there is a mislabelled hibernate-commons-annotations 3.3.0.ga in the wild (Maven2 central and possibly other places), perhaps it might be worth arbitrarily bumping that project's version number up to 3.4.0 for new releases, in the interests of avoiding confusion? Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Annotations, EntityManager and Validator compatible with Core 3.3.x
On May 29, 2008, at 07:02, Max Bowsher wrote: As there is a mislabelled hibernate-commons-annotations 3.3.0.ga in the wild (Maven2 central and possibly other places), perhaps it might be worth arbitrarily bumping that project's version number up to 3.4.0 for new releases, in the interests of avoiding confusion? Emmanuel Bernard wrote: I added a README here (http://repository.jboss.org/maven2/org/hibernate/hibernate-commons-annotations/README.TXT) and there (http://repository.jboss.org/maven2/org/hibernate/hibernate-commons-annotations/3.3.0.ga/README.TXT) I am uncomfortable about the idea of artificially bumping versions because of maven. Let's ee how it goes I agree it's rather irksome that any project has to modify itself to cope with a 3rd party distributor mistake - but I think it would be a really bad idea to ever release a 3.3.0 version of commons-annotations, given the confusion that would be caused. With that in mind, I suppose you could go: 3.1.0, 3.2.0, 3.4.0 - but that isn't any less artificial. Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Sync maven jboss repo with central repo?
Max Rydahl Andersen wrote: Yes, I also forsee the pissing contest unfortunately. Part of the problem is that there are the same artifacts in both repositories with differing poms. Which pom is correct? I vote for the pom maintained by the dev team behind the project - anything else is an approximiation. I'm not saying our pom's are perfect, but at least they are now actively maintained. However, there's also the Release versions may never change once published rule, which applies for good reasons: * If released artifacts are changed, builds depending on them are unexpectedly non-reproducible. * If released artifacts are changed, there's no mechanism for updates to happen to local repositories caching the old versions, so some people will see the old version and some the new, indefinitely. Now, arguably, both of the above would best be solved with architectural changes to Maven, but for the moment, strict adherence to no changes to releases once deployed is the only way to maintain a modicum of sanity. What would be nice, is for automated syncing of all *new* releases to the jboss repository to be initiated, which surely can't be that controversial? (Though there may be issues where new releases depend on things in the jboss repo that are not in the central repo, but I guess they'll need addressing on a case-by-case basis anyway.) Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate EntityManager and Annotations bug fix release
Emmanuel Bernard wrote: On Mar 17, 2008, at 12:14, Max Bowsher wrote: Steve Ebersole wrote: JBoss as a whole is working with the Maven team (Jason) about setting up synching of all the projects we write to the JBoss repo (http://repository.jboss.org/maven2/) automatically. Personally, it is not worth my time, imo, to have to go through this upload rigamarole for every release since we already have upload access to the JBoss repo... Provided I'm not stepping on anyone's toes by doing so, I'd like to help out with the aforesaid rigmarole until more permanent syncing arrangments can be put into place. Sure go ahead, but I don't quite understand the need for duplication. The benefit is the ability for a project to depend on Hibernate artifacts without having to have an additional repository enabled. The problem with using an additional repository is first that Maven then checks for not-found artifacts in all enabled repositories (slow), but even more, that it doesn't have any restrictions on which repositories are entitled to supply which artifacts, and once downloaded, there's no record of what repository an artifact came from. So, for example if I happened to have the JBoss repository enabled, I might end up with a subtley different variation of an artifact than a co-worker who was using only central - opening the door to horribly hard-to-debug build reproducability issues. Granted, this is mainly the fault of Maven for having a design that isn't adequate to managing artifacts from multiple sources well, but it's a powerful motivator to stick to just central whereever possible, and to avoid repositories like JBoss which republish artifacts that are also available in central. As far as the jboss repository is concerned... It contains numerous artifacts with the same ids as things in central - I *hope* these are just duplicates, not subtley different variations. It also in a number of cases contains the same artifact under multiple different group/artifactIds. Altogether, I just don't trust it enough to list it in my POMs. Unfortunately, repo1.maven.org is equally not trustable for Hibernate today. http://repo1.maven.org/maven/org.hibernate/ is quite messy and declare wrong dependencies (I know it's the case for annotations and co). As far as I can see for HAN, HEM, HV, Commons Annotations, the past is equally screwed and messy for repo1.maven.org/maven and repository.jboss.org/maven2. I totally agree, central's record is rather less-than-stellar here. It wins out mainly because it's the mess that's most people agree on :-/ If you have improvement ideas for POMs in http://repository.jboss.org/maven2/org/hibernate/ starting from: HAN 3.3.1.GA HEM 3.3.2.GA HCA 3.3.0.GA please open a JIRA issue, I'll make it better for the next releases. My main problem is that I use ivy for my dependency management, so I can't really test the exclusive maven chain. Thanks. Those TLAs above aren't meant as JIRA keys, are they? One thing that would be great to have cleared up is the ambiguity of HCA version numbers - the same jar is published as both 3.0.0.ga and 3.3.0.ga, whilst in svn trunk, the project is calling itself 3.0.0.GA still - perhaps bump that to 3.4.0.something or 3.3.1.something? Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate EntityManager and Annotations bug fix release
Emmanuel Bernard wrote: Check it out http://in.relation.to/8711.lace What's the current situation with regards to getting this into the Maven central repository at repo1.maven.org? Also, what is the difference between javax.persistence:persistence-api:1.0 and org.hibernate:ejb3-persistence:1.0.1.GA ? It seems bad for the javax.persistence APIs to be defined under two different identifiers, since that opens the door for people unwittingly ending up with both on their classpath, and experiencing unexpected behaviour. Max. signature.asc Description: OpenPGP digital signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
