On 02/06/2014 05:12 PM, Florian Weimer wrote:
On 02/06/2014 01:04 PM, Mikolaj Izdebski wrote:
> maven-local builds packages using upstream POMs. If they are using
> techniques inappropriate for Fedora (like maven-jajjar-plugin,
> maven-shade-plugin, maven-assembly-plugin) then its packager
> responsibility to modify POMs in %prep so that they conform to our
> policy and standards. There are even specialised RPM macros to help
> with that (for example %pom_remove_plugin, see man pom_remove_plugin).
Is maven-assembly-plugin really wrong, assuming that dependencies have a
"provided" scope? I'm adding <scope>provided</scope> like this
during
the %prep stage, and appears to prevent copying over classes:
# Do not bundle dependencies in the generated JAR file.
%pom_xpath_inject
"/pom:project/pom:dependencies/pom:dependency[./pom:artifactId =
'victims-lib' or ./pom:artifactId = 'maven-model']"
"<scope>provided</scope>"
Modifying upstream POM files changing dependency scope to "provided" is
purely wrong in many cases as such POMs won't be usable to build other
packages.
Maven Assembly Plugin can generate assembles with dependencies with any
scope you want. By default it's "runtime", but that's just a matter of
configuration.
Now I only need to figure out a way to auto-generate the
dependencies
and the classpath entries for %jpackage_script. This will not
completely fix things (because the JAR list will still break
encapsulation), but it will remove a lot of the pain.
Transitive dependencies aren't handled automatically by %jpackage_script
for a good reason -- often they are very excessive. Maven not only
offers many dependency scopes, but allows optional dependencies and it's
practically impossible to generate the proper classpath. Packager needs
to do that manually.
It might be possible to generate classpath and allow packagers to
exclude unwanted dependencies, but that's a future feature. You would
need to file a RFE for javapackages-tools.
--
Mikolaj Izdebski
IRC: mizdebsk