[Engine-devel] Jar versions in ovirt-engine

Thu Apr 19 14:10:24 UTC 2012

On 19/04/12 16:53, Juan Hernandez wrote:
> 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.
> 
See below, we actually share the same view...

>> 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.
> 
See below... converging into the latest jar is what I figured that
will happen. Still, as I see it such constraints are not really needed.
>> 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).
> 
It's a good start.

>> 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.
> 
Why not /usr/share/java/ovirt-engine-3/ ? I do not see someone using
engine3 and engine4 on the same machine, but he may need to have
engine-config v3 to handle previous instance and engine-config v4
to handle current instance, so we could have a good infra if we
keep the major version.

-- 

/d

"The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963)