On 07/18/2013 09:39 AM, Mikolaj Izdebski wrote: > %add_maven_depmap macro now injects pom.properties to every JAR file it > 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 reinstalled. 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 7 years > -- 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. -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
