On 07/18/2013 09:39 AM, Mikolaj Izdebski wrote:
%add_maven_depmap macro now injects pom.properties to every JAR file
processes. This will allow XMVn Subst to be used to replace any JAR
For some of our products, we may end up having jars in two (or more)
separate locations where symlinking may not be possible. Because of
this, I try to never modify the jars after %build. And if we (including
Fedora) used an proper maven repository, then I suppose no one would do
this as it would invalidate the current checksum maven files and so
likely those would need to be regenerated by an rpm brp script.
So, my concern is that the jar is modified in the %install section. I
guess for Fedora this may be safer, as I believe the %add_maven_depmap
macro also installs the modified jar even though the modification may
technically happen during the wrong build phase.
%add_to_maven_depmap and %update_maven_depmap macros were removed.
These macros have been obsolete for long time. Their usage was
preventing Fedora from implementing some features related to Maven
metadata. Packages using these macros will have to be ported to use
%add_maven_depmap or they will fail to build.
I am aware that Fedora has not been using the aggregate depmap file for
a long time, but I am not sure what you men here. Can you elaborate?
I guess you have more manpower than I do. As I am just one person, I am
looking at ways to produce various repos without having to rebuild every
Java packages to pick up a new macro.
I think it would be better practice, at least, if a macro simply
expanded to a call of a script. Then this code could be modified at any
time. I am aware there's still a risk as old packages would have to be
I don't think that Fedora or RHEL has ever implemented the great
functionality in Mandriva/Mageia's RPM file triggers (NB: I am not
talking about %trigger).
3) jpackage-utils didn't have update to new upstream version for
-- it was de-facto maintained by Fedora developers. Removing custom
patchsets from our packages allows for better separation of upstream
code from RPM packaging and simplifies overall maintenance.
I am not sure that this is accurate. There is a jpackage-utils 5.0.0 out
there, although I am not sure it added any relevant features. Granted,
there may not have been an official 5.0 release, but you make it sound
as if no work had been done in the past seven years which is not the case.