[Engine-devel] Jar versions in ovirt-engine

Thu Apr 19 13:53:55 UTC 2012

On 04/19/2012 03:22 PM, Doron Fediuck wrote:
> On 19/04/12 13:26, Juan Hernandez wrote:
>> On 04/19/2012 12:00 PM, Doron Fediuck wrote:
>>> On 18/04/12 14:04, Juan Hernandez wrote:
>>>> On 04/18/2012 09:51 AM, Ofer Schreiber wrote:
>>>>> Ever wondered why the version of oVirt's first release is 3.0.0_0001?
>>>>> The answer is simple - We use ovirt-engine jar's version as our "main" release version.
>>>>>
>>>>> Personally, I think the current versioning scheme is ugly. Actually, I can't name even one open-source project using "_" in it's version.
>>>>>
>>>>> What can we do about it? We have couple of options:
>>>>> 1. Leave the engine alone, and use a separate versioning scheme (e.g - use just 3.1.0 as the main version for next release)
>>>>> 2. Remove "_" from engine jars
>>>>> 3. Do nothing.
>>>>>
>>>>> I'd like to hear your thoughts, as well as the reasons to use such an unusual versioning scheme.
>>>>>
>>>>> ---
>>>>> Ofer Schreiber
>>>>> oVirt Release Manager
>>>>> _______________________________________________
>>>>> Arch mailing list
>>>>> Arch at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/arch
>>>>
>>>> From my point of view using the 0001 suffix in the names of the jar
>>>> files is not a big problem, but I agree that using it in the release
>>>> number is ugly, and it produces issues/discussions during packaging. I
>>>> vote for option #1: use 3.1.0 for the next main version.
>>>>
>>>
>>> The original versioning scheme was due to a bug in maven2.
>>>
>>> Juan, I've read some of the Java packaging concepts, but didn't see
>>> (or missed) thoughts about modular versioning (ie- artifacts).
>>>
>>> Here are the things to consider here;
>>>
>>> - Current RPM's are using the version declared in the POM files.
>>> Should this concept remain?
>>> * I think it should remain, as other packaging systems should
>>> be able to use it as well and end-up is the similar project version.
>>
>> I can talk from the Fedora point of view only, as that is what I know a bit.
>>
>> In Fedora there can be only one version of a given jar file installed in
>> the system, so there is no point in adding a version number to the name
>> of that jar file: the version number is already in the package
>> containing that jar file. In fact if the build generates jar files with
>> version numbers in the name the RPM should remove those jar files. That
>> is why I say that having any kind of numbers in the names of the jars is
>> not important: we have to remove them anyway.
>>
>> Packaging guidelines (see [1]) recommend to avoid version numbers in the
>> jar files, and I think that makes sense.
>>
> This would be the easy solution.

Again talking only about Fedora:

Having just one version of every jar is not simple at all, in fact it
requires a lot of work to make sure that the selected versions work
properly together.

> What happens when you have more than a single Java app, and both
> using different versions of the same jar file? This means that one
> of the app's will need to bring it along and use it locally, rather
> than system-level usage.

What happens is that both applications have to be patched so that they
work correctly with the same version of that jar file. If possible the
patches are pushed upstream, if not they applied as part of the package.
Embedding another version of that jar file in one of the applications is
not allowed, in fact that is something that packagers have to undo quite
often.

> I'm guessing if we assume such a constraint the solution will be
> to force all app's to use latest jar version, which isn't trivial.

I agree completely, it is not trivial at all, that is where packagers
expend most of their time.

> So some distro's will allow of concept of slotted installation.
> This means I currently /have/ 2 working versions of postgres in
> my laptop (using Gentoo)-
> 
> equery l postgresql-server
>  * Searching for postgresql-server ...
> [IP-] [  ] dev-db/postgresql-server-8.4.11:8.4
> [IP-] [  ] dev-db/postgresql-server-9.1.3:9.1
> 
> The same works on my laptop for Maven, Java, Python and many others.
> If you think about it, Fedora supports slotted installation for
> kernels, and then added alternatives to do that with other packages
> as well (mta, Java..). So there's a need and a way to handle several
> versions of the same library (regardless of the language), and
> we should be careful when taking such assumptions. At least try
> to be as flexible as possible, to allow others to join in.

In Fedora that is allowed only for major versions: java-1.7.0 and
java-1.6.0, maven 2 and maven 3, so on, but not usually for minor
versions (there are exceptions).

> So learning from Fedora I'd say- let the RPM install in a versioned
> folder (ie- /usr/lib/jvm/jre-1.5.0-gcj/..), and leave the jar
> files without versions for now. In the future we may need to change it
> as some disrto's may use sym links to indicate the latest jar.
> In such a case the RPM will stripdown the version from the artifact.

What we are currently doing with the Fedora ovirt-engine package is that
jar files are installed to /usr/share/java/ovirt-engine, with names like
bll.jar, common.jar, compat.jar, etc. The RPM takes care of stripping
the version numbers generated by the upstream build. This doesn't
preclude other distros from doing it in a different way, using version
numbers or symlinks.

>> On the other hand adding that _0001 suffix to the project itself
>> complicates (just a bit) the packaging. It has to be discussed where
>> that "postrelease" number has to go: in the version tag of the package,
>> in the release tag? You can see an example of that discussion in the
>> review bug of the ovirt-engine package (see [2]).
>>
> I agree. As I said- it was meant to be for maven2 bug solution.
> Not needed when we move to maven3.
>  
>>> - Do we want to expose oVirt engine artifacts in a Maven repo
>>> for others to consume?
>>> * If we do, we'll need to make sure we have a scheme that works both for
>>> Maven and for packaging (RPM) comparisons.
>>
>> I think that we don't need to make the artifacts available for others
>> now. Is anyone consuming those artifacts? However I agree that is good
>> to have numbering that works for Maven and RPM.
>>
> If we won't allow artifact consumption, we won't have it ;)
> The idea is to be able to share artifacts between sibling projects
> as well as external ones. As I see it, modular programming is
> integrating several sub-projects into a working project,
> based on an API. So each sub-project (/module/artifact)
> may be shared with others. Does this makes sense?
> Still, happy we agree on the bottom line :)
> 
>>> One last thing...
>>> I know most of the packaging work now is RPM based. Still, I'm
>>> asking you to leave enough room for non-RPM distro's to join in.
>>
>> I am a bit (well, maybe a byte) RPM biased, mainly because that is what
>> I know, but I don't want to complicate packaging with other mechanisms.
>> Please let me know if I do :-) .
> Simplicity is the best policy, as long as we do not drive away
> others.
> 
>>
>> [1] - https://fedoraproject.org/wiki/Packaging:Java#Filenames
>> [2] - https://bugzilla.redhat.com/show_bug.cgi?