[fedora-java] Fedora vs JPackage naming

[David Walluck]

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

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

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