Re: [fedora-java] Fedora vs JPackage naming
----- Original Message -----
From: "David Walluck" <david(a)zarb.org>
To: java-devel(a)lists.fedoraproject.org
Sent: Friday, February 17, 2012 11:06:21 AM
Subject: Re: [fedora-java] Fedora vs JPackage naming
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.
This should work just fine once someone implements adding version information to the maven
provides generator assuming you stick to using the mvn(gid:aid) format.
> 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.
Nope, no changes to RPM itself are required. RPM provides an extension point for
dependency generators which we have implemented in entirely separate project and shipped
with jpackage-utils in Fedora for quite some time. See
http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator for details.
> 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.
Again, having proper mvn(gid:aid) = pom_version provides should serve this purpose. There
should be just someone motivated to enhance the current generator.
> 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?
If it's build with maven, maven integration is a MUST.
Otherwise maven integration is a SHOULD which I read as non-mandatory (aka you can choose
to not deal with it) but nice-to-have (aka you can't object if someone else does it).
> 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.
Well, xml libs are so many and so different that we all would live in a better world once
projects learn to use the xml apis in the JDK. So the right fix for this one in my eyes is
fix your project to not depend on xerces instead of care how is it packaged.
Alex
> 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.
--
java-devel mailing list
java-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel