[hibernate-dev] [BVAL] POM Versions

Alaa Mohsen alaa.mohsen at egyptdc.com
Tue Mar 17 06:20:42 EDT 2009


Actually, the case was that we installed the artifacts on the local
repository of the CI virtual machine and not on our corporate repository.
The reason we did that was so that the builds for the reference
implementation won't break when the API changes. Since we used the same CI
server for other projects that depends on the Beta 4 version of the API,
when the API changed without changing the version number, the builds for our
projects failed.

Anyway, I know that the best practice for a case like ours is to either have
a vendor branch of your SVN repository, to have a mirror of it, or to have
our own version of your SVN repository and to sync the two whenever we want.
The problem with a vendor branch was that if files are renamed on you branch
(your SVN), we (EDC) might lose the version history of those files. The
problem with mirroring was that we wouldn't be able to commit to the
repository, since a mirror is read only.

Syncing was the best idea, but the problem with SVN prior to version 1.5 was
that we had to sync the whole repositor, and we can't sync parts of it, and
since the version of your SVN server is 1.4.2, we weren't able to sync the
bean validator project alone, and we had to sync the whole JBOSS repository.
Since we didn't want to do that, we accepted the easier scenario, and that
was to get the changes directly from your SVN.

Anyway, our (not so good) decision helped in finding such a problem, which
is a good thing. Currently we stopped the install goal on the CI server
until the version of the POM changes, and until we solve another unrelated
problem in our CI server.

Regards,
Alaa Nassef



On Mon, Mar 16, 2009 at 5:59 PM, Hardy Ferentschik <hibernate at ferentschik.de
> wrote:

> On Mon, 16 Mar 2009 15:27:06 +0100, Alaa Mohsen <alaa.mohsen at egyptdc.com>
> wrote:
>
>  Well, we have our own integration server which installs the new builds to
>> our local repository. I uninstalled the new artifacts with the wrong
>> version, and got the ones from the older ones and we fixed our builds.
>> What I meant by affecting the released version is for the people with cases
>> like ours, where they rely on a CI server to be able to use/test different
>> snapshots.
>>
>
> I guess the best practise is to up the version number right after a
> release. I am trying
> to do that in the reference implementation, but we should do the same for
> the spec.
>
> However, there is no guarantee that something like this happens again or
> some other temporary problem.
> Maybe instead of installing all builds from your ci server into your local
> repository you should
> consider to switch to an explicit install.
>
> Of course it is great for us that you are pretty much testing all our
> changes immediately ;-)
>
> --Hardy
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20090317/c1b1915d/attachment.html 


More information about the hibernate-dev mailing list