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. 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. > 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. > 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? > 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. > 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. > 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. -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
