----- Original Message -----
From: "Mikolaj Izdebski" <mizdebsk(a)redhat.com>
Sent: Wednesday, February 27, 2013 6:07:07 PM
Subject: Re: [fedora-java] New Java guidelines
> > I think we are talking about packages that already have POMs.
> > Maven
> > unaware packages can still install stuff in %_javadir.
> Well, we speak about cases where the fedora package has a pom.xml.
> Many times it's simply picked from maven central and has nothing to
> do with the upstream maintainers (many times this poms are plain
> wrong too). And this causes problems - ant, rhino, ecj, etc. - we
> fought problems with all of their maven central pom.xml files (some
> of them e.g. ant ship their proper pom.xml files now, but many
Any bugs in package POM files should be fixed on per-package basis
should not prevent clean and legitimate POMs from doing things like
forming Maven repository.
While I agree with this in general.
The bugs in this case is actually installing pom.xml files that are not upstream. So yes -
this needs to be done on case by case - but before introducing some weird naming which
someone came with the pom.xml needs to be upstreamed first so we don't came with jar
name with crap like in the ecj package. And this is a very long, very very long process.
ecj package ships
org.eclipse.jdt:core with additional depmap org.eclipse.tycho:org.eclipse.jdt.core
). Using each of those for
will be equally wrong because according to upstream it should be
but this pom is unusable for people that rely on maven dependencies to resolve as deps are
not recorded in the pom and etc..
Note that I don't question such thing being done for packages that has maven as their
primary deployment system. But for cases like ecj putting in such a directory layout will
be huge mistake as primary users of it has no idea about gid:aid nor rely on it at all so
asking someone that requires on ecj (being gcc or eclipse) to look for the jar in some
gid/aid/aid-version will not fix what David was complaining about but just move it from
one group to another. People can make whatever symlinks they want in such cases but they
should be just that *symlinks* as this is second thought for such packages (if a thought
Red Hat Eclipse team