On 07/22/2013 12:40 AM, Mikolaj Izdebski wrote:
> JARs are modified only by files *not* built with Maven -- these files
> wouldn't have checksums generated. Even if we wanted to generate proper
Right, of course. I'm sorry that I missed this. Otherwise, they should
already contain the pom.xml and pom.properties files. I even use this
fact myself in order to tell whether maven has been used to build the
official jar on maven central or not.
> Besides that Java packaging never stricylt respected RPM build sections.
> Tests are often ran in %build instead of %check and some files are
Actually, %check doesn't always work due to various technical
assumptions, so I tend to purposely never use it.
> 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.
When we need to create a file that technically is not created by the
build, we can create it directly in %{buildroot}, which has to be done
in %install. Otherwise, I believe it is best to do it in %prep, but
usually never %build.
Packagers don't always follow the best policies, and I have even made
the mistake myself. But, now we are taking a lot of the manual work away
from the packagers which should make it less likely to make these kind
of packaging errors.
> 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.
Actually, I do agree on the level of inactivity at present. I am a bit
philosophically apposed to some of the macros, but I am not sure there's
much of a point to bring that up here. In short, modifying poms can lead
to lazier packaging, e.g., the stripping out many dependencies instead
of bothering to build them. My other concern is that it makes us move
away from the RPM principle of using patches by instead performing a lot
of trickery in %prep rather than fixing it at the source level.
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
