#257 Issue with xmvn package doing embedding of other packages content
Closed: Fixed None Opened 11 years ago by akurtakov.

A recent change in xmvn package was introduced that started to embed parts of it BuildRequires in the package built.
As this is a build tool and the maintainer refuses to listen to the concerns from others about this introducing needless number of rebuilds - if a problem is fixed in the required package, all packages requiring it needs to be rebuild. Note that this can go recursively.
With the embedding we can have different versions of the required package in various places so a change in the lowest level might need few rounds of rebuild to get the fix everywhere.
Also this introduces changes from upstream for every single package that ships pom.xml file and builds with it hence making communication harder with upstreams as we introduce these obvious changes.
I agree that this simplifies packaging but the cos of that are way bigger and introducing such change in secret without widely announcing it is breaking the community way of doing things. Also refusing to stay to the current state of affairs until the Java SIG agrees is not the right way to work with others.

Note that I'm bringing this to FPC as everything started from the proposed change to the Java guidelines and this change is introducing automatic deviation from upstreams for every single pom file we ship so FPC has to say its word before we even continue discuss whether such things can ever be approved so we don't waste our time in endless cycles.

Full log of the Java SIG discussion is here:
http://meetbot.fedoraproject.org/fedora-meeting/2013-02-19/java_sig.2013-02-19-16.00.log.html


Also if such deviation is unacceptable I would kindly ask you to ask the maintainer of xmvn package to change its behaviour to not do this changes.

FYI: Mutual understanding why both effective and standard poms are needed happened after discussion and changes to xmvn/maven-local happened to install both effective and normal poms and an option to resolve against normal poms to allow development and easy recovery in case of major change in parent poms. As a result I'm closing the ticket as resolved.

Login to comment on this ticket.

Metadata