Quoting Mikolaj Izdebski (2012-12-07 12:55:53)
> Hello all,
>
> 1) jpackage-utils requires generator
>
> Any package that contains Maven fragments in %{_mavendepmapfragdir}
> doesn't need to explicitly specify "Requires: jpackage-utils" any
> longer -- this dependency will be generated automatically by rpmbuild
> on build time. The same applies to javadoc packages (packages that
> install any files in %{_javadocdir}). For these kind of packages you
> can remove Requires: jpackage-utils lines form your spec files. This
> feature is implemented in Rawhide and will be backported to Fedora 17
> and 18.
>
> 3) maven package split
>
> Currently maven package is a monolithic package with a big dependency
> chain. It contains upstream Maven as well as Fedora-specific
> customizations (like mvn-rpmbuild script). Users that just want to use
> Maven don't need to have all the Fedora-specific extensions
> installed. Because of that maven package will be split into two parts:
>
> a) maven. This package will contain only upstream Maven, without any
> extensions or customizations. In other words, maven package will ship
> upstream-like maven.
>
> b) maven-local. This package will contain Fedora extensions for Maven
> and tools useful in building RPM packages containing Maven
> artifacts. This package will depend on maven and may also depend on
> certain Maven plugins and POM files. If you are building RPM packages
> using Maven you want to depend on maven-local.
>
> This means that all Java packages that use "BuildRequires: maven" will
> have to migrate to "BuildRequires: maven-local". You can (but you
> don't have to) start migrating them straight away. Packages that
> build-require maven will be migrated automatically in future (during a
> mass-rebuild).
>
> 4) Simplified %files sections
>
> During build Maven generates a number of files prefixed ".mfiles" that
> contain lists of installed files. You can use .mfiles* as an argument
> to -f option of %files macro instead of manually listing all files
> installed in a subpackage. Note that .mfiles* contain only files
> recognized by maven (such as pom, jar and fragment files), so any
> other files, such as documentation, still need to be listed explicitly.
I've backported this to F17+. This has been relatively big update for F17 so if
you notice any weird build issues in next few days/weeks let me know (should not
happen).
This also means that from this point when packaging for 17+ you no longer have
to add jpackage-utils for Maven packages (or javadoc packages). This is still
needed for packages that do not provide maven fragments, but that's a very small
percentage.
> 2) Java compiler source and target configuration
>
> In Rawhide Maven Compiler Plugin is now forced to enable source
> compatibility of at least Java 1.5 and target not older than
> source. This means that Java sources will be compiled as Java 1.5,
> even if POM files specify source format older than 1.5. It also means
> that JSR-14-like bugs will no longer exist because target format will
> never be older than source format.
This is not backported, but it should not matter (much).
> The above features (1-4) are already implemented and ready for
> use. There are some future features that are under development or
> testing. Let me describe them briefly:
>
> 5) Automatic requires generator - packages don't need to explicitly
> list dependencies on other maven artifacts, appropriate requires will
> be generated automatically from POM files.
>
> 6) Simplified %build and %install sections of spec files (these
> sections can be one-liners, %mvn_build and %mvn_install,
> respectively).
>
> Features 5 and 6 are under development. They are currently used by a
> small number of packages (as a form of testing in production). If you
> want to have impact on future of Fedora Java packaging you can take a
> look at example packages, report any bugs found and share your
> feedback. You can find out which packages use features 5 and 6 with
> repoquery:
>
> repoquery --qf %{name} --repoid rawhide-source --arch src --whatrequires xmvn
I you are maintaining complicated packages with long Requires lists and huge
%install sections you should definitely have a look. Good example is: have a
%look at maven-surefire in F18 vs. rawhide and you'll get an idea.
We are still facing some issues with auto requires generation and we'll have to
discuss them later on during some meeting I am sure.
--
Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
