On 02/17/2012 02:29 AM, Aleksandar Kurtakov wrote:
I've spend enough time on getting this working and it really is
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
I don't understand this point. We can not use maven gid:aid or
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
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
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.