[fedora-java] Getting rid of maven2-depmap.xml

[Mat Booth]

On 10 June 2011 12:06, Alexander Kurtakov <akurtako at redhat.com> wrote:
> On 01:58:33 PM Friday, June 10, 2011 Alexander Kurtakov wrote:
>> On 01:01:39 PM Friday, June 10, 2011 Stanislav Ochotnicky wrote:
>> > This is just an update on progress on migrating from maven2 to maven
>> > package.
>> >
>> > I just committed changes to maven package that will do a few things:
>> >  * direct processing of fragment files generated by %add*_maven_depmap
>> >
>> >    macros
>> >
>> >  * being able to process fragments in /usr/share/maven-fragments
>> >  * being able to resolve pom files in /usr/share/maven-poms
>> >
>> > This will mean several things once the whole puzzle is created:
>> >  * No need for %update_maven_depmap macro in %post and %postun
>> >  * With it - no need for Require(post): jpackage-utils
>> >  * No more rpmlint warnings about non-conf file in /etc
>> >  * Sane place for pom files :-)
>> >  * Simpler packaging (IMO)
>> >  * Later on simpler patches to maven once we remove compat code.
>> >
>> > For now we are backward compatible, so maven still reads from
>> > /etc/maven/fragments and old _mavenpomdir.
>> >
>> > Obviously there is certain performance penalty for processing few
>> > hundred small files instead of one big file. However this performance
>> > hit is rather small and only affects mvn-local and mvn-rpmbuild
>> > so it won't affect users.
>> >
>> > Worst case scenario, I'd rather move regenerating of depmaps into
>> > maven shell script (comparing last change of depmap.xml with last
>> > modification of fragments and all that...).
>> >
>> > Right now no packaging modifications are necessary, since we don't
>> > want to break maven2 just yet :-)
>> >
>> > Next up: jpackage-utils and generation of maven2-depmap.xml even from
>> > /usr/share/maven-fragments (for maven2 compat).
>> >
>> >
>> > See https://fedoraproject.org/wiki/Migration_from_maven2 for more
>> > details and plan.
>>
>> Everything that simplifies packaging and doesn't degrade performance is an
>> absolute win :).
>> I'm already impressed with the speed improvements with our packaged version
>> of maven 3.x (it's few times! faster not few percents) so few percents
>> performance hit won't be noticed from people moving from maven2 to maven
>> 3.x.
>
> Just to put some details. All executions are on my laptop 3rd attempt so all
> the caches are hot :)
>
> qdox package build with maven2:
> real    1m51.801s
> user    1m36.492s
> sys     0m9.199s
>
> qdox package build with maven3:
> real    0m41.633s
> user    0m49.766s
> sys     0m5.210s
>
>
> Isn't it impressive? :) Let's say ~3 times faster for.
>

Nice, I didn't expect such massive improvements there. :-) Do you
happen to know what the bottleneck was in maven2? Where was it
spending all of its time?


-- 
Mat Booth
http://fedoraproject.org/get-fedora