[Engine-devel] Jar versions in ovirt-engine

Thu Apr 19 13:22:03 UTC 2012

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.
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.
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.
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.

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.

> 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?