----- Original Message ----- > From: "David Walluck" <david@xxxxxxxx> > To: java-devel@xxxxxxxxxxxxxxxxxxxxxxx > Sent: Friday, February 17, 2012 11:06:21 AM > Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/java-devel -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
