[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: Getting rid of maven2-depmap.xml



On 11 June 2011 21:19, Alexander Kurtakov <akurtako@xxxxxxxxxx> wrote:
> On 11:17:23 PM Saturday, June 11, 2011 Mat Booth wrote:
>> On 10 June 2011 12:06, Alexander Kurtakov <akurtako@xxxxxxxxxx> 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?
>
> Yup,
> Stanislav wrote a new resolver that uses jars from /usr/share while maven2 was
> coping them to local repo. :) This change surely caused the biggest
> improvement.
>
> Alex
> --

Heh, should have guessed at something like that. Seems obvious now. :-)


-- 
Mat Booth
http://fedoraproject.org/get-fedora
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel



[Home]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Red Hat 9 Bible]     [Fedora Bible]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

Powered by Linux

Google
  Web www.spinics.net