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
