[hibernate-dev] Hibernate EntityManager and Annotations bug fix release
Max Bowsher
maxb at f2s.com
Tue Mar 18 15:00:18 EDT 2008
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20080318/3062375b/attachment.bin
More information about the hibernate-dev
mailing list