[Engine-devel] Jar versions in ovirt-engine
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
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@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.
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
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@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. - 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. 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. -- /d "Forty-two," said Deep Thought, with infinite majesty and calm. --Douglas Adams, The Hitchhiker's Guide to the Galaxy
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@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. 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]).
- 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.
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 :-) . [1] - https://fedoraproject.org/wiki/Packaging:Java#Filenames [2] - https://bugzilla.redhat.com/show_bug.cgi?id=807017#c13
On 04/19/2012 12:26 PM, Juan Hernandez wrote:
In fact if the build generates jar files with version numbers in the name the RPM should remove those jar files.
I wanted to say "the RPM should remove those version numbers", sorry. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
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@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?
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@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?
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@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)
On 04/19/2012 04:10 PM, Doron Fediuck wrote:
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@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.
The only thing I have against ovirt-engine-3 is that the packaging guidelines recommend to use /usr/share/java/%{name}, where %{name} is the name of the package, and the package has already been approved with the name ovirt-engine. Next major version (not 3.1, that is a minor version) can perfectly be named ovirt-engine4 or ovirt4-engine.
On 19/04/12 17:17, Juan Hernandez wrote:
On 04/19/2012 04:10 PM, Doron Fediuck wrote:
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@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.
The only thing I have against ovirt-engine-3 is that the packaging guidelines recommend to use /usr/share/java/%{name}, where %{name} is the name of the package, and the package has already been approved with the name ovirt-engine. Next major version (not 3.1, that is a minor version) can perfectly be named ovirt-engine4 or ovirt4-engine.
Maybe open a bz for it so we'll remember? Make sure to add this thread so we'll know what happened.... -- /d "Air conditioned environment - Do NOT open Windows!"
On 04/19/2012 04:21 PM, Doron Fediuck wrote:
On 19/04/12 17:17, Juan Hernandez wrote:
On 04/19/2012 04:10 PM, Doron Fediuck wrote:
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@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.
The only thing I have against ovirt-engine-3 is that the packaging guidelines recommend to use /usr/share/java/%{name}, where %{name} is the name of the package, and the package has already been approved with the name ovirt-engine. Next major version (not 3.1, that is a minor version) can perfectly be named ovirt-engine4 or ovirt4-engine.
Maybe open a bz for it so we'll remember? Make sure to add this thread so we'll know what happened....
There you go: https://bugzilla.redhat.com/814295
On 19/04/12 17:31, Juan Hernandez wrote:
On 04/19/2012 04:21 PM, Doron Fediuck wrote:
On 19/04/12 17:17, Juan Hernandez wrote:
On 04/19/2012 04:10 PM, Doron Fediuck wrote:
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@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.
The only thing I have against ovirt-engine-3 is that the packaging guidelines recommend to use /usr/share/java/%{name}, where %{name} is the name of the package, and the package has already been approved with the name ovirt-engine. Next major version (not 3.1, that is a minor version) can perfectly be named ovirt-engine4 or ovirt4-engine.
Maybe open a bz for it so we'll remember? Make sure to add this thread so we'll know what happened....
There you go: https://bugzilla.redhat.com/814295 Great, 10x!
-- /d "All computers wait at the same speed."
participants (4)
-
Doron Fediuck -
Juan Hernandez -
Juan Hernandez -
Ofer Schreiber