FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development Java

 
 
LinkBack Thread Tools
 
Old 06-10-2011, 11:06 AM
Alexander Kurtakov
 
Default Getting rid of maven2-depmap.xml

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.

Regards,
Alex

>
> Keep up the good work,
> Alex
>
> > --
> > Stanislav Ochotnicky <sochotnicky@redhat.com>
> > Software Engineer - Base Operating Systems Brno
> >
> > PGP: 7B087241
> > Red Hat Inc. http://cz.redhat.com
>
> --
> java-devel mailing list
> java-devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/java-devel
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 06-11-2011, 12:43 PM
Mat Booth
 
Default Getting rid of maven2-depmap.xml

On 10 June 2011 12:06, Alexander Kurtakov <akurtako@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
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 06-11-2011, 08:19 PM
Alexander Kurtakov
 
Default Getting rid of maven2-depmap.xml

On 11:17:23 PM Saturday, June 11, 2011 Mat Booth wrote:
> On 10 June 2011 12:06, Alexander Kurtakov <akurtako@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?

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
--
java-devel mailing list
java-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 
Old 06-12-2011, 08:18 PM
Mat Booth
 
Default Getting rid of maven2-depmap.xml

On 11 June 2011 21:19, Alexander Kurtakov <akurtako@redhat.com> wrote:
> On 11:17:23 PM Saturday, June 11, 2011 Mat Booth wrote:
>> On 10 June 2011 12:06, Alexander Kurtakov <akurtako@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?
>
> 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel
 

Thread Tools




All times are GMT. The time now is 10:26 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org