Apply exclusions later?

[wecai]

We have a large dependency which has 300+ transitive dependencies, let's name 
the dependency as BigDep1.


We have large numbers of libraries that depend on BigDep1. We may add 
exclusions when we use these libraries in our project.

com.company...
Lib1

some_group_id
some_artifact_id
  
  


It took long time and huge memory to buid the project, we saw the BigDep1 is 
resolved thousands of times without hit from memory cache...


By checking the code,  we can see Maven is trying to load the resolved result 
of BigDep1 from cache, but as debugged it always failed to get the cached 
result.
We can see the key is determined by GAV, repositories, childSelector, 
childManager, childTraverser, childFilter, this means exclusions is considered 
as part of the key.
https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L504
| Object key = |
| | args.pool.toKey( d.getArtifact(), childRepos, childSelector, childManager, 
childTraverser, childFilter ); |
| | |
| | List children = args.pool.getChildren( key ); |
| | if ( children == null ) => always null. need recalculate and again save to 
cache which takes long time and consumes large memory |
| | { |
| | args.pool.putChildren( key, child.getChildren() ); |
| | |
| | args.nodes.push( child ); |
| | |
| | process( args, results, descriptorResult.getDependencies(), childRepos, 
childSelector, childManager, |
| | childTraverser, childFilter ); |
| | |
| | args.nodes.pop(); |
| | } |


Let me use a simple pattern to describe the problem:


Lib1 -> BigDep1
Lib2 -> Lib3 (has exclusion) -> BigDep1
Lib4 -> Lib2
...


Now in our project, we use libraries: Lib1, Lib2 , Lib4 with exclusions.


Project -> Lib1
Project -> Lib2
Project -> Lib4 (has exclusion)


Here is how maven resolve the dependencies:
maven starts to resolve Lib1, Lib1 -> BigDep1. maven first resolves BigDep1 and 
caches BigDep1 in memory
maven starts to resolve Lib2, Lib2 -> Lib3 (has exclusion) -> BigDep1, as Lib3 
has exclusion, so maven cannot load BigDep1 from cache and calculate BigDep1 
again. 
maven starts to resolve Lib4 (has exclusion), Lib4 (has exclusion) -> Lib2 
->Lib3 -> BigDep1,  as Lib4 has exclusion, so maven cannot load Lib2, Lib3, 
BigDep1 from cache, all of them recalculated.


I'm thinking if we can use GAV as the cache key and apply the exclusions later. 
maven can resolve the dependencies in this way:
maven starts to resolve Lib1, maven first resolves BigDep1 and caches BigDep1 
by using BigDep1's GAV as key.
maven starts to resolve Lib2, Lib2 -> Lib3 (has exclusion) -> BigDep1, maven 
get BigDep1 from cache, then calc Lib3 without applying exclusion and cache the 
result with Lib'3 GAV.
when maven comes to resolve Lib2, maven starts to apply Lib3's exclusion to 
Lib3, add Lib3 with exclusion as children of Lib2 and then cache Lib2. 
maven starts to resolve Lib4 (has exclusion), Lib4 (has exclusion) -> Lib2 
->Lib3 -> BigDep1,  maven get Lib2 from cache, then calc Lib4 without applying 
the exclusion and then cache Lib4.
when maven comes to resolve the current project, maven applies Lib4's 
exclusion, add Lib4 with exclusion as children of Project module, and then 
cache Project's resolved result. 


Does this make sense?


This means all libraries' resolved result are cached with its GAV.
Only the one which depends on it need to load the result from cache and apply 
exclusions if any.


Thanks,
Eric 

Discuss: maven-war-plugin build war archive directly without building exploded war

[Cai, Eric]

We have a large web project and there is large numbers of dependencies. When we 
run "mvn war:war", it usually takes 40s+ to build a war (~ 600MB) on a windows 
10 box and 15s + with a mac book.

By checking the war-plugin code, we know the plugin need first copy files 
necessary to a folder under project dir (exploded war), then archive the entire 
folder.
Copying the files to a new folder actually take a long time.

My question is:
Does it make sense to modify war-plugin to skip building the exploded war and 
directly create archive with original files? I think it can save quite a bit 
time.

src/main/webapp -> archive
target/classes -> archive
...

Any impacts if the exploded war is not created?

Thanks,
Eric

[GitHub] [maven-site] michael-o commented on pull request #240: Use an SPDX identifier in example, as recommended

[GitBox]

michael-o commented on pull request #240:
URL: https://github.com/apache/maven-site/pull/240#issuecomment-872241943


   > 
   > 
   > @michael-o I think it would make sense to re-write the docs when a SPDX 
field is added, but right now, the docs say to put SPDX into the name, but then 
don't actually do it.
   > 
   > Original SPDX suggesting PR for reference: #121
   
   I agree with you, this is confusing.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] rjmunro commented on pull request #240: Use an SPDX identifier in example, as recommended

[GitBox]

rjmunro commented on pull request #240:
URL: https://github.com/apache/maven-site/pull/240#issuecomment-872241122


   @michael-o I think it would make sense to re-write the docs when a SPDX 
field is added, but right now, the docs say to put SPDX into the name, but then 
don't actually do it.
   
   Original SPDX suggesting PR for reference: 
https://github.com/apache/maven-site/pull/121


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4 performances problems

[Romain Manni-Bucau]

+1 to fix it before any > alpha release but also agree it is fine to let
the alpha-1 go out while it is explicitly mentionned as known and under
work.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 1 juil. 2021 à 14:13, Michael Osipov  a écrit :

> Am 2021-07-01 um 11:19 schrieb Guillaume Nodet:
> > I've been running a few tests to measure performances.
> > This simplistic test looks like running the following command in a loop
> and
> > measure the execution time.  This is done on a quite big project so that
> a
> > bunch of pom files are actually read.
> >
> > for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
> > -Dmaven.experimental.buildconsumer=true help:evaluate
> > -Dexpression=java.io.tmpdir -DforceStdout -q ; done
> >
> > The average results are the following:
> > Maven 4 with build/consumer:  28,40s
> > Maven 4 w/out build/consumer: 23,43s
> > Maven 3:  21,54s
>
> Kindly try also with -Daether.syncContext.named.factory=nolock
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven 4 performances problems

[Michael Osipov]

Am 2021-07-01 um 11:19 schrieb Guillaume Nodet:

I've been running a few tests to measure performances.
This simplistic test looks like running the following command in a loop and
measure the execution time.  This is done on a quite big project so that a
bunch of pom files are actually read.

for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
-Dmaven.experimental.buildconsumer=true help:evaluate
-Dexpression=java.io.tmpdir -DforceStdout -q ; done

The average results are the following:
Maven 4 with build/consumer:  28,40s
Maven 4 w/out build/consumer: 23,43s
Maven 3:  21,54s


Kindly try also with -Daether.syncContext.named.factory=nolock

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] elharo merged pull request #244: docs: rewrite More Project Information

[GitBox]

elharo merged pull request #244:
URL: https://github.com/apache/maven-site/pull/244


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] elharo merged pull request #245: docs: remove forward looking statement

[GitBox]

elharo merged pull request #245:
URL: https://github.com/apache/maven-site/pull/245


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4 performances problems

[Guillaume Nodet]

No, I don't think this requires a delay in the alpha-1 release.

Le jeu. 1 juil. 2021 à 12:27, Robert Scholte  a
écrit :

> Should we postpone the alpha-1 release because of this?
> For me the most important reason for alpha-1 is to get confirmation that
> builds won't be broken due to build/consumer.
> But if users simply look at buildtime and due to some slower result don't
> care for the other changes, then we shouldn't do this release now.
>
> Robert
>
>
>
> On 1-7-2021 11:20:17, Guillaume Nodet  wrote:
> I've been running a few tests to measure performances.
> This simplistic test looks like running the following command in a loop and
> measure the execution time. This is done on a quite big project so that a
> bunch of pom files are actually read.
>
> for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
> -Dmaven.experimental.buildconsumer=true help:evaluate
> -Dexpression=java.io.tmpdir -DforceStdout -q ; done
>
> The average results are the following:
> Maven 4 with build/consumer: 28,40s
> Maven 4 w/out build/consumer: 23,43s
> Maven 3: 21,54s
>
> I find the 20% performance loss of the build/consumer feature quite
> problematic. I hinted about those possible performance problems when
> reviewing the original PR, so I'd like to see if I can investigate a
> different way of achieving the transformation. I think the main
> performance cost comes from using the following pattern:
> read file -> parse using JAXP -> transform using TRAX -> write to stream
> read stream -> parse using XPP3
> The first step is performed in a separate thread and the output written to
> a pipe stream which is used as the input of the usual pom parser. This
> double parsing step, in addition to using the JAXP / TRAX api, which is not
> the fastest one, comes at a heavy cost.
>
> I see two ways to solve the problem:
> * refactor the build/consumer feature to use a different API so that the
> parsing can be done in a single step (this would mean defining an XmlFilter
> interface to do the filtering and wrapping it inside an XmlPullParser)
> * get rid of the Xpp3 implementation and use the more common Stax api
> which already defines filters
>
> The second option has some drawbacks though: all the plugin configuration
> done using Xpp3Dom would not work anymore, so this is a very big and
> incompatible change.
>
> I'm thus willing to investigate the first option and see what can be done.
> If there's a consensus, I'll start working on a POC about the api / filters
> and will get back to this list with some more information.
>
> --
> 
> Guillaume Nodet
>


-- 

Guillaume Nodet

[GitHub] [maven-site] elharo opened a new pull request #244: docs: rewrite More Project Information

[GitBox]

elharo opened a new pull request #244:
URL: https://github.com/apache/maven-site/pull/244


   @michael-o focus on element's expected content, and in general be a little 
less flip and somewhat more direct


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] michael-o commented on pull request #240: Use an SPDX identifier in example, as recommended

[GitBox]

michael-o commented on pull request #240:
URL: https://github.com/apache/maven-site/pull/240#issuecomment-872147844


   I think this is wrong. the `name` shall remain as is. In a future version of 
the POM we will add something for SPDX. Therefore, I'd recommend to modify the 
SPDX part.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] elharo opened a new pull request #245: docs: remove forward looking statement

[GitBox]

elharo opened a new pull request #245:
URL: https://github.com/apache/maven-site/pull/245


   @khmarbaise


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site-plugin] elharo merged pull request #54: Bump slf4jVersion from 1.7.29 to 1.7.31

[GitBox]

elharo merged pull request #54:
URL: https://github.com/apache/maven-site-plugin/pull/54


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] elharo merged pull request #242: docs: minor cleanup

[GitBox]

elharo merged pull request #242:
URL: https://github.com/apache/maven-site/pull/242


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site] elharo commented on a change in pull request #240: Use an SPDX identifier in example, as recommended

[GitBox]

elharo commented on a change in pull request #240:
URL: https://github.com/apache/maven-site/pull/240#discussion_r662193689



##
File path: content/apt/pom.apt
##
@@ -1474,10 +1474,10 @@ Display parameters as parsed by Maven (in canonical 
form) and comparison result:
 +-+
 
   
-Apache License, Version 2.0
+Apache-2.0
 https://www.apache.org/licenses/LICENSE-2.0.txt
 repo
-A business-friendly OSS license
+Apache License, Version 2.0 - A business-friendly OSS 
license

Review comment:
   typography nit: you want an em dash — after 2.0, not a hyphen
   
   also probably make "A" lower case since it no longer starts the sentence and 
change "OSS" to "open source"




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 4 performances problems

[Anders Hammar]

I agree. We could even mention this known performance "issue" so there
wouldn't be any surprise.

/Anders

On Thu, Jul 1, 2021 at 12:29 PM Enrico Olivelli  wrote:

> Il giorno gio 1 lug 2021 alle ore 12:27 Robert Scholte <
> rfscho...@apache.org>
> ha scritto:
>
> > Should we postpone the alpha-1 release because of this?
> > For me the most important reason for alpha-1 is to get confirmation that
> > builds won't be broken due to build/consumer.
> >
>
> 100% agreed
> it is an ALPHA and there are many cool features, it is worth to give it to
> the users and get feedback
>
> my two cents
> Enrico
>
>
> > But if users simply look at buildtime and due to some slower result don't
> > care for the other changes, then we shouldn't do this release now.
>
>
> > Robert
> >
> >
> >
> > On 1-7-2021 11:20:17, Guillaume Nodet  wrote:
> > I've been running a few tests to measure performances.
> > This simplistic test looks like running the following command in a loop
> and
> > measure the execution time. This is done on a quite big project so that a
> > bunch of pom files are actually read.
> >
> > for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
> > -Dmaven.experimental.buildconsumer=true help:evaluate
> > -Dexpression=java.io.tmpdir -DforceStdout -q ; done
> >
> > The average results are the following:
> > Maven 4 with build/consumer: 28,40s
> > Maven 4 w/out build/consumer: 23,43s
> > Maven 3: 21,54s
> >
> > I find the 20% performance loss of the build/consumer feature quite
> > problematic. I hinted about those possible performance problems when
> > reviewing the original PR, so I'd like to see if I can investigate a
> > different way of achieving the transformation. I think the main
> > performance cost comes from using the following pattern:
> > read file -> parse using JAXP -> transform using TRAX -> write to stream
> > read stream -> parse using XPP3
> > The first step is performed in a separate thread and the output written
> to
> > a pipe stream which is used as the input of the usual pom parser. This
> > double parsing step, in addition to using the JAXP / TRAX api, which is
> not
> > the fastest one, comes at a heavy cost.
> >
> > I see two ways to solve the problem:
> > * refactor the build/consumer feature to use a different API so that the
> > parsing can be done in a single step (this would mean defining an
> XmlFilter
> > interface to do the filtering and wrapping it inside an XmlPullParser)
> > * get rid of the Xpp3 implementation and use the more common Stax api
> > which already defines filters
> >
> > The second option has some drawbacks though: all the plugin configuration
> > done using Xpp3Dom would not work anymore, so this is a very big and
> > incompatible change.
> >
> > I'm thus willing to investigate the first option and see what can be
> done.
> > If there's a consensus, I'll start working on a POC about the api /
> filters
> > and will get back to this list with some more information.
> >
> > --
> > 
> > Guillaume Nodet
> >
>

Re: Maven 4 performances problems

[Enrico Olivelli]

Il giorno gio 1 lug 2021 alle ore 12:27 Robert Scholte 
ha scritto:

> Should we postpone the alpha-1 release because of this?
> For me the most important reason for alpha-1 is to get confirmation that
> builds won't be broken due to build/consumer.
>

100% agreed
it is an ALPHA and there are many cool features, it is worth to give it to
the users and get feedback

my two cents
Enrico


> But if users simply look at buildtime and due to some slower result don't
> care for the other changes, then we shouldn't do this release now.


> Robert
>
>
>
> On 1-7-2021 11:20:17, Guillaume Nodet  wrote:
> I've been running a few tests to measure performances.
> This simplistic test looks like running the following command in a loop and
> measure the execution time. This is done on a quite big project so that a
> bunch of pom files are actually read.
>
> for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
> -Dmaven.experimental.buildconsumer=true help:evaluate
> -Dexpression=java.io.tmpdir -DforceStdout -q ; done
>
> The average results are the following:
> Maven 4 with build/consumer: 28,40s
> Maven 4 w/out build/consumer: 23,43s
> Maven 3: 21,54s
>
> I find the 20% performance loss of the build/consumer feature quite
> problematic. I hinted about those possible performance problems when
> reviewing the original PR, so I'd like to see if I can investigate a
> different way of achieving the transformation. I think the main
> performance cost comes from using the following pattern:
> read file -> parse using JAXP -> transform using TRAX -> write to stream
> read stream -> parse using XPP3
> The first step is performed in a separate thread and the output written to
> a pipe stream which is used as the input of the usual pom parser. This
> double parsing step, in addition to using the JAXP / TRAX api, which is not
> the fastest one, comes at a heavy cost.
>
> I see two ways to solve the problem:
> * refactor the build/consumer feature to use a different API so that the
> parsing can be done in a single step (this would mean defining an XmlFilter
> interface to do the filtering and wrapping it inside an XmlPullParser)
> * get rid of the Xpp3 implementation and use the more common Stax api
> which already defines filters
>
> The second option has some drawbacks though: all the plugin configuration
> done using Xpp3Dom would not work anymore, so this is a very big and
> incompatible change.
>
> I'm thus willing to investigate the first option and see what can be done.
> If there's a consensus, I'll start working on a POC about the api / filters
> and will get back to this list with some more information.
>
> --
> 
> Guillaume Nodet
>

Re: Maven 4 performances problems

[Robert Scholte]

Should we postpone the alpha-1 release because of this?
For me the most important reason for alpha-1 is to get confirmation that builds 
won't be broken due to build/consumer.
But if users simply look at buildtime and due to some slower result don't care 
for the other changes, then we shouldn't do this release now.

Robert



On 1-7-2021 11:20:17, Guillaume Nodet  wrote:
I've been running a few tests to measure performances.
This simplistic test looks like running the following command in a loop and
measure the execution time. This is done on a quite big project so that a
bunch of pom files are actually read.

for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
-Dmaven.experimental.buildconsumer=true help:evaluate
-Dexpression=java.io.tmpdir -DforceStdout -q ; done

The average results are the following:
Maven 4 with build/consumer: 28,40s
Maven 4 w/out build/consumer: 23,43s
Maven 3: 21,54s

I find the 20% performance loss of the build/consumer feature quite
problematic. I hinted about those possible performance problems when
reviewing the original PR, so I'd like to see if I can investigate a
different way of achieving the transformation. I think the main
performance cost comes from using the following pattern:
read file -> parse using JAXP -> transform using TRAX -> write to stream
read stream -> parse using XPP3
The first step is performed in a separate thread and the output written to
a pipe stream which is used as the input of the usual pom parser. This
double parsing step, in addition to using the JAXP / TRAX api, which is not
the fastest one, comes at a heavy cost.

I see two ways to solve the problem:
* refactor the build/consumer feature to use a different API so that the
parsing can be done in a single step (this would mean defining an XmlFilter
interface to do the filtering and wrapping it inside an XmlPullParser)
* get rid of the Xpp3 implementation and use the more common Stax api
which already defines filters

The second option has some drawbacks though: all the plugin configuration
done using Xpp3Dom would not work anymore, so this is a very big and
incompatible change.

I'm thus willing to investigate the first option and see what can be done.
If there's a consensus, I'll start working on a POC about the api / filters
and will get back to this list with some more information.

--

Guillaume Nodet

Maven 4 performances problems

[Guillaume Nodet]

I've been running a few tests to measure performances.
This simplistic test looks like running the following command in a loop and
measure the execution time.  This is done on a quite big project so that a
bunch of pom files are actually read.

for i in 1 2 3 4 5 6 7 8 9 10 ; do time $MAVEN_HOME/bin/mvn -DskipTests
-Dmaven.experimental.buildconsumer=true help:evaluate
-Dexpression=java.io.tmpdir -DforceStdout -q ; done

The average results are the following:
   Maven 4 with build/consumer:  28,40s
   Maven 4 w/out build/consumer: 23,43s
   Maven 3:  21,54s

I find the 20% performance loss of the build/consumer feature quite
problematic.  I hinted about those possible performance problems when
reviewing the original PR, so I'd like to see if I can investigate a
different way of achieving the transformation.  I think the main
performance cost comes from using the following pattern:
  read file -> parse using JAXP -> transform using TRAX -> write to stream
  read stream -> parse using XPP3
The first step is performed in a separate thread and the output written to
a pipe stream which is used as the input of the usual pom parser.  This
double parsing step, in addition to using the JAXP / TRAX api, which is not
the fastest one, comes at a heavy cost.

I see two ways to solve the problem:
  * refactor the build/consumer feature to use a different API so that the
parsing can be done in a single step (this would mean defining an XmlFilter
interface to do the filtering and wrapping it inside an XmlPullParser)
  * get rid of the Xpp3 implementation and use the more common Stax api
which already defines filters

The second option has some drawbacks though: all the plugin configuration
done using Xpp3Dom would not work anymore, so this is a very big and
incompatible change.

I'm thus willing to investigate the first option and see what can be done.
If there's a consensus, I'll start working on a POC about the api / filters
and will get back to this list with some more information.

-- 

Guillaume Nodet

[GitHub] [maven-site-plugin] dependabot[bot] commented on pull request #56: Bump doxiaSitetoolsVersion from 1.9.2 to 1.10

[GitBox]

dependabot[bot] commented on pull request #56:
URL: https://github.com/apache/maven-site-plugin/pull/56#issuecomment-871988731


   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. You can also ignore all major, minor, or patch 
releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site-plugin] asfgit closed pull request #56: Bump doxiaSitetoolsVersion from 1.9.2 to 1.10

[GitBox]

asfgit closed pull request #56:
URL: https://github.com/apache/maven-site-plugin/pull/56


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site-plugin] asfgit closed pull request #55: Bump doxiaVersion from 1.9.1 to 1.10

[GitBox]

asfgit closed pull request #55:
URL: https://github.com/apache/maven-site-plugin/pull/55


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[GitHub] [maven-site-plugin] dependabot[bot] commented on pull request #55: Bump doxiaVersion from 1.9.1 to 1.10

[GitBox]

dependabot[bot] commented on pull request #55:
URL: https://github.com/apache/maven-site-plugin/pull/55#issuecomment-871988521


   OK, I won't notify you again about this release, but will get in touch when 
a new version is available. You can also ignore all major, minor, or patch 
releases for a dependency by adding an [`ignore` 
condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore)
 with the desired `update_types` to your config file.
   
   If you change your mind, just re-open this PR and I'll resolve any conflicts 
on it.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org