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.
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'
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
%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
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.
Software Engineer, Red Hat