On 02/17/2012 03:35 AM, Aleksandar Kurtakov wrote:
Yes, there is Provides: osgi(org.apache.commons.codec) = 1.6.0 for
apache-commons-codec. I'm not aware of the characters problem for the
osgi case and versions in the maven case doesn't make sense as we
ignore them. Though having the version in the provides wouldn't hurt
I would like to, for example, BuildRequires >= <version in pom>. I give
a specific example later on.
someone needs the version. RHEL is out of question in this thread
I would not comment it at all here.
All I mean is that the changes apparently require changes to RPM itself
so that unlike jpackage-utils macros, the changes are not portable.
Unless I am mistaken. For example, we can install jpackage-utils on RHEL
(or anywhere else) and immediately get the support for various macros, etc.
Well, I'm not sure how the release tag will be a problem if e.g.
using Requires: osgi(org.apache.commons.codec) >= 1.6.0 . Note that
the bundle version is used not the package version so the release is
irrelevant unless we try to fight other issues with this like class
versions, apiincompatibilities and etc. which are different problems
in my eyes.
A typical jboss version 1.0.0.CR2. I would like to say >= 1.0.0.CR2.
But, I can't, because it's 1.0.0-99.CR2 or something instead. Even
though putting the CR2 in the version string would be absolutely fine
except that it violates some stupid policy that is apparently not based
on actual RPM versioning semantics and again some abitrary prefs of some
Yes, but we already have too few contributors and trying to force
them either the osgi or maven route will probably make them stop
contributing. That's why I think we can not make this choice until
there is a defacto module system.
There is no policy that already dictates, e.g., support for maven?
Well, we are working hard on this too and such cases are very rare
nowadays but if there is something this is a bug and deserves a bug
Well, package xerces-j2 historically installed xerces-j2.jar, but it
should have been xercesImpl.jar all along because this is what
everything and everybody expects.
exactly what you ment) that's why I commented it. There are
options to use eclipse locally with projects on remote filesystem but
this thread is not the right place. Technically it is adding one
Yes, I know some things such as sshfs, but anyway.