On 07/21/2013 07:08 AM, David Walluck wrote: > 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. JARs are modified only by files *not* built with Maven -- these files wouldn't have checksums generated. Even if we wanted to generate proper repository then checksums would have to be generated separately from Maven and that can easily be done after injecting Maven metadata. > 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. Files built with Maven already have all necessary metadata included and they are not repackaged. In this case metadata is added in `%build' section. Besides that Java packaging never stricylt respected RPM build sections. Tests are often ran in %build instead of %check and some files are generated in %install and not %build (%add_to_maven_depmap and %jpackage_script are examples of file generation in %install). That theoretically happens wrong RPM build phases, but I think that changing this would only be a pointless effort. > >> %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? As I explained in my email, %add_maven_depmap now injects some additioinal metadata to JARs it processes. To have that metadata included in all system JARs known to Maven one would have either to modify %add_to_maven_depmap to inject that metadata too, or make sure that no package uses %add_to_maven_depmap. Because %add_to_maven_depmap has been obsolete for quite long time and quite few packages still use it I decided to remove it so that during the next mass rebuild all packages would need to be migrated to %add_maven_depmap and could benefit from the new feature (the embedded pom.properties). %update_maven_depmap was removed too as it was implemented to NOOP and it was usually used in conjunction with %add_to_maven_depmap -- both macro usages can be removed together in the same commit. > > 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. Unlike the original JPackage (%add_to_maven_depmap, %update_maven_depmap, %jpackage_script and others) *all* Fedora macros *do* expand to external scripts. %add_maven_depmap calls maven_depmap.py Python script (as processing XML in shell wouldn't be very nice). There are 20 other Fedora macros (14 %pom_* macros and 6 %mvn_* macros) which are simple wrappers for shell scripts. > >> 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. This doesn't change the fact that there was no update for very long time and that Fedora maintained its own set of patches. A separate project (javapackages) has been created to develop Fedora-specific macros while keep jpackage-utils close to what JPackage uses in hope that our changes could be synchronized in future. But that didn't happen (yet). If there is a willingness from JPackage side I am all for merging our efforts. Red Hat has licensed the javapackages project under the same terms as JPackage (BSD license) precisely because it would allow to merge our changes easily back to JPackage. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
