[jira] [Commented] (MRESOLVER-394) Provide "static" supplier for RepositorySystemSession
[
https://issues.apache.org/jira/browse/MRESOLVER-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750646#comment-17750646
]
Grzegorz Grzybek commented on MRESOLVER-394:
[~cstamas] good points and I fully agree that you have wider view on this than
me. I was looking only from consistency perspective.
I see that Maven itself creates the session via {{}} only in one place:
{code:java}
org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory.newRepositorySession()
{code}
this factory is a {{@Named}} bean from maven-core
(/META-INF/sisu/javax.inject.Named).
So I guess I was too quick and narrow-minded here. Let's close as won't fix.
Thanks for explanation!
> Provide "static" supplier for RepositorySystemSession
> -
>
> Key: MRESOLVER-394
> URL: https://issues.apache.org/jira/browse/MRESOLVER-394
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Grzegorz Grzybek
>Priority: Major
> Fix For: 1.9.15
>
>
> Similar to MRESOLVER-387, but for DefaultRepositorySystemSession, so we can
> also deprecate
> {{org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-394) Provide "static" supplier for RepositorySystemSession
[
https://issues.apache.org/jira/browse/MRESOLVER-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750646#comment-17750646
]
Grzegorz Grzybek edited comment on MRESOLVER-394 at 8/3/23 9:02 AM:
[~cstamas] good points and I fully agree that you have wider view on this than
me. I was looking only from consistency perspective.
I see that Maven itself creates the session via {{}} only in one place:
{code:java}
org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory.newRepositorySession()
{code}
this factory is a {{@Named}} bean from maven-core
(/META-INF/sisu/javax.inject.Named).
So I guess I was too quick and narrow-minded here. Let's close as won't fix.
Thanks for explanation!
(I don't have permissions to close)
was (Author: gzres):
[~cstamas] good points and I fully agree that you have wider view on this than
me. I was looking only from consistency perspective.
I see that Maven itself creates the session via {{}} only in one place:
{code:java}
org.apache.maven.internal.aether.DefaultRepositorySystemSessionFactory.newRepositorySession()
{code}
this factory is a {{@Named}} bean from maven-core
(/META-INF/sisu/javax.inject.Named).
So I guess I was too quick and narrow-minded here. Let's close as won't fix.
Thanks for explanation!
> Provide "static" supplier for RepositorySystemSession
> -
>
> Key: MRESOLVER-394
> URL: https://issues.apache.org/jira/browse/MRESOLVER-394
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Grzegorz Grzybek
>Priority: Major
> Fix For: 1.9.15
>
>
> Similar to MRESOLVER-387, but for DefaultRepositorySystemSession, so we can
> also deprecate
> {{org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-394) Provide "static" supplier for RepositorySystemSession
[
https://issues.apache.org/jira/browse/MRESOLVER-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750332#comment-17750332
]
Grzegorz Grzybek commented on MRESOLVER-394:
I'll provide a PR tomorrow.
> Provide "static" supplier for RepositorySystemSession
> -
>
> Key: MRESOLVER-394
> URL: https://issues.apache.org/jira/browse/MRESOLVER-394
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Grzegorz Grzybek
>Priority: Major
> Fix For: 1.9.15
>
>
> Similar to MRESOLVER-387, but for DefaultRepositorySystemSession, so we can
> also deprecate
> {{org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-394) Provide "static" supplier for RepositorySystemSession
Grzegorz Grzybek created MRESOLVER-394:
--
Summary: Provide "static" supplier for RepositorySystemSession
Key: MRESOLVER-394
URL: https://issues.apache.org/jira/browse/MRESOLVER-394
Project: Maven Resolver
Issue Type: Improvement
Components: Resolver
Reporter: Grzegorz Grzybek
Similar to MRESOLVER-387, but for DefaultRepositorySystemSession, so we can
also deprecate
{{org.apache.maven.repository.internal.MavenRepositorySystemUtils.newSession()}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750201#comment-17750201 ] Grzegorz Grzybek commented on MRESOLVER-387: Checking it now with Camel 4 > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-387) Provide "static" supplier for RepositorySystem
[ https://issues.apache.org/jira/browse/MRESOLVER-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17749868#comment-17749868 ] Grzegorz Grzybek commented on MRESOLVER-387: Sure - but tomorrow, ok? :) > Provide "static" supplier for RepositorySystem > -- > > Key: MRESOLVER-387 > URL: https://issues.apache.org/jira/browse/MRESOLVER-387 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.15 > > > To provide SL replacement. > Something like this > https://github.com/maveniverse/mima/blob/main/runtime/standalone-static/src/main/java/eu/maveniverse/maven/mima/runtime/standalonestatic/RepositorySystemSupplier.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-157) Get rid of ServiceLocator in Resolver
[ https://issues.apache.org/jira/browse/MRESOLVER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747024#comment-17747024 ] Grzegorz Grzybek commented on MRESOLVER-157: bq. Yup, and yup, that's what I meant by "move this class from MIMA to resolver" :facepalm: - I read the opposite ;) > Get rid of ServiceLocator in Resolver > - > > Key: MRESOLVER-157 > URL: https://issues.apache.org/jira/browse/MRESOLVER-157 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 1.10.0 > > > maven-resolver currently supports: > * ServiceLocator (deprecated as of 1.7.0 see MRESOLVER-160) > * "vanilla" Guice (provides a module) > * DI using Sisu, as used in Maven > IMO, it makes not much sense to support 3 vastly different "DI"s (in quotes > as ServiceLocator is really just a dumb factory pattern). > Not only just complicates the code base, makes changes error prone at least, > yields for "exceptions" (this or that will never work with it, as seen with > SyncContext), and, for me most importantly, prevents proper constructor > initialization and validation of components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-157) Get rid of ServiceLocator in Resolver
[
https://issues.apache.org/jira/browse/MRESOLVER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747020#comment-17747020
]
Grzegorz Grzybek commented on MRESOLVER-157:
So if I understand correctly,
{{eu.maveniverse.maven.mima.runtime.standalonestatic.RepositorySystemSupplier}}
(I must admit - that's a really nice FQCN :)). is no-service-locator and
direct-dependency-injection way to obtain
{{org.eclipse.aether.internal.impl.DefaultRepositorySystem}}?
It suits me - Maybe it could be also added to the resolver itself? :)
> Get rid of ServiceLocator in Resolver
> -
>
> Key: MRESOLVER-157
> URL: https://issues.apache.org/jira/browse/MRESOLVER-157
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 1.10.0
>
>
> maven-resolver currently supports:
> * ServiceLocator (deprecated as of 1.7.0 see MRESOLVER-160)
> * "vanilla" Guice (provides a module)
> * DI using Sisu, as used in Maven
> IMO, it makes not much sense to support 3 vastly different "DI"s (in quotes
> as ServiceLocator is really just a dumb factory pattern).
> Not only just complicates the code base, makes changes error prone at least,
> yields for "exceptions" (this or that will never work with it, as seen with
> SyncContext), and, for me most importantly, prevents proper constructor
> initialization and validation of components.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7741) Add more information when using -Dmaven.repo.local.recordReverseTree=true
[
https://issues.apache.org/jira/browse/MNG-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17701086#comment-17701086
]
Grzegorz Grzybek commented on MNG-7741:
---
PR: https://github.com/apache/maven/pull/1058
cc: [~cstamas], [~gnodet] - I'd appreciate if you have a look at this one. I
can adjust the code, naming, etc. as you wish.
> Add more information when using -Dmaven.repo.local.recordReverseTree=true
> -
>
> Key: MNG-7741
> URL: https://issues.apache.org/jira/browse/MNG-7741
> Project: Maven
> Issue Type: Improvement
>Reporter: Grzegorz Grzybek
>Priority: Major
>
> I much appreciate adding {{-Dmaven.repo.local.recordReverseTree=true}} option
> to Maven Core (supported by new resolver features).
> After initial idea, I added few more options to
> https://github.com/grgrzybek/tracking-maven-extension and I'd be happy to see
> these in {{org.apache.maven.internal.aether.ReverseTreeRepositoryListener}}.
> I did some experiments locally and I have improvement ready which:
> h5. tracks information about missing dependencies
> when using non-existing dependency (like {{org.slf4j:slf4j-apix}}), I can see
> {{~/.m2/repository/org/slf4j/slf4j-apix/1.7.36/.tracking/grgr_simplest_jar_1.0.miss}}
> file with:
> {noformat}
> org.slf4j:slf4j-apix:pom:1.7.36
> org.slf4j:slf4j-apix:jar:1.7.36 (compile) (project)
> grgr:simplest:jar:1.0 (project)
> Configured repositories:
> - central : https://repo.maven.apache.org/maven2
> {noformat}
> h5. tracks information about actual repository information (in
> {{_remote.repositories}} we have only the ID)
> For example
> {noformat}
> org.apache.maven.plugins:maven-compiler-plugin:pom:3.10.1
> org.apache.maven.plugins:maven-compiler-plugin:3.10.1
> org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
> Repository: central (https://repo.maven.apache.org/maven2, default, releases)
> {noformat}
> h5. tracks information where only POM is downloaded
> For example with
> {{~/.m2/repository/com/google/guava/guava-parent/16.0.1/.tracking/org.apache.maven.plugins_maven-surefire-plugin_jar_3.0.0.dep}}:
> {noformat}
> com.google.guava:guava-parent:pom:16.0.1
> com.google.guava:guava:jar:16.0.1 (compile) (plugin)
> org.sonatype.sisu:sisu-guice:jar:no_aop:3.2.3 (compile) (plugin)
> org.apache.maven:maven-core:jar:3.2.5 (provided) (plugin)
> org.apache.maven.shared:maven-common-artifact-filters:jar:3.1.1
> (compile) (plugin)
> org.apache.maven.surefire:maven-surefire-common:jar:3.0.0 (compile)
> (plugin)
> org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0 ()
> (plugin)
> Repository: central (https://repo.maven.apache.org/maven2, default, releases)
> {noformat}
> h5. tracks reverse trees originating from plugins (also implicit ones)
> {noformat}
> org.apache:apache:pom:26
> org.apache.maven.plugins:maven-resources-plugin:3.3.0
> org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
> Repository: central (https://repo.maven.apache.org/maven2, default, releases)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7741) Add more information when using -Dmaven.repo.local.recordReverseTree=true
[
https://issues.apache.org/jira/browse/MNG-7741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-7741:
--
Description:
I much appreciate adding {{-Dmaven.repo.local.recordReverseTree=true}} option
to Maven Core (supported by new resolver features).
After initial idea, I added few more options to
https://github.com/grgrzybek/tracking-maven-extension and I'd be happy to see
these in {{org.apache.maven.internal.aether.ReverseTreeRepositoryListener}}.
I did some experiments locally and I have improvement ready which:
h5. tracks information about missing dependencies
when using non-existing dependency (like {{org.slf4j:slf4j-apix}}), I can see
{{~/.m2/repository/org/slf4j/slf4j-apix/1.7.36/.tracking/grgr_simplest_jar_1.0.miss}}
file with:
{noformat}
org.slf4j:slf4j-apix:pom:1.7.36
org.slf4j:slf4j-apix:jar:1.7.36 (compile) (project)
grgr:simplest:jar:1.0 (project)
Configured repositories:
- central : https://repo.maven.apache.org/maven2
{noformat}
h5. tracks information about actual repository information (in
{{_remote.repositories}} we have only the ID)
For example
{noformat}
org.apache.maven.plugins:maven-compiler-plugin:pom:3.10.1
org.apache.maven.plugins:maven-compiler-plugin:3.10.1
org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
h5. tracks information where only POM is downloaded
For example with
{{~/.m2/repository/com/google/guava/guava-parent/16.0.1/.tracking/org.apache.maven.plugins_maven-surefire-plugin_jar_3.0.0.dep}}:
{noformat}
com.google.guava:guava-parent:pom:16.0.1
com.google.guava:guava:jar:16.0.1 (compile) (plugin)
org.sonatype.sisu:sisu-guice:jar:no_aop:3.2.3 (compile) (plugin)
org.apache.maven:maven-core:jar:3.2.5 (provided) (plugin)
org.apache.maven.shared:maven-common-artifact-filters:jar:3.1.1
(compile) (plugin)
org.apache.maven.surefire:maven-surefire-common:jar:3.0.0 (compile)
(plugin)
org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0 () (plugin)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
h5. tracks reverse trees originating from plugins (also implicit ones)
{noformat}
org.apache:apache:pom:26
org.apache.maven.plugins:maven-resources-plugin:3.3.0
org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
was:
I much appreciate adding {{-Dmaven.repo.local.recordReverseTree=true}} option
to Maven Core (supported by new resolver features).
After initial idea, I added few more options to
https://github.com/grgrzybek/tracking-maven-extension and I'd be happy to see
these in {{org.apache.maven.internal.aether.ReverseTreeRepositoryListener}}.
I did some experiments locally and I have improvement ready which:
h5. tracks information about missing dependencies
when using non-existing dependency (like {{org.slf4j:slf4j-apix}}), I can see
{{~/.m2/repository/org/slf4j/slf4j-apix/1.7.36/.tracking/grgr_simplest_jar_1.0.miss}}
file with:
{noformat}
org.slf4j:slf4j-apix:pom:1.7.36
org.slf4j:slf4j-apix:jar:1.7.36 (compile) (project)
grgr:simplest:jar:1.0 (project)
Configured repositories:
- central : https://repo.maven.apache.org/maven2
{noformat}
h5. tracks information about actual repository information (in
{{_remote.repositories}} we have only the ID)
For example
{noformat}
org.apache.maven.plugins:maven-compiler-plugin:pom:3.10.1
org.apache.maven.plugins:maven-compiler-plugin:3.10.1
org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
h5. tracks information where only POM is downloaded
For example with
{{!/.m2/repository/com/google/guava/guava-parent/16.0.1/.tracking/org.apache.maven.plugins_maven-surefire-plugin_jar_3.0.0.dep}}:
{noformat}
com.google.guava:guava-parent:pom:16.0.1
com.google.guava:guava:jar:16.0.1 (compile) (plugin)
org.sonatype.sisu:sisu-guice:jar:no_aop:3.2.3 (compile) (plugin)
org.apache.maven:maven-core:jar:3.2.5 (provided) (plugin)
org.apache.maven.shared:maven-common-artifact-filters:jar:3.1.1
(compile) (plugin)
org.apache.maven.surefire:maven-surefire-common:jar:3.0.0 (compile)
(plugin)
org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0 () (plugin)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
h5. tracks reverse trees originating from plugins (also implicit ones)
{noformat}
org.apache:apache:pom:26
org.apache.maven.plugins:maven-resources-plugin:3.3.0
org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{
[jira] [Created] (MNG-7741) Add more information when using -Dmaven.repo.local.recordReverseTree=true
Grzegorz Grzybek created MNG-7741:
-
Summary: Add more information when using
-Dmaven.repo.local.recordReverseTree=true
Key: MNG-7741
URL: https://issues.apache.org/jira/browse/MNG-7741
Project: Maven
Issue Type: Improvement
Reporter: Grzegorz Grzybek
I much appreciate adding {{-Dmaven.repo.local.recordReverseTree=true}} option
to Maven Core (supported by new resolver features).
After initial idea, I added few more options to
https://github.com/grgrzybek/tracking-maven-extension and I'd be happy to see
these in {{org.apache.maven.internal.aether.ReverseTreeRepositoryListener}}.
I did some experiments locally and I have improvement ready which:
h5. tracks information about missing dependencies
when using non-existing dependency (like {{org.slf4j:slf4j-apix}}), I can see
{{~/.m2/repository/org/slf4j/slf4j-apix/1.7.36/.tracking/grgr_simplest_jar_1.0.miss}}
file with:
{noformat}
org.slf4j:slf4j-apix:pom:1.7.36
org.slf4j:slf4j-apix:jar:1.7.36 (compile) (project)
grgr:simplest:jar:1.0 (project)
Configured repositories:
- central : https://repo.maven.apache.org/maven2
{noformat}
h5. tracks information about actual repository information (in
{{_remote.repositories}} we have only the ID)
For example
{noformat}
org.apache.maven.plugins:maven-compiler-plugin:pom:3.10.1
org.apache.maven.plugins:maven-compiler-plugin:3.10.1
org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
h5. tracks information where only POM is downloaded
For example with
{{!/.m2/repository/com/google/guava/guava-parent/16.0.1/.tracking/org.apache.maven.plugins_maven-surefire-plugin_jar_3.0.0.dep}}:
{noformat}
com.google.guava:guava-parent:pom:16.0.1
com.google.guava:guava:jar:16.0.1 (compile) (plugin)
org.sonatype.sisu:sisu-guice:jar:no_aop:3.2.3 (compile) (plugin)
org.apache.maven:maven-core:jar:3.2.5 (provided) (plugin)
org.apache.maven.shared:maven-common-artifact-filters:jar:3.1.1
(compile) (plugin)
org.apache.maven.surefire:maven-surefire-common:jar:3.0.0 (compile)
(plugin)
org.apache.maven.plugins:maven-surefire-plugin:jar:3.0.0 () (plugin)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
h5. tracks reverse trees originating from plugins (also implicit ones)
{noformat}
org.apache:apache:pom:26
org.apache.maven.plugins:maven-resources-plugin:3.3.0
org.apache.maven:maven-core:3.9.1:default-lifecycle-bindings (implicit)
Repository: central (https://repo.maven.apache.org/maven2, default, releases)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-157) Get rid of ServiceLocator in Resolver
[
https://issues.apache.org/jira/browse/MRESOLVER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612236#comment-17612236
]
Grzegorz Grzybek edited comment on MRESOLVER-157 at 10/3/22 10:02 AM:
--
I'm checking CAMEL-18555 - to replace shrinkwrap-resolver (which uses
{{org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.ShrinkWrapResolverServiceLocator}}
implementation of now deprecated
{{org.eclipse.aether.spi.locator.ServiceLocator}}).
Checking [this
comment|https://github.com/ops4j/org.ops4j.pax.url/issues/397#issuecomment-915116644]
from [~cstamas] I feel there still should be a dumb, reflection/DI free way to
configure a graph of objects. In theory it is possible, because I can:
# instantiate {{org.eclipse.aether.internal.impl.DefaultRepositorySystem}}
# instantiate {{org.apache.maven.repository.internal.DefaultVersionResolver}}
# call
{{org.eclipse.aether.internal.impl.DefaultRepositorySystem#setVersionResolver()}}
on the first passing the second
However such dumb (but google code free) solution requires public constructors
and setters. While {{DefaultRepositorySystem}}'s setter is fine
(maven-resolver-impl-1.8.2):
{code:java}
public DefaultRepositorySystem()
{
// enables default constructor
}
{code}
It's more problematic in
{{org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector}}:
{code:java}
/**
* Default ctor for SL.
*
* @deprecated Will be dropped once SL gone.
*/
@Deprecated
public DfDependencyCollector()
{
// enables default constructor
}
{code}
If/when the no-arg constructor is dropped, I'll be left with package-private:
{code:java}
@Inject
DfDependencyCollector( RemoteRepositoryManager remoteRepositoryManager,
ArtifactDescriptorReader artifactDescriptorReader,
VersionRangeResolver versionRangeResolver )
{
super( remoteRepositoryManager, artifactDescriptorReader,
versionRangeResolver );
}
{code}
So back to sisu/guice or reflection ({{setAccessible()}} code (or shadowing the
packages)).
I think it'd be good to keep the injection points (constructors, setters)
public. WDYT?
was (Author: gzres):
I'm checking CAMEL-18555 - to replace shrinkwrap-resolver (which uses
{{org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.ShrinkWrapResolverServiceLocator}}
implementation of now deprecated
{{org.eclipse.aether.spi.locator.ServiceLocator}}).
Checking [this
comment|https://github.com/ops4j/org.ops4j.pax.url/issues/397#issuecomment-915116644]
from [~cstamas] I feel there still should be a dumb, reflection/DI free way to
configure a graph of objects. In theory it is possible, because I can:
# instantiate {{org.eclipse.aether.internal.impl.DefaultRepositorySystem}}
# instantiate {{org.apache.maven.repository.internal.DefaultVersionResolver}}
# call
{{org.eclipse.aether.internal.impl.DefaultRepositorySystem#setVersionResolver()}}
on the first passing the second
However such dumb (but google code free) solution requires public constructors
and setters. While {{DefaultRepositorySystem}}'s setter is fine
(maven-resolver-impl-1.8.2):
{code:java}
public DefaultRepositorySystem()
{
// enables default constructor
}
{code}
It's more problematic in
{{org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector}}:
{code:java}
/**
* Default ctor for SL.
*
* @deprecated Will be dropped once SL gone.
*/
@Deprecated
public DfDependencyCollector()
{
// enables default constructor
}
{code}
If/when the no-arg constructor is dropped, I'll be left with package-private:
{code:java}
@Inject
DfDependencyCollector( RemoteRepositoryManager remoteRepositoryManager,
ArtifactDescriptorReader artifactDescriptorReader,
VersionRangeResolver versionRangeResolver )
{
super( remoteRepositoryManager, artifactDescriptorReader,
versionRangeResolver );
}
{code}
So back to sisu/guice or reflection ({{setAccessible()}} code (or shadowing the
packages).
I think it'd be good to keep the injection points (constructors, setters)
public. WDYT?
> Get rid of ServiceLocator in Resolver
> -
>
> Key: MRESOLVER-157
> URL: https://issues.apache.org/jira/browse/MRESOLVER-157
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamás Cservenák
>Priority: Major
>
> maven-resolver currently supports:
> * ServiceLocator (deprecated as of 1.7.0 see MRESOLVER-160)
> * "vanilla" Guice (provides a module)
> * DI using Sisu, as used in Maven
> IMO, it makes not much sense to support 3 vastly different "DI"s (in quotes
> as ServiceLocator is really just a dumb factory pattern).
> Not only just complicates the code base, makes changes error prone at least,
> yields for "exceptions" (this or that will never work with it,
[jira] [Commented] (MRESOLVER-157) Get rid of ServiceLocator in Resolver
[
https://issues.apache.org/jira/browse/MRESOLVER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612236#comment-17612236
]
Grzegorz Grzybek commented on MRESOLVER-157:
I'm checking CAMEL-18555 - to replace shrinkwrap-resolver (which uses
{{org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.ShrinkWrapResolverServiceLocator}}
implementation of now deprecated
{{org.eclipse.aether.spi.locator.ServiceLocator}}).
Checking [this
comment|https://github.com/ops4j/org.ops4j.pax.url/issues/397#issuecomment-915116644]
from [~cstamas] I feel there still should be a dumb, reflection/DI free way to
configure a graph of objects. In theory it is possible, because I can:
# instantiate {{org.eclipse.aether.internal.impl.DefaultRepositorySystem}}
# instantiate {{org.apache.maven.repository.internal.DefaultVersionResolver}}
# call
{{org.eclipse.aether.internal.impl.DefaultRepositorySystem#setVersionResolver()}}
on the first passing the second
However such dumb (but google code free) solution requires public constructors
and setters. While {{DefaultRepositorySystem}}'s setter is fine
(maven-resolver-impl-1.8.2):
{code:java}
public DefaultRepositorySystem()
{
// enables default constructor
}
{code}
It's more problematic in
{{org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector}}:
{code:java}
/**
* Default ctor for SL.
*
* @deprecated Will be dropped once SL gone.
*/
@Deprecated
public DfDependencyCollector()
{
// enables default constructor
}
{code}
If/when the no-arg constructor is dropped, I'll be left with package-private:
{code:java}
@Inject
DfDependencyCollector( RemoteRepositoryManager remoteRepositoryManager,
ArtifactDescriptorReader artifactDescriptorReader,
VersionRangeResolver versionRangeResolver )
{
super( remoteRepositoryManager, artifactDescriptorReader,
versionRangeResolver );
}
{code}
So back to sisu/guice or reflection ({{setAccessible()}} code (or shadowing the
packages).
I think it'd be good to keep the injection points (constructors, setters)
public. WDYT?
> Get rid of ServiceLocator in Resolver
> -
>
> Key: MRESOLVER-157
> URL: https://issues.apache.org/jira/browse/MRESOLVER-157
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamás Cservenák
>Priority: Major
>
> maven-resolver currently supports:
> * ServiceLocator (deprecated as of 1.7.0 see MRESOLVER-160)
> * "vanilla" Guice (provides a module)
> * DI using Sisu, as used in Maven
> IMO, it makes not much sense to support 3 vastly different "DI"s (in quotes
> as ServiceLocator is really just a dumb factory pattern).
> Not only just complicates the code base, makes changes error prone at least,
> yields for "exceptions" (this or that will never work with it, as seen with
> SyncContext), and, for me most importantly, prevents proper constructor
> initialization and validation of components.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-1187) JUnit4 Provider created unnecessary Runner instance
[ https://issues.apache.org/jira/browse/SUREFIRE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972466#comment-14972466 ] Grzegorz Grzybek commented on SUREFIRE-1187: Thanks - it's working great! > JUnit4 Provider created unnecessary Runner instance > --- > > Key: SUREFIRE-1187 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1187 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.19 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.1 > > > We should think of better approach of creating a new instance of Description > in method createTestsDescription(). > This instantiates extra JUnit Runner object > runNotifier.fireTestRunStarted( createTestsDescription() ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1187) JUnit4 Provider created unnecessary Runner instance
[ https://issues.apache.org/jira/browse/SUREFIRE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14970924#comment-14970924 ] Grzegorz Grzybek commented on SUREFIRE-1187: Thanks for looking into it! > JUnit4 Provider created unnecessary Runner instance > --- > > Key: SUREFIRE-1187 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1187 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.19 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.1 > > > We should think of better approach of creating a new instance of Description > in method createTestsDescription(). > This instantiates extra JUnit Runner object > runNotifier.fireTestRunStarted( createTestsDescription() ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1095) NPE in RunListener
[
https://issues.apache.org/jira/browse/SUREFIRE-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14969584#comment-14969584
]
Grzegorz Grzybek commented on SUREFIRE-1095:
Thanks for hint - it worked with:
{code:xml}
maven-surefire-plugin
2.19
org.apache.maven.surefire
surefire-junit47
2.19
{code}
Description is not important for me - but I guess it was introduced on purpose.
Thanks for help.
> NPE in RunListener
> --
>
> Key: SUREFIRE-1095
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1095
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.17
> Environment: Tested on Mac, using Maven 3.1, Java 7
>Reporter: Andrea Arcuri
>Assignee: Tibor Digana
> Fix For: 2.18
>
>
> In the surefire plugin, it is possible to specify one or more RunListener
> when running tests with JUnit.
> However, it does not look like the listener is properly called by the plugin.
> In particular, there is a problem with the method:
> public void testRunStarted(Description description)
> it's javadoc at
> http://junit.sourceforge.net/javadoc/org/junit/runner/notification/RunListener.html#testRunStarted%28org.junit.runner.Description%29
> states:
> "Parameters:
> description - describes the tests to be run "
> however, in all maven projects I tried ("mvn test"), the surefire plugin
> seems like passing a null reference instead of a Description instance that
> "describes the tests to be run "
> Note: other methods in the RunListener I tested seems fine (i.e., they get a
> valid Description object as input)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1095) NPE in RunListener
[
https://issues.apache.org/jira/browse/SUREFIRE-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968854#comment-14968854
]
Grzegorz Grzybek commented on SUREFIRE-1095:
[This change|https://github.com/apache/maven-surefire/commit/4df65165] in
{{org/apache/maven/surefire/junit4/JUnit4Provider.java}}:
{noformat}
-runNotifer.fireTestRunStarted( null );
+runNotifier.fireTestRunStarted( createTestsDescription() );
{noformat}
introduces additional creation of runners:
{noformat}
"main@1" prio=5 tid=0x1 nid=NA runnable
java.lang.Thread.State: RUNNABLE
at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:25)
at org.junit.runner.Computer.getRunner(Computer.java:40)
at org.junit.runner.Computer$1.runnerForClass(Computer.java:31)
at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at
org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:101)
at
org.junit.runners.model.RunnerBuilder.runners(RunnerBuilder.java:87)
at org.junit.runners.Suite.(Suite.java:81)
at org.junit.runner.Computer.getSuite(Computer.java:28)
at org.junit.runner.Request.classes(Request.java:75)
at org.junit.runner.Request.classes(Request.java:91)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.apache.maven.surefire.common.junit4.JUnit4Reflector.createRequest(JUnit4Reflector.java:67)
at
org.apache.maven.surefire.common.junit4.JUnit4ProviderUtil.createSuiteDescription(JUnit4ProviderUtil.java:111)
at
org.apache.maven.surefire.junit4.JUnit4Provider.createTestsDescription(JUnit4Provider.java:328)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:166)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:286)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:240)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
{noformat}
And in case of Arquillian runner (when runners are counted, and suite cleanup
is called only after the count drops to 0) we have problems because two runners
are started for a class, but only one is finished (see
https://issues.jboss.org/browse/ARQ-1940).
> NPE in RunListener
> --
>
> Key: SUREFIRE-1095
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1095
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.17
> Environment: Tested on Mac, using Maven 3.1, Java 7
>Reporter: Andrea Arcuri
>Assignee: Tibor Digana
> Fix For: 2.18
>
>
> In the surefire plugin, it is possible to specify one or more RunListener
> when running tests with JUnit.
> However, it does not look like the listener is properly called by the plugin.
> In particular, there is a problem with the method:
> public void testRunStarted(Description description)
> it's javadoc at
> http://junit.sourceforge.net/javadoc/org/junit/runner/notification/RunListener.html#testRunStarted%28org.junit.runner.Description%29
> states:
> "Parameters:
> description - describes the tests to be run "
> however, in all maven projects I tried ("mvn test"), the surefire plugin
> seems like passing a null reference instead of a Description instance that
> "describes the tests to be run "
> Note: other methods in the RunListener I tested seems fine (i.e., they get a
> valid Description object as input)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (SUREFIRE-1004) Enhance pattern/wildcard capabilities for dependenciesToScan to GAVT
[
https://jira.codehaus.org/browse/SUREFIRE-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353257#comment-353257
]
Grzegorz Grzybek commented on SUREFIRE-1004:
By the way - not only GAWT, but classifier too. one pom could produce JAR with
"tests" classifier which could be referenced in another POM's
{{dependenciesToScan}}.
> Enhance pattern/wildcard capabilities for dependenciesToScan to GAVT
>
>
> Key: SUREFIRE-1004
> URL: https://jira.codehaus.org/browse/SUREFIRE-1004
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.15
>Reporter: Andreas Gudian
>
> * Enhance what has been built with SUREFIRE-569 to support patterns as in
> maven-shade-plugin. Use maven-common-artifact-filters for that.
> * Add/Adapt documentation and examples.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-416) Lightweight HTTP Wagon doesn't set Proxy-Authorization header
[
https://jira.codehaus.org/browse/WAGON-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated WAGON-416:
---
Summary: Lightweight HTTP Wagon doesn't set Proxy-Authorization header
(was: Lightweight HTTP Wagon doesn't set Proxy-Authorization headers)
> Lightweight HTTP Wagon doesn't set Proxy-Authorization header
> -
>
> Key: WAGON-416
> URL: https://jira.codehaus.org/browse/WAGON-416
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
>Reporter: Grzegorz Grzybek
>
> When using
> {code:java}
> org.apache.maven.wagon.AbstractWagon#connect(org.apache.maven.wagon.repository.Repository,
> org.apache.maven.wagon.authentication.AuthenticationInfo,
> org.apache.maven.wagon.proxy.ProxyInfoProvider)
> {code}
> method (using {{ProxyInfoProvider}}) the {{proxyInfo}} field in Wagon isn't
> initialized. Then, when connecting to secure HTTP proxy,
> {{Proxy-Authorization}} header is not set.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-416) Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
[
https://jira.codehaus.org/browse/WAGON-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348786#comment-348786
]
Grzegorz Grzybek edited comment on WAGON-416 at 6/26/14 8:13 AM:
-
Pull Request ready: https://github.com/apache/maven-wagon/pull/11
The above pull request correctly sets the {{proxyInfo}} field in both
{{connect()}} variants (using ProxyInfo and ProxyInfoProvider). I've provided
also a test that shows the problem.
was (Author: gr.grzybek):
Pull Request ready: https://github.com/apache/maven-wagon/pull/11
> Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
> --
>
> Key: WAGON-416
> URL: https://jira.codehaus.org/browse/WAGON-416
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
>Reporter: Grzegorz Grzybek
>
> When using
> {code:java}
> org.apache.maven.wagon.AbstractWagon#connect(org.apache.maven.wagon.repository.Repository,
> org.apache.maven.wagon.authentication.AuthenticationInfo,
> org.apache.maven.wagon.proxy.ProxyInfoProvider)
> {code}
> method (using {{ProxyInfoProvider}}) the {{proxyInfo}} field in Wagon isn't
> initialized. Then, when connecting to secure HTTP proxy,
> {{Proxy-Authorization}} header is not set.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-416) Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
[
https://jira.codehaus.org/browse/WAGON-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348785#comment-348785
]
Grzegorz Grzybek commented on WAGON-416:
The {{connect()}} method with {{ProxyInfoProvider}} is used by e.g.,
{{org.sonatype.aether.connector.wagon.WagonRepositoryConnector#connectWagon()}}
> Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
> --
>
> Key: WAGON-416
> URL: https://jira.codehaus.org/browse/WAGON-416
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
>Reporter: Grzegorz Grzybek
>
> When using
> {code:java}
> org.apache.maven.wagon.AbstractWagon#connect(org.apache.maven.wagon.repository.Repository,
> org.apache.maven.wagon.authentication.AuthenticationInfo,
> org.apache.maven.wagon.proxy.ProxyInfoProvider)
> {code}
> method (using {{ProxyInfoProvider}}) the {{proxyInfo}} field in Wagon isn't
> initialized. Then, when connecting to secure HTTP proxy,
> {{Proxy-Authorization}} header is not set.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-416) Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
[
https://jira.codehaus.org/browse/WAGON-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348786#comment-348786
]
Grzegorz Grzybek commented on WAGON-416:
Pull Request ready: https://github.com/apache/maven-wagon/pull/11
> Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
> --
>
> Key: WAGON-416
> URL: https://jira.codehaus.org/browse/WAGON-416
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http-lightweight
>Reporter: Grzegorz Grzybek
>
> When using
> {code:java}
> org.apache.maven.wagon.AbstractWagon#connect(org.apache.maven.wagon.repository.Repository,
> org.apache.maven.wagon.authentication.AuthenticationInfo,
> org.apache.maven.wagon.proxy.ProxyInfoProvider)
> {code}
> method (using {{ProxyInfoProvider}}) the {{proxyInfo}} field in Wagon isn't
> initialized. Then, when connecting to secure HTTP proxy,
> {{Proxy-Authorization}} header is not set.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (WAGON-416) Lightweight HTTP Wagon doesn't set Proxy-Authorization headers
Grzegorz Grzybek created WAGON-416:
--
Summary: Lightweight HTTP Wagon doesn't set Proxy-Authorization
headers
Key: WAGON-416
URL: https://jira.codehaus.org/browse/WAGON-416
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http-lightweight
Reporter: Grzegorz Grzybek
When using
{code:java}
org.apache.maven.wagon.AbstractWagon#connect(org.apache.maven.wagon.repository.Repository,
org.apache.maven.wagon.authentication.AuthenticationInfo,
org.apache.maven.wagon.proxy.ProxyInfoProvider)
{code}
method (using {{ProxyInfoProvider}}) the {{proxyInfo}} field in Wagon isn't
initialized. Then, when connecting to secure HTTP proxy,
{{Proxy-Authorization}} header is not set.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348099#comment-348099
]
Grzegorz Grzybek commented on MNG-5594:
---
Thanks for looking into this.
Sure - with parallel build it's useless, but it helps when I have ~20 minutes
build and I want to look at the console to see how far I got.
Maybe it'd be good to think about something similar to log4j/logback's
"pattern" for this header line? (using placeholders for project's name,
artifactId, total, current, etc.)
regards
Grzegorz
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
>Priority: Minor
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-5594:
--
Priority: Minor (was: Major)
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
>Priority: Minor
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-5594:
--
Description:
While building long projects, containing hundreds of modules it would be nice
to see how far did we get.
For example, the build might look like this:
{noformat}
...
[INFO]
[INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
[INFO]
[INFO]
...
[INFO]
[INFO]
[INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
[INFO]
[INFO]
...
{noformat}
Please find attached a naive implementation here: [^project-progress.diff].
was:
While building long projects, containing hundreds of modules it would be nice
to see how far did we get.
For example, the build might look like this:
{noformat}
...
[INFO]
[INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
[INFO]
[INFO]
...
[INFO]
[INFO]
[INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
[INFO]
[INFO]
...
{noformat}
Please find attached a [naive implementation^project-progress.diff].
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a naive implementation here: [^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
[
https://jira.codehaus.org/browse/MNG-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated MNG-5594:
--
Attachment: project-progress.diff
> Show current/total project number in reactor during build
> -
>
> Key: MNG-5594
> URL: https://jira.codehaus.org/browse/MNG-5594
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.2.x
>Reporter: Grzegorz Grzybek
> Attachments: project-progress.diff
>
>
> While building long projects, containing hundreds of modules it would be nice
> to see how far did we get.
> For example, the build might look like this:
> {noformat}
> ...
> [INFO]
>
> [INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
> [INFO]
>
> [INFO]
> ...
> [INFO]
>
> [INFO]
>
> [INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
> [INFO]
>
> [INFO]
> ...
> {noformat}
> Please find attached a [naive implementation^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5594) Show current/total project number in reactor during build
Grzegorz Grzybek created MNG-5594:
-
Summary: Show current/total project number in reactor during build
Key: MNG-5594
URL: https://jira.codehaus.org/browse/MNG-5594
Project: Maven 2 & 3
Issue Type: Improvement
Components: General
Affects Versions: 3.2.x
Reporter: Grzegorz Grzybek
While building long projects, containing hundreds of modules it would be nice
to see how far did we get.
For example, the build might look like this:
{noformat}
...
[INFO]
[INFO] Building Maven Compat 3.2.2-SNAPSHOT (11/13)
[INFO]
[INFO]
...
[INFO]
[INFO]
[INFO] Building Maven Embedder 3.2.2-SNAPSHOT (12/13)
[INFO]
[INFO]
...
{noformat}
Please find attached a [naive implementation^project-progress.diff].
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-305) Filtering doesn't work as expected after switching from maven-filtering:1.0-beta-2 to maven-filtering:1.1
[
https://jira.codehaus.org/browse/MWAR-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=335380#comment-335380
]
Grzegorz Grzybek commented on MWAR-305:
---
Hello - any news on this issue?
> Filtering doesn't work as expected after switching from
> maven-filtering:1.0-beta-2 to maven-filtering:1.1
> --
>
> Key: MWAR-305
> URL: https://jira.codehaus.org/browse/MWAR-305
> Project: Maven WAR Plugin
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>Priority: Critical
>
> {{maven-filtering:1.0-beta-3}} introduced a setting
> {{org.apache.maven.shared.filtering.AbstractMavenFilteringRequest.injectProjectBuildFilters}}
> defaulted to {{false}}.
> While constructing {{defaultFilterWrappers}} in
> {{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(MavenProject,
> File)}} the {{MavenResourcesExecution}} is constructed.
> In {{maven-filtering:1.0-beta-2}} there's unconditional call:
> {code:java}
> loadProperties( filterProperties, mavenProject.getBuild().getFilters(),
> baseProps );
> {code}
> In {{maven-filtering:1.1}}+ there's conditional call:
> {code:java}
> if ( request.isInjectProjectBuildFilters() )
> {
> List buildFilters = new ArrayList(
> request.getMavenProject().getBuild().getFilters() );
> buildFilters.removeAll( request.getFileFilters() );
> loadProperties( filterProperties, buildFilters, baseProps );
> }
> {code}
> So my filters declared (as always) in:
> {code:xml}
>
>
> ../src/config/env/envX/config.properties
>
>
> {code}
> are *not taken into account* forcing me to set (configuration duplicate)
> [maven-war-plugin's
> filter|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#filters]
> property.
> Please change (in
> {{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp()}}) the line:
> {code:xml}
> mavenResourcesExecution.setFilters( filters );
> {code}
> to
> {code:xml}
> mavenResourcesExecution.setFilters( filters == null ?
> project.getBuild().getFilters() : filters );
> {code}
> regards
> Grzegorz Grzybek
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-301) webResources filtering not happening properly
[
https://jira.codehaus.org/browse/MWAR-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333881#comment-333881
]
Grzegorz Grzybek commented on MWAR-301:
---
Please see MWAR-305, where I've done some analysis. The problem occured when
upgrading to {{maven-filtering:1.0-beta-3}}.
regards
Grzegorz Grzybek
> webResources filtering not happening properly
> -
>
> Key: MWAR-301
> URL: https://jira.codehaus.org/browse/MWAR-301
> Project: Maven WAR Plugin
> Issue Type: Bug
> Components: filtering
>Affects Versions: 2.4
> Environment: Linux
>Reporter: Mukarram Baig
> Attachments: mwar-tester.zip
>
>
> I noticed that webResources were not getting filtered when I upgraded from
> 2.3 to 2.4 and could not find an open issue related to it, so letting you
> guys know if I am doing something incorrect that was working till 2.3 and got
> fixed in 2.4. I am attaching a sample project where a JS file was getting
> filtered properly when using 2.3 and not when using 2.4.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-293) Filtering doesn't work as expected after switching from maven-filtering:1.0-beta-2 to maven-filtering:1.1
[
https://jira.codehaus.org/browse/MSHARED-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek closed MSHARED-293.
Resolution: Not A Bug
Sorry! It was meant to be created at MWAR...
> Filtering doesn't work as expected after switching from
> maven-filtering:1.0-beta-2 to maven-filtering:1.1
> -
>
> Key: MSHARED-293
> URL: https://jira.codehaus.org/browse/MSHARED-293
> Project: Maven Shared Components
> Issue Type: Bug
>Reporter: Grzegorz Grzybek
>
> {{maven-filtering:1.0-beta-3}} introduced a setting
> {{org.apache.maven.shared.filtering.AbstractMavenFilteringRequest.injectProjectBuildFilters}}
> defaulted to {{false}}.
> While constructing {{defaultFilterWrappers}} in
> {{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(MavenProject,
> File)}} the {{MavenResourcesExecution}} is constructed.
> In {{maven-filtering:1.0-beta-2}} there's unconditional call:
> {code:java}
> loadProperties( filterProperties, mavenProject.getBuild().getFilters(),
> baseProps );
> {code}
> In {{maven-filtering:1.1}}+ there's conditional call:
> {code:java}
> if ( request.isInjectProjectBuildFilters() )
> {
> List buildFilters = new ArrayList(
> request.getMavenProject().getBuild().getFilters() );
> buildFilters.removeAll( request.getFileFilters() );
> loadProperties( filterProperties, buildFilters, baseProps );
> }
> {code}
> So my filters declared (as always) in:
> {code:xml}
>
>
> ../src/config/env/envX/config.properties
>
>
> {code}
> are *not taken into account* forcing me to set (configuration duplicate)
> [maven-war-plugin's
> filter|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#filters]
> property.
> Please change (in
> {{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp()}}) the line:
> {code:xml}
> mavenResourcesExecution.setFilters( filters );
> {code}
> to
> {code:xml}
> mavenResourcesExecution.setFilters( filters == null ?
> project.getBuild().getFilters() : filters );
> {code}
> regards
> Grzegorz Grzybek
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MWAR-305) Filtering doesn't work as expected after switching from maven-filtering:1.0-beta-2 to maven-filtering:1.1
Grzegorz Grzybek created MWAR-305:
-
Summary: Filtering doesn't work as expected after switching from
maven-filtering:1.0-beta-2 to maven-filtering:1.1
Key: MWAR-305
URL: https://jira.codehaus.org/browse/MWAR-305
Project: Maven WAR Plugin
Issue Type: Bug
Reporter: Grzegorz Grzybek
Priority: Critical
{{maven-filtering:1.0-beta-3}} introduced a setting
{{org.apache.maven.shared.filtering.AbstractMavenFilteringRequest.injectProjectBuildFilters}}
defaulted to {{false}}.
While constructing {{defaultFilterWrappers}} in
{{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(MavenProject, File)}}
the {{MavenResourcesExecution}} is constructed.
In {{maven-filtering:1.0-beta-2}} there's unconditional call:
{code:java}
loadProperties( filterProperties, mavenProject.getBuild().getFilters(),
baseProps );
{code}
In {{maven-filtering:1.1}}+ there's conditional call:
{code:java}
if ( request.isInjectProjectBuildFilters() )
{
List buildFilters = new ArrayList(
request.getMavenProject().getBuild().getFilters() );
buildFilters.removeAll( request.getFileFilters() );
loadProperties( filterProperties, buildFilters, baseProps );
}
{code}
So my filters declared (as always) in:
{code:xml}
../src/config/env/envX/config.properties
{code}
are *not taken into account* forcing me to set (configuration duplicate)
[maven-war-plugin's
filter|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#filters]
property.
Please change (in
{{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp()}}) the line:
{code:xml}
mavenResourcesExecution.setFilters( filters );
{code}
to
{code:xml}
mavenResourcesExecution.setFilters( filters == null ?
project.getBuild().getFilters() : filters );
{code}
regards
Grzegorz Grzybek
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHARED-293) Filtering doesn't work as expected after switching from maven-filtering:1.0-beta-2 to maven-filtering:1.1
Grzegorz Grzybek created MSHARED-293:
Summary: Filtering doesn't work as expected after switching from
maven-filtering:1.0-beta-2 to maven-filtering:1.1
Key: MSHARED-293
URL: https://jira.codehaus.org/browse/MSHARED-293
Project: Maven Shared Components
Issue Type: Bug
Reporter: Grzegorz Grzybek
{{maven-filtering:1.0-beta-3}} introduced a setting
{{org.apache.maven.shared.filtering.AbstractMavenFilteringRequest.injectProjectBuildFilters}}
defaulted to {{false}}.
While constructing {{defaultFilterWrappers}} in
{{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(MavenProject, File)}}
the {{MavenResourcesExecution}} is constructed.
In {{maven-filtering:1.0-beta-2}} there's unconditional call:
{code:java}
loadProperties( filterProperties, mavenProject.getBuild().getFilters(),
baseProps );
{code}
In {{maven-filtering:1.1}}+ there's conditional call:
{code:java}
if ( request.isInjectProjectBuildFilters() )
{
List buildFilters = new ArrayList(
request.getMavenProject().getBuild().getFilters() );
buildFilters.removeAll( request.getFileFilters() );
loadProperties( filterProperties, buildFilters, baseProps );
}
{code}
So my filters declared (as always) in:
{code:xml}
../src/config/env/envX/config.properties
{code}
are *not taken into account* forcing me to set (configuration duplicate)
[maven-war-plugin's
filter|http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html#filters]
property.
Please change (in
{{org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp()}}) the line:
{code:xml}
mavenResourcesExecution.setFilters( filters );
{code}
to
{code:xml}
mavenResourcesExecution.setFilters( filters == null ?
project.getBuild().getFilters() : filters );
{code}
regards
Grzegorz Grzybek
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-650) Pretty please restore eclipse:m2eclipse mojo
Pretty please restore eclipse:m2eclipse mojo
Key: MECLIPSE-650
URL: http://jira.codehaus.org/browse/MECLIPSE-650
Project: Maven 2.x Eclipse Plugin
Issue Type: Wish
Components: M2Eclipse support
Affects Versions: 2.8
Reporter: Grzegorz Grzybek
I've read MECLIPSE-632, but I would really like to be able to generate
.project/.classpath files with maven-eclipse-plugin (for example to be able to
create linked resources).
Isn't it possible to generate .classpath without all M2_REPO/* entries and just
{{con = org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER}}?
You can explicitely state that this is special case and one-way generation.
regards
Grzegorz Grzybek
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-482) SvnInfoConsumer not I18N aware
SvnInfoConsumer not I18N aware
--
Key: SCM-482
URL: http://jira.codehaus.org/browse/SCM-482
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-svn
Affects Versions: 1.2
Environment: Debian GNU Linux (squeeze), Subversion 1.5.6
Reporter: Grzegorz Grzybek
There is a problem with class
{{org.apache.maven.scm.provider.svn.svnexe.command.info.SvnInfoConsumer}} - it
heavely depends on:
bq. svn --non-interactive info
result
which differs under different locale settings
It would be *much* better if
{{org.apache.maven.scm.provider.svn.svnexe.command.info.SvnInfoCommand.createCommandLine(SvnScmProviderRepository,
ScmFileSet, boolean, String)}} use:
bq. svn --non-interactive --xml info
instead of:
bq. svn --non-interactive info
the former produces:{panel}
http://javelin/svn/com.winuel.sip/trunk
http://javelin/svn/com.winuel.sip
e17e3fd1-5418-7e4b-8253-85740d203573
normal
infinity
grgr
2009-07-14T11:49:37.776704Z
{panel} and the latter (on my computer):{panel}
Ścieżka: .
URL: http://javelin/svn/com.winuel.sip/trunk
Katalog główny repozytorium: http://javelin/svn/com.winuel.sip
UUID repozytorium: e17e3fd1-5418-7e4b-8253-85740d203573
Wersja: 1647
Rodzaj obiektu: katalog
Zlecenie: normalne
Autor ostatniej zmiany: grgr
Ostatnio zmieniona wersja: 1647
Data ostatniej zmiany: 2009-07-14 13:49:37 +0200 (Wt){panel}
It's obvious that this command should be locale-independent
regards
Grzegorz Grzybek
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-160) Strange behaviour of org.apache.maven.plugin.war.util.WarUtils.dependencyEquals(Dependency, Dependency)
Strange behaviour of
org.apache.maven.plugin.war.util.WarUtils.dependencyEquals(Dependency,
Dependency)
---
Key: MWAR-160
URL: http://jira.codehaus.org/browse/MWAR-160
Project: Maven 2.x War Plugin
Issue Type: Bug
Environment: all
Reporter: Grzegorz Grzybek
Maybe I have a bad day, but it seems that
{code:java}
if ( !!StringUtils.equals( first.getArtifactId(), second.getArtifactId() ) )
{
return false;
}
{code}
has too many ! marks...
am I wrong?
with best regards
Grzegorz Grzybek
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
