[fedora-java] Fedora vs JPackage naming

Fri Feb 17 08:35:26 UTC 2012

----- Original Message -----
> From: "David Walluck" <david at zarb.org>
> To: java-devel at lists.fedoraproject.org
> Sent: Friday, February 17, 2012 9:59:18 AM
> Subject: Re: [fedora-java] Fedora vs JPackage naming
> 
> On 02/17/2012 02:29 AM, Aleksandar Kurtakov wrote:
> > I've spend enough time on getting this working and it really is
> > now.
> > If your package installs pom.xml file it will have Provide:
> > mvn(gid:aid) If your package is an osgi bundle it will have
> > Provide:
> > osgi(bundle-symbolic-name) If it installs pom.xml and is osgi
> > bundle
> > it will have both Provides. When in doubt just use that or use yum
> > to
> > tell you the package name.
> 
> Does it set the version properly too? I know that certain characters
> are
> not allowed in the RPM version string so it would have to normalize
> it
> somehow. Currently, we don't have this on RHEL 6, so I haven't
> actually
> seen it in action.

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 - if someone wants to enhance the maven provides generator - the code is at http://git.fedorahosted.org/git/?p=javapackages.git . Assuming that others are more interested in the maven case I'll be happy to guide them in achieving this. I get it to the point where it serves the generic Fedora case well and let the community enhance it if someone needs the version.
RHEL is out of question in this thread and I would not comment it at all here.
> 
> The Fedora Release tag policy prevents proper versioning of
> BuildRequires since important parts of the version string end up in
> the
> Release tag for no good reason. Since RPM compares both the V and the
> R,
> moving things from V to R doesn't really make sense. RPM also
> compares
> text strings in both, and while it may not exactly match how maven or
> osgi compares, I think it's better than nothing and at least
> internally
> consistent.

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.

> 
> > I don't understand this point. We can not use maven gid:aid or osgi
> > symbolic-name as package names. The mess will become way bigger in
> > this case - it will be: * for maven packages use gid-aid as package
> > names * for osgi packages use symbolic names * for jars that are
> > neither - stick to the project names * for packages that are both
> > maven and osgi ? - should we give the packager a choice? I don't
> > feel
> > it's right to ask osgi developers to care about maven and
> > vise-versa
> > so letting the packager makes a choice seems like the right choice.
> 
> I guess I would say to just pick one. If we have a policy that each
> package must have a POM (or OSGI support---your choice), then each
> package is also guarnateed to have a unique name in those systems.

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.

> 
> > But just imagine the mess this will be !!! I'm definetely not
> > looking
> > for this. People should learn to use the virtual provides for the
> > time being (until there is suitable! module system in java world).
> 
> OK, you have some point to this in that we can start using these
> names
> and pretend that the package name doesn't exist. But this only works
> if
> the artifact names and locations are fixed too, right?

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.

> 
> > I'm really tired of seeing this remarks. It is my choice to make
> > this
> > tool this way and people should respect that. Everyone is free to
> > come with better(where better means more suitable for him) ones
> 
> I never said anything bad about your tool. If you look at what I
> said,
> my choice was 100% driven by bandwidth concerns and my crappy
> internet
> speed. It had nothing to do with software even. As I think you know,
> I
> used to use Eclipse a lot in the past (especially when I was doing
> Java
> development), and if I was able to do development on my local machine
> I'd probably be using it now.
> 
> So again, I have nothing bad to say about your tool. But, I wonder if
> parts of it are not tied to the GUI, then we could prehaps reuse a
> lot
> of code to provide a headless solution? I am not saying that you (or
> I)
> would be willing to code such a thing, but I am wondering if it makes
> sense.

Sorry David, I'm bit touchy on the subject because I see these remarks too often and most of the time from people that haven't even tried something. My reply is because of my personal feelings about the topic and how will a number of people read it (though I know 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 class implementing IApplication that will call the command with the correct parameters that will allow people to run it headless(without gui) aka eclipse -application myapp . If there is anything else needed in the code I'll be happy to do it but I would not drive such an effort myself. I care for people being able to use my work but people should be ready to step in :).

> 
> > There is one huge difference here - perl and python are modulized
> > upstream, with every module having it's own tarball an release
> > (most
> > of the times). Thus this comparison is irrelevant here until this
> > happens upstream in java land.
> 
> So, should we wait for Jigsaw? Will Jigsaw actually solve anything?
> If
> yes, then we could at least start to plan for it.

Wait - no . Jigsaw is work in progress AFAIK so people should join there and help drive it for our needs.

> 
> > If we want to be more of a product than a bunch of random packages
> > I
> > think that this things should be set distro wide so there are no
> > distro wide and enforced in a way that we don't see the current
> > mess.
> 
> Good point. But if there were such specific standards, a tool can
> generate to such standards, and rpmlint already exists to complain
> about
> such things, although I don't know that it's actually deployed for
> Fedora.

Rpmlint is supposed to be used during review but I would not say it's deployed distro wide. At least not in the way it was at Mandriva - with build system rejecting builds on certain rpmlint errors. But this is fight I'm not ready to step in.

Alex

> --
> java-devel mailing list
> java-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel