Re: Question on shading and missing dependencies

[Lars Francke]

Hi Piotr,

thanks for opening that issue. That's a great idea and would be useful
to have going forward.

And Martin, what you describe can be described using SBOMs as well, so
it's a good fit.

Cheers,
Lars

On Tue, May 14, 2024 at 1:15 AM Martin Desruisseaux
 wrote:
>
> Le 2024-05-13 à 22 h 52, Piotr P. Karwasz a écrit :
>
> > If the CycloneDX Maven plugin learns to use those SBOMs as metadata
> > source instead of POM files, your problem should be solved.
> >
> I'm not familiar with CycloneDX, but I think that if any SBOM is used
> with a shaded artifact, then the metadata should said that the
> dependencies have been transformed that way. For modular dependencies,
> shading the artifact has major impacts: it breaks modules encapsulation,
> potentially creating security holes that did not existed in the original
> libraries. For non-modular dependencies, the impacts are typically
> smaller, but not necessarily null. For example, a library could perform
> security checks based on package names, and those checks may become
> invalid if the packages have been renamed. It does not mean that SBOM
> are useless, but I think that shading is a very significant
> transformation that should be declared in the metadata, and not give the
> impression that the dependencies are in their original form.
>
>  Martin
>

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

Re: Question on shading and missing dependencies

[Martin Desruisseaux]

Le 2024-05-13 à 22 h 52, Piotr P. Karwasz a écrit :

If the CycloneDX Maven plugin learns to use those SBOMs as metadata 
source instead of POM files, your problem should be solved.


I'm not familiar with CycloneDX, but I think that if any SBOM is used 
with a shaded artifact, then the metadata should said that the 
dependencies have been transformed that way. For modular dependencies, 
shading the artifact has major impacts: it breaks modules encapsulation, 
potentially creating security holes that did not existed in the original 
libraries. For non-modular dependencies, the impacts are typically 
smaller, but not necessarily null. For example, a library could perform 
security checks based on package names, and those checks may become 
invalid if the packages have been renamed. It does not mean that SBOM 
are useless, but I think that shading is a very significant 
transformation that should be declared in the metadata, and not give the 
impression that the dependencies are in their original form.


    Martin

Re: Question on shading and missing dependencies

[Piotr P. Karwasz]

Hi Lars,

On Mon, 13 May 2024 at 17:46, Lars Francke  wrote:
> The problem is that SBOM tools have no realistic chance to gather that
> information if all they have is a final artifact and the POMs that
> were published as is the case here.

An increasing number of Maven artifacts publish CycloneDX SBOMs
alongside their artifacts.

If the CycloneDX Maven plugin learns to use those SBOMs as metadata
source instead of POM files, your problem should be solved. I have
opened a feature request[1] for that purpose.

Piotr

[1] https://github.com/CycloneDX/cyclonedx-maven-plugin/issues/497

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

Re: Question on shading and missing dependencies

[Lars Francke]

Hi François,

thanks for the quick response!

The problem is that SBOM tools have no realistic chance to gather that
information if all they have is a final artifact and the POMs that
were published as is the case here.
And as you say: In an ideal world SBOMs would be published along the
way but that is hard for e.g. libraries as well because they don't
know how they are going to be used: Are any of their libraries going
to be overwritten? Shaded? Something else.
It is a hard problem.

You're just confirming what I feared :)

"keepDependenciesWithProvidedScope" seems like a good idea but then
we'd need to make sure to have this set _everywhere_ across the supply
chain.
This topic is going to keep a lot of us awake in the next few years
with Cyber Resilience Act and similar regulation.

Cheers,
Lars


On Mon, May 13, 2024 at 5:37 PM Francois Marot  wrote:
>
> Hello Lars,
>
> ignoring your second email, I felt like it is normal for the pom to ignore
> the shaded dependencies. This is how Maven works.
> For me, it should be the job of a SBOM (CycloneDX format or SPDX for
> exemple) to keep the information of what the shaded jar contains.
> This is the role of SBOMs. So in an ideal world, the shade plugin would
> produce an SBOM to keep track of what is included in the shaded jar.
> In an ideal world, SBOMs would also be kept for each Maven jars in the
> repositories so they coule be aggregated by the shade plugins.
>
> After reading your second mail, "keepDependenciesWithProvidedScope" may be
> the best easy option you have right now, in a not-ideal world.
>
> François
>
> Le lun. 13 mai 2024 à 17:07, Lars Francke  a écrit :
>
> > To add to my question I just found that the shade plugin has an option
> > called "keepDependenciesWithProvidedScope"[1] which might have helped
> > here.
> >
> > [1] <
> > https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#keepDependenciesWithProvidedScope
> > >
> >
> >
> > On Mon, May 13, 2024 at 4:50 PM Lars Francke 
> > wrote:
> > >
> > > Hi,
> > >
> > > we're hunting vulnerabilities in our dependency tree and I have a
> > > question that came up while doing so.
> > >
> > > We are using HBase (I'm a committer there as well) and HBase has (had)
> > > a dependency on the now retired HTrace:
> > >
> > > 
> > >   org.apache.htrace
> > >   htrace-core4
> > > 
> > >
> > > HTrace in version 4.2.0-incubating has a dependency on
> > > jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
> > > relocate all of its dependencies[3].
> > > The published POM of HTrace contains no trace of these dependencies[4].
> > >
> > > A vulnerability scanner like Trivy[5] does find the code via the
> > > META-INF/maven/ files but if HTrace is included via various levels
> > > (e.g. Phoenix -> HBase -> HTrace) it is very hard to follow along and
> > > find the actual place a dependency comes from.
> > >
> > > I also tried the Maven CycloneDX generator and that also does not list
> > > jackson-databind as a dependency.
> > >
> > > My question: Is this expected? How can I build an accurate dependency
> > > tree that includes all dependencies?
> > >
> > > I feel like I must be doing something obvious wrong.
> > >
> > > Thank you for your help.
> > >
> > > Cheers,
> > > Lars
> > >
> > >
> > > [1] <
> > https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/pom.xml#L308-L312
> > >
> > >
> > > [2] <
> > https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L98-L101
> > >
> > >
> > > [3] <
> > https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L52-L59
> > >
> > >
> > > [4] <
> > https://repo1.maven.org/maven2/org/apache/htrace/htrace-core4/4.2.0-incubating/htrace-core4-4.2.0-incubating.pom
> > >
> > >
> > > [5] <https://github.com/aquasecurity/trivy>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

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

Re: Question on shading and missing dependencies

[Francois Marot]

Hello Lars,

ignoring your second email, I felt like it is normal for the pom to ignore
the shaded dependencies. This is how Maven works.
For me, it should be the job of a SBOM (CycloneDX format or SPDX for
exemple) to keep the information of what the shaded jar contains.
This is the role of SBOMs. So in an ideal world, the shade plugin would
produce an SBOM to keep track of what is included in the shaded jar.
In an ideal world, SBOMs would also be kept for each Maven jars in the
repositories so they coule be aggregated by the shade plugins.

After reading your second mail, "keepDependenciesWithProvidedScope" may be
the best easy option you have right now, in a not-ideal world.

François

Le lun. 13 mai 2024 à 17:07, Lars Francke  a écrit :

> To add to my question I just found that the shade plugin has an option
> called "keepDependenciesWithProvidedScope"[1] which might have helped
> here.
>
> [1] <
> https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#keepDependenciesWithProvidedScope
> >
>
>
> On Mon, May 13, 2024 at 4:50 PM Lars Francke 
> wrote:
> >
> > Hi,
> >
> > we're hunting vulnerabilities in our dependency tree and I have a
> > question that came up while doing so.
> >
> > We are using HBase (I'm a committer there as well) and HBase has (had)
> > a dependency on the now retired HTrace:
> >
> > 
> >   org.apache.htrace
> >   htrace-core4
> > 
> >
> > HTrace in version 4.2.0-incubating has a dependency on
> > jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
> > relocate all of its dependencies[3].
> > The published POM of HTrace contains no trace of these dependencies[4].
> >
> > A vulnerability scanner like Trivy[5] does find the code via the
> > META-INF/maven/ files but if HTrace is included via various levels
> > (e.g. Phoenix -> HBase -> HTrace) it is very hard to follow along and
> > find the actual place a dependency comes from.
> >
> > I also tried the Maven CycloneDX generator and that also does not list
> > jackson-databind as a dependency.
> >
> > My question: Is this expected? How can I build an accurate dependency
> > tree that includes all dependencies?
> >
> > I feel like I must be doing something obvious wrong.
> >
> > Thank you for your help.
> >
> > Cheers,
> > Lars
> >
> >
> > [1] <
> https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/pom.xml#L308-L312
> >
> >
> > [2] <
> https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L98-L101
> >
> >
> > [3] <
> https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L52-L59
> >
> >
> > [4] <
> https://repo1.maven.org/maven2/org/apache/htrace/htrace-core4/4.2.0-incubating/htrace-core4-4.2.0-incubating.pom
> >
> >
> > [5] <https://github.com/aquasecurity/trivy>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Question on shading and missing dependencies

[Lars Francke]

To add to my question I just found that the shade plugin has an option
called "keepDependenciesWithProvidedScope"[1] which might have helped
here.

[1] 
<https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#keepDependenciesWithProvidedScope>


On Mon, May 13, 2024 at 4:50 PM Lars Francke  wrote:
>
> Hi,
>
> we're hunting vulnerabilities in our dependency tree and I have a
> question that came up while doing so.
>
> We are using HBase (I'm a committer there as well) and HBase has (had)
> a dependency on the now retired HTrace:
>
> 
>   org.apache.htrace
>   htrace-core4
> 
>
> HTrace in version 4.2.0-incubating has a dependency on
> jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
> relocate all of its dependencies[3].
> The published POM of HTrace contains no trace of these dependencies[4].
>
> A vulnerability scanner like Trivy[5] does find the code via the
> META-INF/maven/ files but if HTrace is included via various levels
> (e.g. Phoenix -> HBase -> HTrace) it is very hard to follow along and
> find the actual place a dependency comes from.
>
> I also tried the Maven CycloneDX generator and that also does not list
> jackson-databind as a dependency.
>
> My question: Is this expected? How can I build an accurate dependency
> tree that includes all dependencies?
>
> I feel like I must be doing something obvious wrong.
>
> Thank you for your help.
>
> Cheers,
> Lars
>
>
> [1] 
> <https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/pom.xml#L308-L312>
>
> [2] 
> <https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L98-L101>
>
> [3] 
> <https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L52-L59>
>
> [4] 
> <https://repo1.maven.org/maven2/org/apache/htrace/htrace-core4/4.2.0-incubating/htrace-core4-4.2.0-incubating.pom>
>
> [5] <https://github.com/aquasecurity/trivy>

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

Question on shading and missing dependencies

[Lars Francke]

Hi,

we're hunting vulnerabilities in our dependency tree and I have a
question that came up while doing so.

We are using HBase (I'm a committer there as well) and HBase has (had)
a dependency on the now retired HTrace:


  org.apache.htrace
  htrace-core4


HTrace in version 4.2.0-incubating has a dependency on
jackson-databind 2.4.0[1, 2] but it also uses the shade plugin to
relocate all of its dependencies[3].
The published POM of HTrace contains no trace of these dependencies[4].

A vulnerability scanner like Trivy[5] does find the code via the
META-INF/maven/ files but if HTrace is included via various levels
(e.g. Phoenix -> HBase -> HTrace) it is very hard to follow along and
find the actual place a dependency comes from.

I also tried the Maven CycloneDX generator and that also does not list
jackson-databind as a dependency.

My question: Is this expected? How can I build an accurate dependency
tree that includes all dependencies?

I feel like I must be doing something obvious wrong.

Thank you for your help.

Cheers,
Lars


[1] 
<https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/pom.xml#L308-L312>

[2] 
<https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L98-L101>

[3] 
<https://github.com/apache/incubator-retired-htrace/blob/2ce9d3b25a49d371a7b48e389b56d50a0164c8a0/htrace-core4/pom.xml#L52-L59>

[4] 
<https://repo1.maven.org/maven2/org/apache/htrace/htrace-core4/4.2.0-incubating/htrace-core4-4.2.0-incubating.pom>

[5] <https://github.com/aquasecurity/trivy>

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

Re: a question about the Maven Resolver Ant Tasks uber JAR

[Tamás Cservenák]

Re-reading your "I tried to make a JAR that included the Maven Resolver Ant
Tasks uber JAR plus some extra stuff"...

The Maven Resolver Ant Tasks uber JAR contains _relocated_ classes (see
POM).

Hence, using this uber JAR to create another uber JAR is not recommended
(or make sure there are no shared dependencies).

You'd be better if you used non-uber JAR dependencies of Ant Tasks and
other stuff and create uber jar out of those instead.

T

On Fri, Mar 1, 2024 at 4:55 PM Alan Snyder 
wrote:

> So how should this issue be resolved?
>
> Should the exclusion be removed?
>
> > On Feb 28, 2024, at 9:33 PM, Thorsten Heit  wrote:
> >
> > Hi,
> >
> >> For reasons that I may no longer believe, I tried to make a JAR that
> included the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
> >> I figured I could do that by resolving the Maven Resolver Ant Tasks and
> including all those artifacts in my JAR.
> >> But that did not work.
> >> The resulting JAR fails because of a class not found:
> org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
> >> What seems odd is that the POM for maven-resolver-transport-http
> *explicitly excludes commons-logging*.
> >> The stated explanation is that jcl-over-slf4j is used instead.
> >> But obviously, there is some need for commons-logging, and the MRAT
> uber JAR includes commons-logging.
> >> Is commons-logging added to the MRAT uber JAR as a special case?
> >
> > As long as *jcl-over-slf4j* itself is included, that explains the
> > presence of commons-logging stuff:
> >
> >
> > % jar tf
> > ~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar
> > | sort
> > META-INF/
> > (...)
> > org/
> > org/apache/
> > org/apache/commons/
> > org/apache/commons/logging/
> > org/apache/commons/logging/Log.class
> > org/apache/commons/logging/LogConfigurationException.class
> > org/apache/commons/logging/LogFactory.class
> > org/apache/commons/logging/impl/
> > org/apache/commons/logging/impl/NoOpLog.class
> > org/apache/commons/logging/impl/SLF4JLocationAwareLog.class
> > org/apache/commons/logging/impl/SLF4JLog.class
> > org/apache/commons/logging/impl/SLF4JLogFactory.class
> > org/apache/commons/logging/impl/SimpleLog.class
> >
> >
> > Regards
> >
> > Thorsten
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: a question about the Maven Resolver Ant Tasks uber JAR

[Alan Snyder]

So how should this issue be resolved?

Should the exclusion be removed?

> On Feb 28, 2024, at 9:33 PM, Thorsten Heit  wrote:
> 
> Hi,
> 
>> For reasons that I may no longer believe, I tried to make a JAR that 
>> included the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
>> I figured I could do that by resolving the Maven Resolver Ant Tasks and 
>> including all those artifacts in my JAR.
>> But that did not work.
>> The resulting JAR fails because of a class not found: 
>> org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
>> What seems odd is that the POM for maven-resolver-transport-http *explicitly 
>> excludes commons-logging*.
>> The stated explanation is that jcl-over-slf4j is used instead.
>> But obviously, there is some need for commons-logging, and the MRAT uber JAR 
>> includes commons-logging.
>> Is commons-logging added to the MRAT uber JAR as a special case?
> 
> As long as *jcl-over-slf4j* itself is included, that explains the
> presence of commons-logging stuff:
> 
> 
> % jar tf
> ~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar
> | sort
> META-INF/
> (...)
> org/
> org/apache/
> org/apache/commons/
> org/apache/commons/logging/
> org/apache/commons/logging/Log.class
> org/apache/commons/logging/LogConfigurationException.class
> org/apache/commons/logging/LogFactory.class
> org/apache/commons/logging/impl/
> org/apache/commons/logging/impl/NoOpLog.class
> org/apache/commons/logging/impl/SLF4JLocationAwareLog.class
> org/apache/commons/logging/impl/SLF4JLog.class
> org/apache/commons/logging/impl/SLF4JLogFactory.class
> org/apache/commons/logging/impl/SimpleLog.class
> 
> 
> Regards
> 
> Thorsten
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: a question about the Maven Resolver Ant Tasks uber JAR

[Thorsten Heit]

Hi,


For reasons that I may no longer believe, I tried to make a JAR that included 
the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
I figured I could do that by resolving the Maven Resolver Ant Tasks and 
including all those artifacts in my JAR.
But that did not work.
The resulting JAR fails because of a class not found: 
org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
What seems odd is that the POM for maven-resolver-transport-http *explicitly 
excludes commons-logging*.
The stated explanation is that jcl-over-slf4j is used instead.
But obviously, there is some need for commons-logging, and the MRAT uber JAR 
includes commons-logging.
Is commons-logging added to the MRAT uber JAR as a special case?


As long as *jcl-over-slf4j* itself is included, that explains the
presence of commons-logging stuff:


% jar tf
~/.m2/repository/org/slf4j/jcl-over-slf4j/2.0.9/jcl-over-slf4j-2.0.9.jar
| sort
META-INF/
(...)
org/
org/apache/
org/apache/commons/
org/apache/commons/logging/
org/apache/commons/logging/Log.class
org/apache/commons/logging/LogConfigurationException.class
org/apache/commons/logging/LogFactory.class
org/apache/commons/logging/impl/
org/apache/commons/logging/impl/NoOpLog.class
org/apache/commons/logging/impl/SLF4JLocationAwareLog.class
org/apache/commons/logging/impl/SLF4JLog.class
org/apache/commons/logging/impl/SLF4JLogFactory.class
org/apache/commons/logging/impl/SimpleLog.class


Regards

Thorsten

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

Re: a question about the Maven Resolver Ant Tasks uber JAR

[Tamás Cservenák]

Howdy,

This is probably an oversight, as Resolver does use SLF4J and yes, in Maven
for example jcl-over-slf4j is used. Or a bug? As jcl-over-slf4j is here:
https://github.com/apache/maven-resolver/blob/maven-resolver-1.9.18/maven-resolver-transport-http/pom.xml#L81-L86

Can you post some reproducer?

T

On Wed, Feb 28, 2024 at 10:50 PM Alan Snyder 
wrote:

> For reasons that I may no longer believe, I tried to make a JAR that
> included the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
> I figured I could do that by resolving the Maven Resolver Ant Tasks and
> including all those artifacts in my JAR.
> But that did not work.
> The resulting JAR fails because of a class not found:
> org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
> What seems odd is that the POM for maven-resolver-transport-http
> *explicitly excludes commons-logging*.
> The stated explanation is that jcl-over-slf4j is used instead.
> But obviously, there is some need for commons-logging, and the MRAT uber
> JAR includes commons-logging.
> Is commons-logging added to the MRAT uber JAR as a special case?
>
> Seems like something is wrong here.
>
> I can fix my problem by adding commons-logging explicitly to my JAR, so I
> don’t need a solution, but I would still
> like to know why I had this problem.
>
>

a question about the Maven Resolver Ant Tasks uber JAR

[Alan Snyder]

For reasons that I may no longer believe, I tried to make a JAR that included 
the Maven Resolver Ant Tasks uber JAR plus some extra stuff.
I figured I could do that by resolving the Maven Resolver Ant Tasks and 
including all those artifacts in my JAR.
But that did not work.
The resulting JAR fails because of a class not found: 
org/apache/commons/logging/LogFactory [called from http AbstractVerifier].
What seems odd is that the POM for maven-resolver-transport-http *explicitly 
excludes commons-logging*.
The stated explanation is that jcl-over-slf4j is used instead.
But obviously, there is some need for commons-logging, and the MRAT uber JAR 
includes commons-logging.
Is commons-logging added to the MRAT uber JAR as a special case?

Seems like something is wrong here.

I can fix my problem by adding commons-logging explicitly to my JAR, so I don’t 
need a solution, but I would still
like to know why I had this problem.

Re: Question about HTTP blocking WARN

[Alexander Kriegisch]

The plugin itself also has lots of dependencies.

$ mvn dependency:resolve-plugins -DincludeArtifactIds=nifi-nar-maven-plugin

org.apache.nifi:nifi-nar-maven-plugin:maven-plugin:1.5.0:runtime
   org.apache.nifi:nifi-nar-maven-plugin:jar:1.5.0
   org.apache.maven:maven-archiver:jar:3.6.0
   org.codehaus.plexus:plexus-io:jar:3.4.0
   javax.inject:javax.inject:jar:1
   org.codehaus.plexus:plexus-archiver:jar:4.4.0
   org.apache.commons:commons-compress:jar:1.21
   org.iq80.snappy:snappy:jar:0.4
   org.tukaani:xz:jar:1.9
   org.codehaus.plexus:plexus-utils:jar:3.4.2
   org.codehaus.plexus:plexus-interpolation:jar:1.26
   org.apache.maven:maven-plugin-api:jar:3.9.0
   org.apache.maven:maven-model:jar:3.9.0
   org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.3.5
   javax.annotation:javax.annotation-api:jar:1.2
   org.eclipse.sisu:org.eclipse.sisu.inject:jar:0.3.5
   org.codehaus.plexus:plexus-classworlds:jar:2.6.0
   org.apache.maven:maven-artifact:jar:3.9.0
   org.apache.commons:commons-lang3:jar:3.8.1
   org.apache.maven:maven-compat:jar:3.9.0
   org.apache.maven:maven-model-builder:jar:3.9.0
   org.apache.maven:maven-builder-support:jar:3.9.0
   org.apache.maven:maven-settings:jar:3.9.0
   org.apache.maven:maven-settings-builder:jar:3.9.0
   org.codehaus.plexus:plexus-sec-dispatcher:jar:2.0
   org.codehaus.plexus:plexus-cipher:jar:2.0
   org.apache.maven:maven-core:jar:3.9.0
   org.apache.maven.resolver:maven-resolver-spi:jar:1.9.4
   com.google.inject:guice:jar:5.1.0
   aopalliance:aopalliance:jar:1.0
   com.google.guava:guava:jar:30.1-jre
   com.google.guava:failureaccess:jar:1.0.1
   org.apache.maven:maven-resolver-provider:jar:3.9.0
   org.apache.maven:maven-repository-metadata:jar:3.9.0
   org.apache.maven.resolver:maven-resolver-api:jar:1.9.4
   org.apache.maven.resolver:maven-resolver-util:jar:1.9.4
   org.apache.maven.resolver:maven-resolver-impl:jar:1.9.4
   org.apache.maven.resolver:maven-resolver-named-locks:jar:1.9.4
   org.codehaus.plexus:plexus-component-annotations:jar:2.1.0
   org.apache.maven.wagon:wagon-provider-api:jar:3.5.3
   org.apache.maven.plugins:maven-dependency-plugin:maven-plugin:3.5.0
   commons-io:commons-io:jar:2.11.0
   org.apache.maven.shared:maven-dependency-analyzer:jar:1.13.0
   org.ow2.asm:asm:jar:9.3
   org.apache.maven.shared:maven-common-artifact-filters:jar:3.3.2
   org.apache.maven.shared:maven-artifact-transfer:jar:0.13.1
   org.apache.maven.shared:maven-shared-utils:jar:3.3.4
   org.apache.commons:commons-collections4:jar:4.2
   org.sonatype.plexus:plexus-build-api:jar:0.0.7
   org.apache.maven.shared:maven-dependency-tree:jar:3.2.1
   org.eclipse.aether:aether-util:jar:1.0.0.v20140518
   org.eclipse.aether:aether-api:jar:1.0.0.v20140518
   org.slf4j:slf4j-api:jar:1.7.36
   org.apache.maven.plugins:maven-jar-plugin:jar:3.3.0
   org.apache.maven.shared:file-management:jar:3.1.0

-- 
Alexander Kriegisch
https://scrum-master.de


Asaf Mesika schrieb am 10.01.2024 02:48 (GMT +07:00):

> For me, on some occasions, it stalls the build as each such "failed" lookup
> takes a long time hence my motivation to solve this problem.
> 
> Regarding nifi:
> I looked at
> https://repo1.maven.org/maven2/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0.pom,
> and I didn't see any repository mentioned there.
> 
> If I want to improve Maven, I need to change that WARN to include the
> repository URL instead of writing maven-default-http-blocker. Is it
> possible?
> 
> 
> 
> On Tue, Jan 9, 2024 at 1:40 PM Stefan CORDES
>  wrote:
> 
>> Hi Asaf,
>> with
>>
>> mvn.cmd install -DskipTests  -Dcheckstyle.skip=true -Dspotbugs.skip=true
>> -Dmaven.repo.local=c:\temp\m2-repo -s c:\temp\empty-settings.xml
>>
>> I receive the same warnings
>>
>> [INFO] --- nifi-nar:1.5.0:nar (default-nar) @ tiered-storage-jcloud ---
>> [INFO] Copying pulsar-common.jar to
>> C:\java\_head\pulsar\tiered-storage\jcloud\target\classes\META-INF\bundled-dependencies\pulsar-common-3.3.0-SNAPSHOT.jar
>> [INFO] Copying jclouds-shaded.jar to
>> C:\java\_head\pulsar\tiered-storage\jcloud\target\classes\META-INF\bundled-dependencies\jclouds-shaded-3.3.0-SNAPSHOT.jar
>> [INFO] Generating documentation for NiFi extensions in the NAR...
>> [WARNING] Could not transfer metadata
>> net.minidev:json-smart/maven-metadata.xml from/to
>> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
>> repositories: [glassfish-repository (
>> http://download.java.net/maven/glassfish, default, releases+snapshots)]
>>
>> but build continues and finishes successfully.
>>
>> Seems to be in nifi-nar plugin.
>>
>> Gruß,
>> Stefan
>>
>> -Original Message-
>> From: Asaf Mesika 
>> Sent: Sunday, January 7, 2024 12:22 PM
>> To: Maven Users List 
>> Subject: Re: 

Re: Question about HTTP blocking WARN

[Asaf Mesika]

For me, on some occasions, it stalls the build as each such "failed" lookup
takes a long time hence my motivation to solve this problem.

Regarding nifi:
I looked at
https://repo1.maven.org/maven2/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0.pom,
and I didn't see any repository mentioned there.

If I want to improve Maven, I need to change that WARN to include the
repository URL instead of writing maven-default-http-blocker. Is it
possible?



On Tue, Jan 9, 2024 at 1:40 PM Stefan CORDES
 wrote:

> Hi Asaf,
> with
>
> mvn.cmd install -DskipTests  -Dcheckstyle.skip=true -Dspotbugs.skip=true
> -Dmaven.repo.local=c:\temp\m2-repo -s c:\temp\empty-settings.xml
>
> I receive the same warnings
>
> [INFO] --- nifi-nar:1.5.0:nar (default-nar) @ tiered-storage-jcloud ---
> [INFO] Copying pulsar-common.jar to
> C:\java\_head\pulsar\tiered-storage\jcloud\target\classes\META-INF\bundled-dependencies\pulsar-common-3.3.0-SNAPSHOT.jar
> [INFO] Copying jclouds-shaded.jar to
> C:\java\_head\pulsar\tiered-storage\jcloud\target\classes\META-INF\bundled-dependencies\jclouds-shaded-3.3.0-SNAPSHOT.jar
> [INFO] Generating documentation for NiFi extensions in the NAR...
> [WARNING] Could not transfer metadata
> net.minidev:json-smart/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for
> repositories: [glassfish-repository (
> http://download.java.net/maven/glassfish, default, releases+snapshots)]
>
> but build continues and finishes successfully.
>
> Seems to be in nifi-nar plugin.
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Sunday, January 7, 2024 12:22 PM
> To: Maven Users List 
> Subject: Re: Question about HTTP blocking WARN
>
> Hi Stefan,
>
> Not sure I follow. Are you saying you ran the command with a local
> temporary .m2 and didn't see any of the warnings I got?
>
> I looked at
>
> https://repo1.maven.org/maven2/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0.pom
> ,
> and I didn't see any repository mentioned there.
>
> Is my only option for finding the root cause for this warning is altering
> Maven's code to emit the repository, causing this message to appear? Or
> does another option exist?
>
>
>
> On Thu, Jan 4, 2024 at 8:50 PM Stefan CORDES 
> wrote:
>
> > Hi Asaf,
> >
> > Ok, now I could build with
> > mvn clean install -DskipTests -Dmaven.repo.local=c:\temp\m2-repo
> >
> > And even I do not have configured the apache.snapshot in
> > $MAVEN_HOME\conf\settings.xml or ./.m2/settings.xml the
> >
> > Build is trying to download
> >
> > Downloading from apache.snapshots:
> > http://repository.apache.org/snapshots/io/grpc/grpc-api/maven-metadata
> > .xml
> >  apache.snapshot
> >
> > This is happening in the context of
> >  [INFO] org.apache.maven.cli.event.ExecutionEventLogger - ---
> > nifi-nar-maven-plugin:1.5.0:nar (default-nar) @ tiered-storage-jcloud
> > ---
> >
> >
> >
> > And so I guess the
> >
> > nifi-nar-maven-plugin
> >
> > has some "build-in" repositories which refer to http://
> >
> >
> > Gruß,
> > Stefan
> >
> > Gruß,
> > Stefan
> >
> > -Original Message-
> > From: Asaf Mesika 
> > Sent: Thursday, January 4, 2024 5:06 PM
> > To: Maven Users List 
> > Subject: Re: Question about HTTP blocking WARN
> >
> > I appreciate the help, Stefan.
> >
> > I tried deleting the directories you mentioned, but I still got the
> > same warnings regarding "maven-default-http-blocker".
> >
> > I did the following for a clean slate:
> > 1. git clone g...@github.com:apache/pulsar.git pulsar-mvn-issue 2. cd
> > pulsar-mvn-issue 3. ./mvnw clean install -DskipTests
> > -Dmaven.repo.local=/Users/asaf/streamnative/sandbox/temp-m2
> >
> > This uses an empty .m2 directory.
> >
> > In less than a few minutes, I get the following warnings:
> >
> > Downloading from maven-default-http-blocker:
> > http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
> > ...
> > Downloaded from jcenter:
> > https://jcenter.bintray.com/io/grpc/grpc-api/maven-metadata.xml (3.6
> > kB at
> > 8.3 kB/s)
> > Progress (1): 600 B
> >
> > Downloaded from sonatype-nexus-snapshots:
> >
> > https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-a
> > pi/maven-metadata.xml
> > (600 B at 525 B/s)
> > [WARNING] Could not transfer metadata
> > io.grpc:grpc-api/maven-metadata.xml
> > from/to maven-default-http-blocke

RE: Question about HTTP blocking WARN

[Stefan CORDES]

Hi Asaf,
with

mvn.cmd install -DskipTests  -Dcheckstyle.skip=true -Dspotbugs.skip=true 
-Dmaven.repo.local=c:\temp\m2-repo -s c:\temp\empty-settings.xml

I receive the same warnings

[INFO] --- nifi-nar:1.5.0:nar (default-nar) @ tiered-storage-jcloud ---
[INFO] Copying pulsar-common.jar to 
C:\java\_head\pulsar\tiered-storage\jcloud\target\classes\META-INF\bundled-dependencies\pulsar-common-3.3.0-SNAPSHOT.jar
[INFO] Copying jclouds-shaded.jar to 
C:\java\_head\pulsar\tiered-storage\jcloud\target\classes\META-INF\bundled-dependencies\jclouds-shaded-3.3.0-SNAPSHOT.jar
[INFO] Generating documentation for NiFi extensions in the NAR...
[WARNING] Could not transfer metadata net.minidev:json-smart/maven-metadata.xml 
from/to maven-default-http-blocker (http://0.0.0.0/): Blocked mirror for 
repositories: [glassfish-repository (http://download.java.net/maven/glassfish, 
default, releases+snapshots)]

but build continues and finishes successfully.

Seems to be in nifi-nar plugin.

Gruß,
Stefan

-Original Message-
From: Asaf Mesika 
Sent: Sunday, January 7, 2024 12:22 PM
To: Maven Users List 
Subject: Re: Question about HTTP blocking WARN

Hi Stefan,

Not sure I follow. Are you saying you ran the command with a local temporary 
.m2 and didn't see any of the warnings I got?

I looked at
https://repo1.maven.org/maven2/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0.pom,
and I didn't see any repository mentioned there.

Is my only option for finding the root cause for this warning is altering 
Maven's code to emit the repository, causing this message to appear? Or does 
another option exist?



On Thu, Jan 4, 2024 at 8:50 PM Stefan CORDES  
wrote:

> Hi Asaf,
>
> Ok, now I could build with
> mvn clean install -DskipTests -Dmaven.repo.local=c:\temp\m2-repo
>
> And even I do not have configured the apache.snapshot in
> $MAVEN_HOME\conf\settings.xml or ./.m2/settings.xml the
>
> Build is trying to download
>
> Downloading from apache.snapshots:
> http://repository.apache.org/snapshots/io/grpc/grpc-api/maven-metadata
> .xml
>  apache.snapshot
>
> This is happening in the context of
>  [INFO] org.apache.maven.cli.event.ExecutionEventLogger - ---
> nifi-nar-maven-plugin:1.5.0:nar (default-nar) @ tiered-storage-jcloud
> ---
>
>
>
> And so I guess the
>
> nifi-nar-maven-plugin
>
> has some "build-in" repositories which refer to http://
>
>
> Gruß,
> Stefan
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Thursday, January 4, 2024 5:06 PM
> To: Maven Users List 
> Subject: Re: Question about HTTP blocking WARN
>
> I appreciate the help, Stefan.
>
> I tried deleting the directories you mentioned, but I still got the
> same warnings regarding "maven-default-http-blocker".
>
> I did the following for a clean slate:
> 1. git clone g...@github.com:apache/pulsar.git pulsar-mvn-issue 2. cd
> pulsar-mvn-issue 3. ./mvnw clean install -DskipTests
> -Dmaven.repo.local=/Users/asaf/streamnative/sandbox/temp-m2
>
> This uses an empty .m2 directory.
>
> In less than a few minutes, I get the following warnings:
>
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
> ...
> Downloaded from jcenter:
> https://jcenter.bintray.com/io/grpc/grpc-api/maven-metadata.xml (3.6
> kB at
> 8.3 kB/s)
> Progress (1): 600 B
>
> Downloaded from sonatype-nexus-snapshots:
>
> https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-a
> pi/maven-metadata.xml
> (600 B at 525 B/s)
> [WARNING] Could not transfer metadata
> io.grpc:grpc-api/maven-metadata.xml
> from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed
> for http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-
> 1.51.0.pom
> Progress (1): 2.0 kB
>
> Downloaded from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-
> 1.51.0.pom
> (2.0 kB at 13 kB/s)
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-context/1.51.0/grpc-
> context-1.51.0.pom
> ...
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
> ...
> Downloaded from sonatype-nexus-snapshots:
>
> https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-c
> ore/maven-metadata.xml
> (906 B at 2.5 kB/s)
> Downloaded from jcenter:
> https://jcenter.bintray.com/io/grpc/grpc-core/maven-metadata.xml (5.2
> kB at
> 12 kB/s)
> [WARNING] Could not transfer metadata
> io.grpc:grpc-core/maven-metadata.xml
> from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed
>

Re: Question about HTTP blocking WARN

[Asaf Mesika]

Hi Stefan,

Not sure I follow. Are you saying you ran the command with a local
temporary .m2 and didn't see any of the warnings I got?

I looked at
https://repo1.maven.org/maven2/org/apache/nifi/nifi-nar-maven-plugin/1.5.0/nifi-nar-maven-plugin-1.5.0.pom,
and I didn't see any repository mentioned there.

Is my only option for finding the root cause for this warning is altering
Maven's code to emit the repository, causing this message to appear? Or
does another option exist?



On Thu, Jan 4, 2024 at 8:50 PM Stefan CORDES
 wrote:

> Hi Asaf,
>
> Ok, now I could build with
> mvn clean install -DskipTests -Dmaven.repo.local=c:\temp\m2-repo
>
> And even I do not have configured the apache.snapshot in
> $MAVEN_HOME\conf\settings.xml or ./.m2/settings.xml the
>
> Build is trying to download
>
> Downloading from apache.snapshots:
> http://repository.apache.org/snapshots/io/grpc/grpc-api/maven-metadata.xml
>  apache.snapshot
>
> This is happening in the context of
>  [INFO] org.apache.maven.cli.event.ExecutionEventLogger - ---
> nifi-nar-maven-plugin:1.5.0:nar (default-nar) @ tiered-storage-jcloud ---
>
>
>
> And so I guess the
>
> nifi-nar-maven-plugin
>
> has some "build-in" repositories which refer to http://
>
>
> Gruß,
> Stefan
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Thursday, January 4, 2024 5:06 PM
> To: Maven Users List 
> Subject: Re: Question about HTTP blocking WARN
>
> I appreciate the help, Stefan.
>
> I tried deleting the directories you mentioned, but I still got the same
> warnings regarding "maven-default-http-blocker".
>
> I did the following for a clean slate:
> 1. git clone g...@github.com:apache/pulsar.git pulsar-mvn-issue 2. cd
> pulsar-mvn-issue 3. ./mvnw clean install -DskipTests
> -Dmaven.repo.local=/Users/asaf/streamnative/sandbox/temp-m2
>
> This uses an empty .m2 directory.
>
> In less than a few minutes, I get the following warnings:
>
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
> ...
> Downloaded from jcenter:
> https://jcenter.bintray.com/io/grpc/grpc-api/maven-metadata.xml (3.6 kB at
> 8.3 kB/s)
> Progress (1): 600 B
>
> Downloaded from sonatype-nexus-snapshots:
>
> https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-api/maven-metadata.xml
> (600 B at 525 B/s)
> [WARNING] Could not transfer metadata io.grpc:grpc-api/maven-metadata.xml
> from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-1.51.0.pom
> Progress (1): 2.0 kB
>
> Downloaded from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-1.51.0.pom
> (2.0 kB at 13 kB/s)
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-context/1.51.0/grpc-context-1.51.0.pom
> ...
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
> ...
> Downloaded from sonatype-nexus-snapshots:
>
> https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-core/maven-metadata.xml
> (906 B at 2.5 kB/s)
> Downloaded from jcenter:
> https://jcenter.bintray.com/io/grpc/grpc-core/maven-metadata.xml (5.2 kB
> at
> 12 kB/s)
> [WARNING] Could not transfer metadata io.grpc:grpc-core/maven-metadata.xml
> from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.50.2/grpc-core-1.50.2.pom
> Progress (1): 2.5 kB
>
> Downloaded from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.50.2/grpc-core-1.50.2.pom
> (2.5 kB at 17 kB/s)
> [WARNING] io.grpc:grpc-api/maven-metadata.xmlfailed to transfer from
> http://0.0.0.0/ during a previous attempt. This failure was cached in the
> local repository and resolution will not be reattempted until the update
> interval of maven-default-http-blocker has elapsed or updates are forced.
> Original error: Could not transfer metadata
> io.grpc:grpc-api/maven-metadata.xml from/to maven-default-http-blocker (
> http://0.0.0.0/): transfer failed for
> http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
> Downloading from vertx-snapshots-repository:
>
> https://s01.oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-api/maven-metadata.xml
> Downloading from central:
>
> https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.50.2/grpc-api-1.50.2.pom
> Progress (1): 2.0 kB
>
> Downl

RE: Question about HTTP blocking WARN

[Stefan CORDES]

Hi Asaf,

Ok, now I could build with
mvn clean install -DskipTests -Dmaven.repo.local=c:\temp\m2-repo

And even I do not have configured the apache.snapshot in 
$MAVEN_HOME\conf\settings.xml or ./.m2/settings.xml the

Build is trying to download

Downloading from apache.snapshots: 
http://repository.apache.org/snapshots/io/grpc/grpc-api/maven-metadata.xml   
apache.snapshot

This is happening in the context of
 [INFO] org.apache.maven.cli.event.ExecutionEventLogger - --- 
nifi-nar-maven-plugin:1.5.0:nar (default-nar) @ tiered-storage-jcloud ---



And so I guess the

nifi-nar-maven-plugin

has some "build-in" repositories which refer to http://


Gruß,
Stefan

Gruß,
Stefan

-Original Message-
From: Asaf Mesika 
Sent: Thursday, January 4, 2024 5:06 PM
To: Maven Users List 
Subject: Re: Question about HTTP blocking WARN

I appreciate the help, Stefan.

I tried deleting the directories you mentioned, but I still got the same 
warnings regarding "maven-default-http-blocker".

I did the following for a clean slate:
1. git clone g...@github.com:apache/pulsar.git pulsar-mvn-issue 2. cd 
pulsar-mvn-issue 3. ./mvnw clean install -DskipTests
-Dmaven.repo.local=/Users/asaf/streamnative/sandbox/temp-m2

This uses an empty .m2 directory.

In less than a few minutes, I get the following warnings:

Downloading from maven-default-http-blocker:
http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
...
Downloaded from jcenter:
https://jcenter.bintray.com/io/grpc/grpc-api/maven-metadata.xml (3.6 kB at
8.3 kB/s)
Progress (1): 600 B

Downloaded from sonatype-nexus-snapshots:
https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-api/maven-metadata.xml
(600 B at 525 B/s)
[WARNING] Could not transfer metadata io.grpc:grpc-api/maven-metadata.xml
from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-1.51.0.pom
Progress (1): 2.0 kB

Downloaded from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-1.51.0.pom
(2.0 kB at 13 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-context/1.51.0/grpc-context-1.51.0.pom
...
Downloading from maven-default-http-blocker:
http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
...
Downloaded from sonatype-nexus-snapshots:
https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-core/maven-metadata.xml
(906 B at 2.5 kB/s)
Downloaded from jcenter:
https://jcenter.bintray.com/io/grpc/grpc-core/maven-metadata.xml (5.2 kB at
12 kB/s)
[WARNING] Could not transfer metadata io.grpc:grpc-core/maven-metadata.xml
from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.50.2/grpc-core-1.50.2.pom
Progress (1): 2.5 kB

Downloaded from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.50.2/grpc-core-1.50.2.pom
(2.5 kB at 17 kB/s)
[WARNING] io.grpc:grpc-api/maven-metadata.xmlfailed to transfer from 
http://0.0.0.0/ during a previous attempt. This failure was cached in the local 
repository and resolution will not be reattempted until the update interval of 
maven-default-http-blocker has elapsed or updates are forced.
Original error: Could not transfer metadata io.grpc:grpc-api/maven-metadata.xml 
from/to maven-default-http-blocker (
http://0.0.0.0/): transfer failed for
http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
Downloading from vertx-snapshots-repository:
https://s01.oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-api/maven-metadata.xml
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.50.2/grpc-api-1.50.2.pom
Progress (1): 2.0 kB

Downloaded from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.50.2/grpc-api-1.50.2.pom
(2.0 kB at 13 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-context/1.50.2/grpc-context-1.50.2.pom
Progress (1): 1.2 kB


Are you not getting those warnings?
My main issue here is: How do I know which repository is blocked due to lack of 
https? Once I know, I can search for it in the pom.xml and change it, right?
I know that I don't have any settings.xml personally that can affect it, so it 
must be in the pom.xml

Thanks!

Asaf



On Thu, Jan 4, 2024 at 12:53 PM Stefan CORDES  
wrote:

> Hi Asaf,
>
> my build (branch * master) works.
>
> Try deleting
> ~/.m2/repository/org/mongodb/bson
> and
> ~/.m2/repository/org/testcontainers
>
> (Maybe in the past you had a sonatype-nexus-snapshots via "http://; in
> one of your settings.xml or pom.xml)
>
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Tuesday, January 2, 2024 1:25 PM
> To: Maven Users List 
> Subj

Re: Question about HTTP blocking WARN

[Asaf Mesika]

I appreciate the help, Stefan.

I tried deleting the directories you mentioned, but I still got the same
warnings regarding "maven-default-http-blocker".

I did the following for a clean slate:
1. git clone g...@github.com:apache/pulsar.git pulsar-mvn-issue
2. cd pulsar-mvn-issue
3. ./mvnw clean install -DskipTests
-Dmaven.repo.local=/Users/asaf/streamnative/sandbox/temp-m2

This uses an empty .m2 directory.

In less than a few minutes, I get the following warnings:

Downloading from maven-default-http-blocker:
http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
...
Downloaded from jcenter:
https://jcenter.bintray.com/io/grpc/grpc-api/maven-metadata.xml (3.6 kB at
8.3 kB/s)
Progress (1): 600 B

Downloaded from sonatype-nexus-snapshots:
https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-api/maven-metadata.xml
(600 B at 525 B/s)
[WARNING] Could not transfer metadata io.grpc:grpc-api/maven-metadata.xml
from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-1.51.0.pom
Progress (1): 2.0 kB

Downloaded from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.51.0/grpc-api-1.51.0.pom
(2.0 kB at 13 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-context/1.51.0/grpc-context-1.51.0.pom
...
Downloading from maven-default-http-blocker:
http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
...
Downloaded from sonatype-nexus-snapshots:
https://oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-core/maven-metadata.xml
(906 B at 2.5 kB/s)
Downloaded from jcenter:
https://jcenter.bintray.com/io/grpc/grpc-core/maven-metadata.xml (5.2 kB at
12 kB/s)
[WARNING] Could not transfer metadata io.grpc:grpc-core/maven-metadata.xml
from/to maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/io/grpc/grpc-core/maven-metadata.xml
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.50.2/grpc-core-1.50.2.pom
Progress (1): 2.5 kB

Downloaded from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.50.2/grpc-core-1.50.2.pom
(2.5 kB at 17 kB/s)
[WARNING] io.grpc:grpc-api/maven-metadata.xmlfailed to transfer from
http://0.0.0.0/ during a previous attempt. This failure was cached in the
local repository and resolution will not be reattempted until the update
interval of maven-default-http-blocker has elapsed or updates are forced.
Original error: Could not transfer metadata
io.grpc:grpc-api/maven-metadata.xml from/to maven-default-http-blocker (
http://0.0.0.0/): transfer failed for
http://0.0.0.0/io/grpc/grpc-api/maven-metadata.xml
Downloading from vertx-snapshots-repository:
https://s01.oss.sonatype.org/content/repositories/snapshots/io/grpc/grpc-api/maven-metadata.xml
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.50.2/grpc-api-1.50.2.pom
Progress (1): 2.0 kB

Downloaded from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-api/1.50.2/grpc-api-1.50.2.pom
(2.0 kB at 13 kB/s)
Downloading from central:
https://repo.maven.apache.org/maven2/io/grpc/grpc-context/1.50.2/grpc-context-1.50.2.pom
Progress (1): 1.2 kB


Are you not getting those warnings?
My main issue here is: How do I know which repository is blocked due to
lack of https? Once I know, I can search for it in the pom.xml and change
it, right?
I know that I don't have any settings.xml personally that can affect it, so
it must be in the pom.xml

Thanks!

Asaf



On Thu, Jan 4, 2024 at 12:53 PM Stefan CORDES
 wrote:

> Hi Asaf,
>
> my build (branch * master) works.
>
> Try deleting
> ~/.m2/repository/org/mongodb/bson
> and
> ~/.m2/repository/org/testcontainers
>
> (Maybe in the past you had a sonatype-nexus-snapshots via "http://; in
> one of your settings.xml or pom.xml)
>
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Tuesday, January 2, 2024 1:25 PM
> To: Maven Users List 
> Subject: Re: Question about HTTP blocking WARN
>
> Here is the content of the file you wrote:
>
> ➜  pulsar git:(pip-323-implementation) ✗ cat
> ~/.m2/repository/org/mongodb/bson/4.4.2-SNAPSHOT/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format
> can be changed without prior notice.
> #Wed Feb 08 16:24:48 IST 2023
> bson-4.4.2-20220207.232016-3.pom>sonatype-nexus-snapshots=
> ➜  pulsar git:(pip-323-implementation) ✗
>
> I don't have a MAVEN_HOME env variable
>
> ➜  pulsar git:(pip-323-implementation) ✗ echo $MAVEN_HOME
>
> ➜  pulsar git:(pip-323-implementation) ✗
>
> Also no settings.xml file
>
> ➜  pulsar git:(pip-323-implementation) ✗ cat ~/.m2/settings.xml
> cat: /Users/asaf/.m2/settings.xml: No such file or directory
>
> In my buil

RE: Question about HTTP blocking WARN

[Stefan CORDES]

Hi Asaf,

my build (branch * master) works.

Try deleting
~/.m2/repository/org/mongodb/bson
and
~/.m2/repository/org/testcontainers

(Maybe in the past you had a sonatype-nexus-snapshots via "http://; in one of 
your settings.xml or pom.xml)


Gruß,
Stefan

-Original Message-
From: Asaf Mesika 
Sent: Tuesday, January 2, 2024 1:25 PM
To: Maven Users List 
Subject: Re: Question about HTTP blocking WARN

Here is the content of the file you wrote:

➜  pulsar git:(pip-323-implementation) ✗ cat 
~/.m2/repository/org/mongodb/bson/4.4.2-SNAPSHOT/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format can be 
changed without prior notice.
#Wed Feb 08 16:24:48 IST 2023
bson-4.4.2-20220207.232016-3.pom>sonatype-nexus-snapshots=
➜  pulsar git:(pip-323-implementation) ✗

I don't have a MAVEN_HOME env variable

➜  pulsar git:(pip-323-implementation) ✗ echo $MAVEN_HOME

➜  pulsar git:(pip-323-implementation) ✗

Also no settings.xml file

➜  pulsar git:(pip-323-implementation) ✗ cat ~/.m2/settings.xml
cat: /Users/asaf/.m2/settings.xml: No such file or directory

In my build output the module is:

[INFO] --- maven-install-plugin:3.1.0:install (default-install) @ 
pulsar-io-rabbitmq --- [INFO] Installing 
/Users/asaf/streamnative/pulsar/pulsar-io/rabbitmq/pom.xml to 
/Users/asaf/.m2/repository/org/apache/pulsar/pulsar-io-rabbitmq/3.2.0-SNAPSHOT/pulsar-io-rabbitmq-3.2.0-SNAPSHOT.pom
[INFO] Installing
/Users/asaf/streamnative/pulsar/pulsar-io/rabbitmq/target/pulsar-io-rabbitmq-3.2.0-SNAPSHOT.nar
to
/Users/asaf/.m2/repository/org/apache/pulsar/pulsar-io-rabbitmq/3.2.0-SNAPSHOT/pulsar-io-rabbitmq-3.2.0-SNAPSHOT.jar
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml


I run it as `./mvnw clean install -DskipTests`

On Wed, Dec 13, 2023 at 9:24 PM Stefan CORDES  
wrote:

> Hi Asaf,
> normally you should not unblock http:// repositories as all artifacts
> are (should be) available via https://
>
> I build latest master from g...@github.com:apache/pulsar.git and up to
> module
>  Building Pulsar IO :: Canal 3.2.0-SNAPSHOT  [75/134]
>  (later it failed locally)
>
> I did not see maven-default-http-blocker here.
>
> Maybe in your local repository
> ~/.m2/repository/org/mongodb/bson/4.4.2-SNAPSHOT
> the _remote.repositories file contains outdated http:// repository
> references?
>
> Additionally you can check your personal ~/.m2/settings.xml and
> maven_home/conf/settings.xml not having any  with http://
> and not any  with http://
>
> If still facing maven-default-http-blocker: which module of pulsar
> build tries to download ?
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Wednesday, December 13, 2023 7:41 PM
> To: Maven Users List 
> Subject: Re: Question about HTTP blocking WARN
>
> How do I unblock ? I searched in .mvn directory and found nothing. I
> don’t have a settings file
>
> On Wed, 13 Dec 2023 at 17:50 
> wrote:
>
> > Sorry, I failed to read your email carefully enough.
> > Idea: try un-blocking HTTP, and see where it ends up downloading
> > things from.
> >
> > -Original Message-----
> > From: mark.yagnatin...@barclays.com.INVALID
> > 
> > Sent: Wednesday, December 13, 2023 10:47 AM
> > To: users@maven.apache.org
> > Subject: RE: Question about HTTP blocking WARN
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > mark.yagnatin...@barclays.com.INVALID Do not click on links, open
> > attachments, or respond unless you recognize the sender and can
> > validate the content is safe.
> > See release notes for 3.8.1:
> >
> > https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmf
> > ng
> > K9X2

Re: Question about HTTP blocking WARN

[Asaf Mesika]

Here is the content of the file you wrote:

➜  pulsar git:(pip-323-implementation) ✗ cat
~/.m2/repository/org/mongodb/bson/4.4.2-SNAPSHOT/_remote.repositories
#NOTE: This is a Maven Resolver internal implementation file, its format
can be changed without prior notice.
#Wed Feb 08 16:24:48 IST 2023
bson-4.4.2-20220207.232016-3.pom>sonatype-nexus-snapshots=
➜  pulsar git:(pip-323-implementation) ✗

I don't have a MAVEN_HOME env variable

➜  pulsar git:(pip-323-implementation) ✗ echo $MAVEN_HOME

➜  pulsar git:(pip-323-implementation) ✗

Also no settings.xml file

➜  pulsar git:(pip-323-implementation) ✗ cat ~/.m2/settings.xml
cat: /Users/asaf/.m2/settings.xml: No such file or directory

In my build output the module is:

[INFO] --- maven-install-plugin:3.1.0:install (default-install) @
pulsar-io-rabbitmq ---
[INFO] Installing
/Users/asaf/streamnative/pulsar/pulsar-io/rabbitmq/pom.xml to
/Users/asaf/.m2/repository/org/apache/pulsar/pulsar-io-rabbitmq/3.2.0-SNAPSHOT/pulsar-io-rabbitmq-3.2.0-SNAPSHOT.pom
[INFO] Installing
/Users/asaf/streamnative/pulsar/pulsar-io/rabbitmq/target/pulsar-io-rabbitmq-3.2.0-SNAPSHOT.nar
to
/Users/asaf/.m2/repository/org/apache/pulsar/pulsar-io-rabbitmq/3.2.0-SNAPSHOT/pulsar-io-rabbitmq-3.2.0-SNAPSHOT.jar
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to
transfer from http://0.0.0.0/ during a previous attempt. This failure was
cached in the local repository and resolution will not be reattempted until
the update interval of maven-default-http-blocker has elapsed or updates
are forced. Original error: Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml


I run it as `./mvnw clean install -DskipTests`

On Wed, Dec 13, 2023 at 9:24 PM Stefan CORDES
 wrote:

> Hi Asaf,
> normally you should not unblock http:// repositories as all artifacts are
> (should be) available via https://
>
> I build latest master from g...@github.com:apache/pulsar.git and up to
> module
>  Building Pulsar IO :: Canal 3.2.0-SNAPSHOT  [75/134]
>  (later it failed locally)
>
> I did not see maven-default-http-blocker here.
>
> Maybe in your local repository
> ~/.m2/repository/org/mongodb/bson/4.4.2-SNAPSHOT
> the _remote.repositories file contains outdated http:// repository
> references?
>
> Additionally you can check your personal ~/.m2/settings.xml and
> maven_home/conf/settings.xml
> not having any  with http:// and not any  with http://
>
> If still facing maven-default-http-blocker: which module of pulsar build
> tries to download ?
>
> Gruß,
> Stefan
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Wednesday, December 13, 2023 7:41 PM
> To: Maven Users List 
> Subject: Re: Question about HTTP blocking WARN
>
> How do I unblock ? I searched in .mvn directory and found nothing. I don’t
> have a settings file
>
> On Wed, 13 Dec 2023 at 17:50 
> wrote:
>
> > Sorry, I failed to read your email carefully enough.
> > Idea: try un-blocking HTTP, and see where it ends up downloading
> > things from.
> >
> > -Original Message-
> > From: mark.yagnatin...@barclays.com.INVALID
> > 
> > Sent: Wednesday, December 13, 2023 10:47 AM
> > To: users@maven.apache.org
> > Subject: RE: Question about HTTP blocking WARN
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > mark.yagnatin...@barclays.com.INVALID Do not click on links, open
> > attachments, or respond unless you recognize the sender and can
> > validate the content is safe.
> > See release notes for 3.8.1:
> >
> > https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfng
> > K9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://maven.apache.org/docs/3.8.1/re
> > lease-notes.html
> >
> > -Original Message-
> > From: Asaf Mesika 
> > Sent: Wednesday, December 13, 2023 6:07 AM
> > To: users@maven.apache.org
> > Subject: Question about HTTP blocking WARN
> >
> >
> > CAUTION: This email originated from outside our organisation -
> > asaf.mes...@gmail.com Do no

RE: Question about HTTP blocking WARN

[Stefan CORDES]

Hi Asaf,
normally you should not unblock http:// repositories as all artifacts are 
(should be) available via https://

I build latest master from g...@github.com:apache/pulsar.git and up to module
 Building Pulsar IO :: Canal 3.2.0-SNAPSHOT  [75/134]
 (later it failed locally)

I did not see maven-default-http-blocker here.

Maybe in your local repository ~/.m2/repository/org/mongodb/bson/4.4.2-SNAPSHOT
the _remote.repositories file contains outdated http:// repository references?

Additionally you can check your personal ~/.m2/settings.xml and 
maven_home/conf/settings.xml
not having any  with http:// and not any  with http://

If still facing maven-default-http-blocker: which module of pulsar build tries 
to download ?

Gruß,
Stefan

-Original Message-
From: Asaf Mesika 
Sent: Wednesday, December 13, 2023 7:41 PM
To: Maven Users List 
Subject: Re: Question about HTTP blocking WARN

How do I unblock ? I searched in .mvn directory and found nothing. I don’t have 
a settings file

On Wed, 13 Dec 2023 at 17:50  wrote:

> Sorry, I failed to read your email carefully enough.
> Idea: try un-blocking HTTP, and see where it ends up downloading
> things from.
>
> -Original Message-
> From: mark.yagnatin...@barclays.com.INVALID
> 
> Sent: Wednesday, December 13, 2023 10:47 AM
> To: users@maven.apache.org
> Subject: RE: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation -
> mark.yagnatin...@barclays.com.INVALID Do not click on links, open
> attachments, or respond unless you recognize the sender and can
> validate the content is safe.
> See release notes for 3.8.1:
>
> https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfng
> K9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://maven.apache.org/docs/3.8.1/re
> lease-notes.html
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Wednesday, December 13, 2023 6:07 AM
> To: users@maven.apache.org
> Subject: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation -
> asaf.mes...@gmail.com Do not click on links, open attachments, or
> respond unless you recognize the sender and can validate the content is safe.
> Hi,
>
> I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building
> Apache Pulsar.
>
> I get the following WARN:
>
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to
> transfer from http://0.0.0.0/ during a previous attempt. This failure
> was cached in the local repository and resolution will not be
> reattempted until the update interval of maven-default-http-blocker
> has elapsed or updates are forced. Original error: Could not transfer
> metadata org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to
> transfer from http://0.0.0.0/ during a previous attempt. This failure
> was cached in the local repository and resolution will not be
> reattempted until the update interval of maven-default-http-blocker
> has elapsed or updates are forced. Original error: Could not transfer
> metadata org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [
>
> I can't understand how to understand which repository in my pom.xml
> has an http and not https repository based on this WARN message.
>
> I searched for  over any pom.xml file and didn't find
> any http repository.
>
> Any help would be greatly appreciated. This is the latest master
> branch of
> pulsar:
> https://clicktime.symantec.com

RE: Question about HTTP blocking WARN

[mark.yagnatinsky]

Look at the second answer to this stack overflow question (the one with 151 
votes, not the one with 209)
https://stackoverflow.com/questions/67001968/how-to-disable-maven-blocking-external-http-repositories
Direct link to answer: https://stackoverflow.com/a/68394404/3273929
(but read the question first!  It's short and has good background)

-Original Message-
From: Asaf Mesika  
Sent: Wednesday, December 13, 2023 1:41 PM
To: Maven Users List 
Subject: Re: Question about HTTP blocking WARN


CAUTION: This email originated from outside our organisation - 
asaf.mes...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
How do I unblock ? I searched in .mvn directory and found nothing. I don’t have 
a settings file

On Wed, 13 Dec 2023 at 17:50  wrote:

> Sorry, I failed to read your email carefully enough.
> Idea: try un-blocking HTTP, and see where it ends up downloading 
> things from.
>
> -Original Message-
> From: mark.yagnatin...@barclays.com.INVALID
> 
> Sent: Wednesday, December 13, 2023 10:47 AM
> To: users@maven.apache.org
> Subject: RE: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation - 
> mark.yagnatin...@barclays.com.INVALID Do not click on links, open 
> attachments, or respond unless you recognize the sender and can 
> validate the content is safe.
> See release notes for 3.8.1:
>
> https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfng
> K9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://clicktime.symantec.com/15sM687
> fTyGuMBLR2CM2R?h=vJEKCCwUrBkrxG9qvgpjtvj4UuijkPM-jYzq_09Gv_8==https:
> //maven.apache.org/docs/3.8.1/release-notes.html
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Wednesday, December 13, 2023 6:07 AM
> To: users@maven.apache.org
> Subject: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation - 
> asaf.mes...@gmail.com Do not click on links, open attachments, or 
> respond unless you recognize the sender and can validate the content is safe.
> Hi,
>
> I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building 
> Apache Pulsar.
>
> I get the following WARN:
>
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to 
> transfer from http://0.0.0.0/ during a previous attempt. This failure 
> was cached in the local repository and resolution will not be 
> reattempted until the update interval of maven-default-http-blocker 
> has elapsed or updates are forced. Original error: Could not transfer 
> metadata org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to 
> transfer from http://0.0.0.0/ during a previous attempt. This failure 
> was cached in the local repository and resolution will not be 
> reattempted until the update interval of maven-default-http-blocker 
> has elapsed or updates are forced. Original error: Could not transfer 
> metadata org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [
>
> I can't understand how to understand which repository in my pom.xml 
> has an http and not https repository based on this WARN message.
>
> I searched for  over any pom.xml file and didn't find 
> any http repository.
>
> Any help would be greatly appreciated. This is the latest master 
> branch of
> pulsar:
> https://clicktime.symantec.com/15sM1HvP1MbJwEWVUdwso?h=BeG4fi1jEwX3x_F
> z_0dLLaDa6HE7dTKsqsKwVd67Tcg==ht

Re: Question about HTTP blocking WARN

[Asaf Mesika]

How do I unblock ? I searched in .mvn directory and found nothing. I don’t
have a settings file

On Wed, 13 Dec 2023 at 17:50  wrote:

> Sorry, I failed to read your email carefully enough.
> Idea: try un-blocking HTTP, and see where it ends up downloading things
> from.
>
> -Original Message-
> From: mark.yagnatin...@barclays.com.INVALID
> 
> Sent: Wednesday, December 13, 2023 10:47 AM
> To: users@maven.apache.org
> Subject: RE: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation -
> mark.yagnatin...@barclays.com.INVALID Do not click on links, open
> attachments, or respond unless you recognize the sender and can validate
> the content is safe.
> See release notes for 3.8.1:
>
> https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfngK9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://maven.apache.org/docs/3.8.1/release-notes.html
>
> -Original Message-
> From: Asaf Mesika 
> Sent: Wednesday, December 13, 2023 6:07 AM
> To: users@maven.apache.org
> Subject: Question about HTTP blocking WARN
>
>
> CAUTION: This email originated from outside our organisation -
> asaf.mes...@gmail.com Do not click on links, open attachments, or respond
> unless you recognize the sender and can validate the content is safe.
> Hi,
>
> I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building Apache
> Pulsar.
>
> I get the following WARN:
>
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to
> transfer from http://0.0.0.0/ during a previous attempt. This failure was
> cached in the local repository and resolution will not be reattempted until
> the update interval of maven-default-http-blocker has elapsed or updates
> are forced. Original error: Could not transfer metadata
> org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to
> transfer from http://0.0.0.0/ during a previous attempt. This failure was
> cached in the local repository and resolution will not be reattempted until
> the update interval of maven-default-http-blocker has elapsed or updates
> are forced. Original error: Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> Downloading from maven-default-http-blocker:
> http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
> [WARNING] Could not transfer metadata
> org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
> maven-default-http-blocker (http://0.0.0.0/): transfer failed for
> http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
> [
>
> I can't understand how to understand which repository in my pom.xml has an
> http and not https repository based on this WARN message.
>
> I searched for  over any pom.xml file and didn't find any
> http repository.
>
> Any help would be greatly appreciated. This is the latest master branch of
> pulsar:
> https://clicktime.symantec.com/15sLvTizaiLPdE4JXAvu7?h=MSjyi1VB4cPbNJsglaLsboIIC2w3PxVFwT0C3b3tJjE==https://clicktime.symantec.com/15sM1HvLio6GkLoeSsGso?h=a4l_3miTQ9Jpp9kBhV4g1A6nK9z3Xc4ThYeLnyNM6NM==https://github.com/apache/pulsar
>
> Thanks,
>
> Asaf
>
> This message is for information purposes only. It is not a recommendation,
> advice, offer or solicitation to buy or sell a product or service, nor an
> official confirmation of any transaction. It is directed at persons who are
> professionals and is intended for the recipient(s) only. It is not directed
> at retail customers. This message is subject to the terms at:
> https://clicktime.symantec.com/15sMWH63UVBqE1mBiDfmX?h=DIqE4zifGAeQprKQUyrnrW7RczY3fI3DZ9CksSTeo3A==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
>
> For important disclosures, please see:
> https://clicktime.symantec.com/15sMRStm1sWEp4wGAfGcu?h=

RE: Question about HTTP blocking WARN

[mark.yagnatinsky]

Sorry, I failed to read your email carefully enough.
Idea: try un-blocking HTTP, and see where it ends up downloading things from.

-Original Message-
From: mark.yagnatin...@barclays.com.INVALID 
 
Sent: Wednesday, December 13, 2023 10:47 AM
To: users@maven.apache.org
Subject: RE: Question about HTTP blocking WARN


CAUTION: This email originated from outside our organisation - 
mark.yagnatin...@barclays.com.INVALID Do not click on links, open attachments, 
or respond unless you recognize the sender and can validate the content is safe.
See release notes for 3.8.1:
https://clicktime.symantec.com/15sM687dBQmsAHdZzRg2R?h=vGmJxLiSHcBmfngK9X2tEIMgJvGX3EQZ2p_ZA8IE8vo==https://maven.apache.org/docs/3.8.1/release-notes.html

-Original Message-
From: Asaf Mesika  
Sent: Wednesday, December 13, 2023 6:07 AM
To: users@maven.apache.org
Subject: Question about HTTP blocking WARN


CAUTION: This email originated from outside our organisation - 
asaf.mes...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hi,

I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building Apache Pulsar.

I get the following WARN:

[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[

I can't understand how to understand which repository in my pom.xml has an http 
and not https repository based on this WARN message.

I searched for  over any pom.xml file and didn't find any http 
repository.

Any help would be greatly appreciated. This is the latest master branch of
pulsar: 
https://clicktime.symantec.com/15sLvTizaiLPdE4JXAvu7?h=MSjyi1VB4cPbNJsglaLsboIIC2w3PxVFwT0C3b3tJjE==https://clicktime.symantec.com/15sM1HvLio6GkLoeSsGso?h=a4l_3miTQ9Jpp9kBhV4g1A6nK9z3Xc4ThYeLnyNM6NM==https://github.com/apache/pulsar

Thanks,

Asaf

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://clicktime.symantec.com/15sMWH63UVBqE1mBiDfmX?h=DIqE4zifGAeQprKQUyrnrW7RczY3fI3DZ9CksSTeo3A==https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
 

For important disclosures, please see: 
https://clicktime.symantec.com/15sMRStm1sWEp4wGAfGcu?h=o9osYrwRO8Nk9pRhDXC5l0HduDMhhY22d5g2I2QVwuc==https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html
 regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://clicktime.symantec.com/15sMAxJue2TTaETVXz5B3?h=_YvyWi2JtvO3gSgRRKCpC0ImVYSd52rWl07eYNFwfaY==https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html
 regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect

RE: Question about HTTP blocking WARN

[mark.yagnatinsky]

See release notes for 3.8.1:
https://maven.apache.org/docs/3.8.1/release-notes.html

-Original Message-
From: Asaf Mesika  
Sent: Wednesday, December 13, 2023 6:07 AM
To: users@maven.apache.org
Subject: Question about HTTP blocking WARN


CAUTION: This email originated from outside our organisation - 
asaf.mes...@gmail.com Do not click on links, open attachments, or respond 
unless you recognize the sender and can validate the content is safe.
Hi,

I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building Apache Pulsar.

I get the following WARN:

[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to transfer 
from http://0.0.0.0/ during a previous attempt. This failure was cached in the 
local repository and resolution will not be reattempted until the update 
interval of maven-default-http-blocker has elapsed or updates are forced. 
Original error: Could not transfer metadata 
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to 
maven-default-http-blocker (http://0.0.0.0/): transfer failed for 
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[

I can't understand how to understand which repository in my pom.xml has an http 
and not https repository based on this WARN message.

I searched for  over any pom.xml file and didn't find any http 
repository.

Any help would be greatly appreciated. This is the latest master branch of
pulsar: 
https://clicktime.symantec.com/15sLvTizaiLPdE4JXAvu7?h=MSjyi1VB4cPbNJsglaLsboIIC2w3PxVFwT0C3b3tJjE==https://github.com/apache/pulsar

Thanks,

Asaf

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

Question about HTTP blocking WARN

[Asaf Mesika]

Hi,

I'm running Apache Maven 3.8.5 (using Maven Wrapper) for building Apache
Pulsar.

I get the following WARN:

[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xmlfailed to
transfer from http://0.0.0.0/ during a previous attempt. This failure was
cached in the local repository and resolution will not be reattempted until
the update interval of maven-default-http-blocker has elapsed or updates
are forced. Original error: Could not transfer metadata
org.mongodb:bson:4.4.1-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.1-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[WARNING] org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xmlfailed to
transfer from http://0.0.0.0/ during a previous attempt. This failure was
cached in the local repository and resolution will not be reattempted until
the update interval of maven-default-http-blocker has elapsed or updates
are forced. Original error: Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/org/mongodb/bson/4.5.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not transfer metadata
org.mongodb:bson:4.4.2-SNAPSHOT/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/org/mongodb/bson/4.4.2-SNAPSHOT/maven-metadata.xml
[

I can't understand how to understand which repository in my pom.xml has an
http and not https repository based on this WARN message.

I searched for  over any pom.xml file and didn't find any
http repository.

Any help would be greatly appreciated. This is the latest master branch of
pulsar: https://github.com/apache/pulsar

Thanks,

Asaf

Re: question on maven dependency scope

[Greg Chabala]

> there will be a common core but i will provide premium
> features as addons. ... what is the best way to achieve my goal?


I would suggest using compile or runtime as the scope, depending on how you
implement the addons, but mark them as optional dependencies.

RE: question on maven dependency scope

[mark.yagnatinsky]

That sounds like it might actually work

-Original Message-
From: Siddharth Jain  
Sent: Sunday, October 1, 2023 8:47 PM
To: Maven Users List 
Subject: question on maven dependency scope


CAUTION: This email originated from outside our organisation - 
siddh...@gmail.com Do not click on links, open attachments, or respond unless 
you recognize the sender and can validate the content is safe.
hello.

https://clicktime.symantec.com/15siFB7xf2QcUHAdxCz1m?h=rHBhQF_TXrl6Mj2r5j5v0vCyG83lV5yoa6fcxP1NDwY==https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html%23Dependency_Scope

   - *provided*
   This is much like compile, but indicates you expect the JDK or a
   container to provide the dependency at runtime. For example, when building
   a web application for the Java Enterprise Edition, you would set the
   dependency on the Servlet API and related Java EE APIs to scope provided 
because
   the web container provides those classes. A dependency with this scope is
   added to the classpath used for compilation and test, but not the runtime
   classpath. It is not transitive.

what does the runtime classpath mean here? does it mean the classpath when 
running the application using the maven-exec-plugin? does it make any 
difference to the maven-assembly-plugin whether scope is provided or not?

context: I am trying to build an application with different levels of 
subscription. there will be a common core but i will provide premium features 
as addons. so I want to treat them as dependencies with provided scope in the 
core and package the application differently depending on the customer's 
subscription level. as the packing into a jar is done with the assembly plugin, 
I would like to know whether it makes any difference to the assembly plugin 
whether the scope is provided or not.

if not, what is the best way to achieve my goal?

thanks.

S.

This message is for information purposes only. It is not a recommendation, 
advice, offer or solicitation to buy or sell a product or service, nor an 
official confirmation of any transaction. It is directed at persons who are 
professionals and is intended for the recipient(s) only. It is not directed at 
retail customers. This message is subject to the terms at: 
https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: 
https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
regarding marketing commentary from Barclays Sales and/or Trading desks, who 
are active market participants; 
https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
regarding our standard terms for Barclays Corporate and Investment Bank where 
we trade with you in principal-to-principal wholesale markets transactions; and 
in respect to Barclays Research, including disclosures relating to specific 
issuers, see: http://publicresearch.barclays.com.
__
 
If you are incorporated or operating in Australia, read these important 
disclosures: 
https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__
For more details about how we use personal information, see our privacy notice: 
https://www.cib.barclays/disclosures/personal-information-use.html. 
__

question on maven dependency scope

[Siddharth Jain]

hello.

https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

   - *provided*
   This is much like compile, but indicates you expect the JDK or a
   container to provide the dependency at runtime. For example, when building
   a web application for the Java Enterprise Edition, you would set the
   dependency on the Servlet API and related Java EE APIs to scope
provided because
   the web container provides those classes. A dependency with this scope is
   added to the classpath used for compilation and test, but not the runtime
   classpath. It is not transitive.

what does the runtime classpath mean here? does it mean the classpath when
running the application using the maven-exec-plugin? does it make any
difference to the maven-assembly-plugin whether scope is provided or not?

context: I am trying to build an application with different levels of
subscription. there will be a common core but i will provide premium
features as addons. so I want to treat them as dependencies with
provided scope in the core and package the application differently
depending on the customer's subscription level. as the packing into a jar
is done with the assembly plugin, I would like to know whether it makes any
difference to the assembly plugin whether the scope is provided or not.

if not, what is the best way to achieve my goal?

thanks.

S.

AW: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Bernhard Schuhmann]

Wondering why no one mentioned https://github.com/highsource/jaxb-tools yet? 
Some good people have resurrected the project after the original maintainer 
passed away. Given the still existing need for the plug-ins, I’m thankful 
someone filled the void and not just created yet another fork of the original 
project…

They’re making good progress to integrate the maven and xjc (former 
jaxb2-basics) plug-ins into one repo and have already shipped version 2.0.x of 
both (available on maven-central). Version 2.0.x is still supporting only JAXB 
2.3, but they’re already working on support for JAXB >= 3…

Thanks

Bernhard


Bernhard Schuhmann
Senior Software Engineer|Jedox
Jedox GmbH
Chief Executive Officer (Geschäftsführer): Florian Winterstein
Place of Business: Freiburg i. Br. | Registry Court: Amtsgericht Freiburg | HRB 
723467
​
​​[TM.V06112018]

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Falko Modler]

I'd recommend https://github.com/patrodyne/hisrc-basicjaxb#hisrc-basicjaxb

Cheers!

Am 24.08.2023 um 20:21 schrieb David Hoffer:

That one works great as a general purpose XJC tool and supports JAXB4 but
unfortunately to use any of the plugin options

-XtoString
-Xequals
-XhashCode
-Xcopyable

Requires the use of jaxb2-basics according to the
docs which is ancient and stuck in JDK8 and prior.  So, not an option for a
JDK17 Java EE 10 application.

If anyone knows of newer plugin extensions that can support JDK17 let me
know.

Thanks,
-David

On Tue, Aug 22, 2023 at 2:46 PM Delany  wrote:


This one has JAXB4 support
https://github.com/phax/maven-jaxb2-plugin
Delany



On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:


I think that is based on:

org.jvnet.jaxb2.maven2
maven-jaxb2-plugin

Which, I can't get to work with JDK17 and to be compatible with the rest

of

my app has to be at Java EE 10.

I'm currently trying to use:

org.codehaus.mojo
jaxb2-maven-plugin
3.1.0

As it's current; seems to support JDK17 Java 10 well.  But it seems they
dropped support for -X argument options.  Or I just can't find how it's
supported.

I have also tried:

org.apache.cxf
cxf-xjc-plugin
4.0.0

And it too is current, supports JDK17 and Java 10.  It does have

extension

support for:

toString
defaultValue

But does not have support for:
equals
hashCode

And those I would really like to have.  Trying to find a way to have all

4

of those options.

-Dave

On Tue, Aug 22, 2023 at 1:31 PM Delany 

wrote:

Try here https://stackoverflow.com/a/32336886/2746335
Delany

On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:


I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17

project.

I'm using version 3.1.0.  I can get it to generate the Java code but

can't

find any way to add support for optional things like:

toString
equals
hashCode
defaultValue

Can someone point me in the right direction on how to add these very

useful

options to the generated code.

Thanks,
-Dave




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

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Delany]

Try this https://github.com/aspan/jaxb2-basics
Delany

On Thu, 24 Aug 2023 at 20:21, David Hoffer  wrote:

> That one works great as a general purpose XJC tool and supports JAXB4 but
> unfortunately to use any of the plugin options
>
> -XtoString
> -Xequals
> -XhashCode
> -Xcopyable
>
> Requires the use of jaxb2-basics according to the
> docs which is ancient and stuck in JDK8 and prior.  So, not an option for a
> JDK17 Java EE 10 application.
>
> If anyone knows of newer plugin extensions that can support JDK17 let me
> know.
>
> Thanks,
> -David
>
> On Tue, Aug 22, 2023 at 2:46 PM Delany  wrote:
>
> > This one has JAXB4 support
> > https://github.com/phax/maven-jaxb2-plugin
> > Delany
> >
> >
> >
> > On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:
> >
> > > I think that is based on:
> > >
> > > org.jvnet.jaxb2.maven2
> > > maven-jaxb2-plugin
> > >
> > > Which, I can't get to work with JDK17 and to be compatible with the
> rest
> > of
> > > my app has to be at Java EE 10.
> > >
> > > I'm currently trying to use:
> > >
> > > org.codehaus.mojo
> > > jaxb2-maven-plugin
> > > 3.1.0
> > >
> > > As it's current; seems to support JDK17 Java 10 well.  But it seems
> they
> > > dropped support for -X argument options.  Or I just can't find how it's
> > > supported.
> > >
> > > I have also tried:
> > >
> > > org.apache.cxf
> > > cxf-xjc-plugin
> > > 4.0.0
> > >
> > > And it too is current, supports JDK17 and Java 10.  It does have
> > extension
> > > support for:
> > >
> > > toString
> > > defaultValue
> > >
> > > But does not have support for:
> > > equals
> > > hashCode
> > >
> > > And those I would really like to have.  Trying to find a way to have
> all
> > 4
> > > of those options.
> > >
> > > -Dave
> > >
> > > On Tue, Aug 22, 2023 at 1:31 PM Delany 
> > wrote:
> > >
> > > > Try here https://stackoverflow.com/a/32336886/2746335
> > > > Delany
> > > >
> > > > On Tue, 22 Aug 2023 at 21:16, David Hoffer 
> wrote:
> > > >
> > > > > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17
> > > project.
> > > > > I'm using version 3.1.0.  I can get it to generate the Java code
> but
> > > > can't
> > > > > find any way to add support for optional things like:
> > > > >
> > > > > toString
> > > > > equals
> > > > > hashCode
> > > > > defaultValue
> > > > >
> > > > > Can someone point me in the right direction on how to add these
> very
> > > > useful
> > > > > options to the generated code.
> > > > >
> > > > > Thanks,
> > > > > -Dave
> > > > >
> > > >
> > >
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[David Hoffer]

That one works great as a general purpose XJC tool and supports JAXB4 but
unfortunately to use any of the plugin options

-XtoString
-Xequals
-XhashCode
-Xcopyable

Requires the use of jaxb2-basics according to the
docs which is ancient and stuck in JDK8 and prior.  So, not an option for a
JDK17 Java EE 10 application.

If anyone knows of newer plugin extensions that can support JDK17 let me
know.

Thanks,
-David

On Tue, Aug 22, 2023 at 2:46 PM Delany  wrote:

> This one has JAXB4 support
> https://github.com/phax/maven-jaxb2-plugin
> Delany
>
>
>
> On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:
>
> > I think that is based on:
> >
> > org.jvnet.jaxb2.maven2
> > maven-jaxb2-plugin
> >
> > Which, I can't get to work with JDK17 and to be compatible with the rest
> of
> > my app has to be at Java EE 10.
> >
> > I'm currently trying to use:
> >
> > org.codehaus.mojo
> > jaxb2-maven-plugin
> > 3.1.0
> >
> > As it's current; seems to support JDK17 Java 10 well.  But it seems they
> > dropped support for -X argument options.  Or I just can't find how it's
> > supported.
> >
> > I have also tried:
> >
> > org.apache.cxf
> > cxf-xjc-plugin
> > 4.0.0
> >
> > And it too is current, supports JDK17 and Java 10.  It does have
> extension
> > support for:
> >
> > toString
> > defaultValue
> >
> > But does not have support for:
> > equals
> > hashCode
> >
> > And those I would really like to have.  Trying to find a way to have all
> 4
> > of those options.
> >
> > -Dave
> >
> > On Tue, Aug 22, 2023 at 1:31 PM Delany 
> wrote:
> >
> > > Try here https://stackoverflow.com/a/32336886/2746335
> > > Delany
> > >
> > > On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:
> > >
> > > > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17
> > project.
> > > > I'm using version 3.1.0.  I can get it to generate the Java code but
> > > can't
> > > > find any way to add support for optional things like:
> > > >
> > > > toString
> > > > equals
> > > > hashCode
> > > > defaultValue
> > > >
> > > > Can someone point me in the right direction on how to add these very
> > > useful
> > > > options to the generated code.
> > > >
> > > > Thanks,
> > > > -Dave
> > > >
> > >
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Delany]

This one has JAXB4 support
https://github.com/phax/maven-jaxb2-plugin
Delany



On Tue, 22 Aug 2023 at 22:04, David Hoffer  wrote:

> I think that is based on:
>
> org.jvnet.jaxb2.maven2
> maven-jaxb2-plugin
>
> Which, I can't get to work with JDK17 and to be compatible with the rest of
> my app has to be at Java EE 10.
>
> I'm currently trying to use:
>
> org.codehaus.mojo
> jaxb2-maven-plugin
> 3.1.0
>
> As it's current; seems to support JDK17 Java 10 well.  But it seems they
> dropped support for -X argument options.  Or I just can't find how it's
> supported.
>
> I have also tried:
>
> org.apache.cxf
> cxf-xjc-plugin
> 4.0.0
>
> And it too is current, supports JDK17 and Java 10.  It does have extension
> support for:
>
> toString
> defaultValue
>
> But does not have support for:
> equals
> hashCode
>
> And those I would really like to have.  Trying to find a way to have all 4
> of those options.
>
> -Dave
>
> On Tue, Aug 22, 2023 at 1:31 PM Delany  wrote:
>
> > Try here https://stackoverflow.com/a/32336886/2746335
> > Delany
> >
> > On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:
> >
> > > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17
> project.
> > > I'm using version 3.1.0.  I can get it to generate the Java code but
> > can't
> > > find any way to add support for optional things like:
> > >
> > > toString
> > > equals
> > > hashCode
> > > defaultValue
> > >
> > > Can someone point me in the right direction on how to add these very
> > useful
> > > options to the generated code.
> > >
> > > Thanks,
> > > -Dave
> > >
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[David Hoffer]

I think that is based on:

org.jvnet.jaxb2.maven2
maven-jaxb2-plugin

Which, I can't get to work with JDK17 and to be compatible with the rest of
my app has to be at Java EE 10.

I'm currently trying to use:

org.codehaus.mojo
jaxb2-maven-plugin
3.1.0

As it's current; seems to support JDK17 Java 10 well.  But it seems they
dropped support for -X argument options.  Or I just can't find how it's
supported.

I have also tried:

org.apache.cxf
cxf-xjc-plugin
4.0.0

And it too is current, supports JDK17 and Java 10.  It does have extension
support for:

toString
defaultValue

But does not have support for:
equals
hashCode

And those I would really like to have.  Trying to find a way to have all 4
of those options.

-Dave

On Tue, Aug 22, 2023 at 1:31 PM Delany  wrote:

> Try here https://stackoverflow.com/a/32336886/2746335
> Delany
>
> On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:
>
> > I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17 project.
> > I'm using version 3.1.0.  I can get it to generate the Java code but
> can't
> > find any way to add support for optional things like:
> >
> > toString
> > equals
> > hashCode
> > defaultValue
> >
> > Can someone point me in the right direction on how to add these very
> useful
> > options to the generated code.
> >
> > Thanks,
> > -Dave
> >
>

Re: JAXB2 Maven Plugin XJC Goal JDK17 Question

[Delany]

Try here https://stackoverflow.com/a/32336886/2746335
Delany

On Tue, 22 Aug 2023 at 21:16, David Hoffer  wrote:

> I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17 project.
> I'm using version 3.1.0.  I can get it to generate the Java code but can't
> find any way to add support for optional things like:
>
> toString
> equals
> hashCode
> defaultValue
>
> Can someone point me in the right direction on how to add these very useful
> options to the generated code.
>
> Thanks,
> -Dave
>

JAXB2 Maven Plugin XJC Goal JDK17 Question

[David Hoffer]

I'm wanting to use the JAXB2 Maven Plugin's XJC goal in a JDK17 project.
I'm using version 3.1.0.  I can get it to generate the Java code but can't
find any way to add support for optional things like:

toString
equals
hashCode
defaultValue

Can someone point me in the right direction on how to add these very useful
options to the generated code.

Thanks,
-Dave

Question on multi-module reactor sorting

[Zhoucheng Li]

Hi all,

I encountered a build issue recently that no one in the team has seen,
which I believe it's caused by multi-thread racing but I can't prove it tbh.

Maven version tested: 3.6.3 & 3.9.1
Java: open-jdk 11

Our project contains multiple modules and  is declared in parent
pom. And let's say if A module depends on B module, then module B is not
explicitly added into the A's pom file.

When multi-thread is turned on (with parameter `-T 1C`,1 thread per core, Apple
M2 silicon), there is a high chance of compilation error (usually saying
class not found).  After turning off multi-threading, `mvn clean install`
is ok but still `mvn dependency:analyze` would always fail.

However, the issue is completely gone once I manually listed B as a
dependency in A's pom file. Note, the actual dependency graph is a bit
complicated so you can imagine there are multiple A-B, A-C, B-C etc pairs.

I have read the page regarding how reactor sorting works (
https://maven.apache.org/guides/mini/guide-multiple-modules.html#reactor-sorting)
so it looks like our current project uses rule 5 only.

But here are the things I don't know for sure:
- if reactor sorting only uses rule5 only, does it mean the build order
would strictly follow the module declaring order in ? If that's
the case, it seems the multi-thread race conditions shouldn't happen. Is my
understanding correct?
- How does dependency:analyze work? Is there documentation I can read? This
always fail and seems it's not related to the `-T 1C` parameter.
- What's the preferred way to manage multi-module dependencies? Is it
better to strictly declare them whenever using the dependencies (rule 1) or
this is no best practice but only different options?

Thanks
Joe

Re: question java 1.7 support

[John Patrick]

Most people and use cases have the Java Home is the same version you put in
source/target/release.

The part I was trying to highlight was, if you set release and have Java
Home and Path to Java 1.7 (as the title of the email indicates), then it
won't work, so you need to use source and target.
If it was a type and the person has Java Home and Path set to Java 17, then
use release.

Also what I posted is the text from the maven compiler plugin.


On Sat, 26 Mar 2022 at 15:05, Alexander Kriegisch 
wrote:

> John Patrick schrieb am 26.03.2022 16:12 (GMT +07:00):
>
> > I thought maven.compiler.release only supports Java 9 and newer (The
> > -release argument for the Java compiler, supported since Java9).
>
> Small correction: The javac compiler option '--release N' exists since
> JDK 9, but you can also compile to older versions. A little overview,
> quickly compiled from what I happen to have installed locally (no 12):
>
>
> javac | --release
> --|--
>9  | 6-9
>   10  | 6-10
>   11  | 6-11
>   13  | 7-13
>   14  | 7-14
>   15  | 7-15
>   16  | 7-16
>   17  | 7-17
>   18  | 7-18
>
>
> BTW, most people around here probably know, but for those who do not:
> '--release N' is **not** the same as '-source N -target N', but also
> ensures that code is cross-compiled not just to the byte code level N
> like with '-target N', but also to the exact JDK API of that version -
> basically a more user-friendly way to set an older JDK as boot classpath
> for compilation, without the need to install extra JDKs or toolchains.
> Each JDK 9+ contains a compressed set of legacy API descriptions
> utilised by '--release N'.
>
> I.e., while the compiler option really just exists since JDK 9, you can
> still target certain older bytecode and/or JDK API versions. And if you
> need really old bytecode targets in a brandnew and well-maintained
> compiler, you can use ECJ. Current version 3.29.0 still supports source
> and target versions as old as 1.3 (and of course up to 18) - a unique
> selling point in comparison to Javac.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: question java 1.7 support

[Alexander Kriegisch]

John Patrick schrieb am 26.03.2022 16:12 (GMT +07:00):

> I thought maven.compiler.release only supports Java 9 and newer (The
> -release argument for the Java compiler, supported since Java9).

Small correction: The javac compiler option '--release N' exists since
JDK 9, but you can also compile to older versions. A little overview,
quickly compiled from what I happen to have installed locally (no 12):


javac | --release
--|--
   9  | 6-9
  10  | 6-10
  11  | 6-11
  13  | 7-13
  14  | 7-14
  15  | 7-15
  16  | 7-16
  17  | 7-17
  18  | 7-18


BTW, most people around here probably know, but for those who do not:
'--release N' is **not** the same as '-source N -target N', but also
ensures that code is cross-compiled not just to the byte code level N
like with '-target N', but also to the exact JDK API of that version -
basically a more user-friendly way to set an older JDK as boot classpath
for compilation, without the need to install extra JDKs or toolchains.
Each JDK 9+ contains a compressed set of legacy API descriptions
utilised by '--release N'.

I.e., while the compiler option really just exists since JDK 9, you can
still target certain older bytecode and/or JDK API versions. And if you
need really old bytecode targets in a brandnew and well-maintained
compiler, you can use ECJ. Current version 3.29.0 still supports source
and target versions as old as 1.3 (and of course up to 18) - a unique
selling point in comparison to Javac.

-- 
Alexander Kriegisch
https://scrum-master.de

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

Re: question java 1.7 support

[John Patrick]

Alexander,
Your email says Java 1.7, your sdkman says 17 and your maven pom says 1.17.

I thought maven.compiler.release only supports Java 9 and newer (The
-release argument for the Java compiler, supported since Java9).

If you are wanting Java 1.7 (released July 2011) then use user properties;
1.7
1.7
also;
delete user property maven.compiler.release
from maven-compiler-plugin configuration, delete source and target.


If you want Java 17 (released September 2021), then use user property;
17
also;
delete user property maven.compiler.source
delete user property maven.compiler.target
from maven-compiler-plugin configuration, delete source and target.

John


On Sat, 26 Mar 2022 at 04:11, Olivier Lamy  wrote:

> On Sat, 26 Mar 2022 at 2:06 pm, Nils Breunese  wrote:
>
> > Olivier Lamy  wrote:
> >
> > > should be 1.7 not 1.17 ;)
> >
> > No, 1.7 is for Java 7. For Java 17 it should be just 17.
>
>
> The email subject says “ question java 1.7 support”
> But yeah should be simply 17
> Use release flag rather than sources and target
>
> >
> >
> > Nils.
> >
> > > On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
> > > alexander.ushakov.em...@gmail.com> wrote:
> > >
> > >> Hello!
> > >>
> > >> I am trying to play with Apache Kafka and craft next pom.xml
> > >>
> > >> ```xml
> > >>
> > >>  > >> xmlns="http://maven.apache.org/POM/4.0.0;
> > >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > >> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> > >>   4.0.0
> > >>   streams.examples
> > >>   streams.examples
> > >>   0.1
> > >>   jar
> > >>   Kafka Streams Demo Application
> > >>   
> > >>
> UTF-8
> > >>  3.1.0
> > >>  1.7.7
> > >>  1.2.17
> > >>  1.17
> > >>   
> > >>   
> > >>  
> > >> apache.snapshots
> > >> Apache Development Snapshot Repository
> > >> 
> > >> https://repository.apache.org/content/repositories/snapshots/
> > >> 
> > >>false
> > >> 
> > >> 
> > >>true
> > >> 
> > >>  
> > >>   
> > >>   
> > >>  
> > >> 
> > >>org.apache.maven.plugins
> > >>maven-compiler-plugin
> > >>3.1
> > >>
> > >>   1.17
> > >>   1.17
> > >>
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >> 
> > >>  
> > >>   
> > >>   
> > >>  
> > >> org.apache.kafka
> > >> kafka-streams
> > >> ${kafka.version}
> > >>  
> > >>  
> > >> org.slf4j
> > >> slf4j-api
> > >> ${slf4j.version}
> > >>  
> > >>  
> > >> org.slf4j
> > >> slf4j-simple
> > >> ${slf4j.version}
> > >>  
> > >>   
> > >>
> > >> ```
> > >>
> > >> command
> > >>
> > >> ```sh
> > >> mvn clean package
> > >> ```
> > >>
> > >> results with error
> > >>
> > >> ```
> > >> [ERROR] Failed to execute goal
> > >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> > >> (default-compile) on project streams.examples: Fatal error compiling:
> > >> error: invalid target release: 1.17 -> [Help 1]
> > >> ```
> > >>
> > >> Java and Maven has been installed through SdkMan. Java 17.
> > >>
> > >> Can someone, please, suggest the solution?
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: question java 1.7 support

[Olivier Lamy]

On Sat, 26 Mar 2022 at 2:06 pm, Nils Breunese  wrote:

> Olivier Lamy  wrote:
>
> > should be 1.7 not 1.17 ;)
>
> No, 1.7 is for Java 7. For Java 17 it should be just 17.


The email subject says “ question java 1.7 support”
But yeah should be simply 17
Use release flag rather than sources and target

>
>
> Nils.
>
> > On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
> > alexander.ushakov.em...@gmail.com> wrote:
> >
> >> Hello!
> >>
> >> I am trying to play with Apache Kafka and craft next pom.xml
> >>
> >> ```xml
> >>
> >>  >> xmlns="http://maven.apache.org/POM/4.0.0;
> >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> >> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> >>   4.0.0
> >>   streams.examples
> >>   streams.examples
> >>   0.1
> >>   jar
> >>   Kafka Streams Demo Application
> >>   
> >>  UTF-8
> >>  3.1.0
> >>  1.7.7
> >>  1.2.17
> >>  1.17
> >>   
> >>   
> >>  
> >> apache.snapshots
> >> Apache Development Snapshot Repository
> >> 
> >> https://repository.apache.org/content/repositories/snapshots/
> >> 
> >>false
> >> 
> >> 
> >>true
> >> 
> >>  
> >>   
> >>   
> >>  
> >> 
> >>org.apache.maven.plugins
> >>maven-compiler-plugin
> >>3.1
> >>
> >>   1.17
> >>   1.17
> >>
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>  
> >>   
> >>   
> >>  
> >> org.apache.kafka
> >> kafka-streams
> >> ${kafka.version}
> >>  
> >>  
> >> org.slf4j
> >> slf4j-api
> >> ${slf4j.version}
> >>  
> >>  
> >> org.slf4j
> >> slf4j-simple
> >> ${slf4j.version}
> >>  
> >>   
> >>
> >> ```
> >>
> >> command
> >>
> >> ```sh
> >> mvn clean package
> >> ```
> >>
> >> results with error
> >>
> >> ```
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> >> (default-compile) on project streams.examples: Fatal error compiling:
> >> error: invalid target release: 1.17 -> [Help 1]
> >> ```
> >>
> >> Java and Maven has been installed through SdkMan. Java 17.
> >>
> >> Can someone, please, suggest the solution?
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: question java 1.7 support

[Nils Breunese]

Olivier Lamy  wrote:

> should be 1.7 not 1.17 ;)

No, 1.7 is for Java 7. For Java 17 it should be just 17.

Nils.

> On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
> alexander.ushakov.em...@gmail.com> wrote:
> 
>> Hello!
>> 
>> I am trying to play with Apache Kafka and craft next pom.xml
>> 
>> ```xml
>> 
>> > xmlns="http://maven.apache.org/POM/4.0.0;
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>>   4.0.0
>>   streams.examples
>>   streams.examples
>>   0.1
>>   jar
>>   Kafka Streams Demo Application
>>   
>>  UTF-8
>>  3.1.0
>>  1.7.7
>>  1.2.17
>>  1.17
>>   
>>   
>>  
>> apache.snapshots
>> Apache Development Snapshot Repository
>> 
>> https://repository.apache.org/content/repositories/snapshots/
>> 
>>false
>> 
>> 
>>true
>> 
>>  
>>   
>>   
>>  
>> 
>>org.apache.maven.plugins
>>maven-compiler-plugin
>>3.1
>>
>>   1.17
>>   1.17
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>  
>>   
>>   
>>  
>> org.apache.kafka
>> kafka-streams
>> ${kafka.version}
>>  
>>  
>> org.slf4j
>> slf4j-api
>> ${slf4j.version}
>>  
>>  
>> org.slf4j
>> slf4j-simple
>> ${slf4j.version}
>>  
>>   
>> 
>> ```
>> 
>> command
>> 
>> ```sh
>> mvn clean package
>> ```
>> 
>> results with error
>> 
>> ```
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
>> (default-compile) on project streams.examples: Fatal error compiling:
>> error: invalid target release: 1.17 -> [Help 1]
>> ```
>> 
>> Java and Maven has been installed through SdkMan. Java 17.
>> 
>> Can someone, please, suggest the solution?
>> 


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

Re: question java 1.7 support

[Olivier Lamy]

should be 1.7 not 1.17 ;)

On Sat, 26 Mar 2022 at 13:48, Alexander Ushakov <
alexander.ushakov.em...@gmail.com> wrote:

> Hello!
>
> I am trying to play with Apache Kafka and craft next pom.xml
>
> ```xml
>
>  xmlns="http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>4.0.0
>streams.examples
>streams.examples
>0.1
>jar
>Kafka Streams Demo Application
>
>   UTF-8
>   3.1.0
>   1.7.7
>   1.2.17
>   1.17
>
>
>   
>  apache.snapshots
>  Apache Development Snapshot Repository
>  
> https://repository.apache.org/content/repositories/snapshots/
>  
> false
>  
>  
> true
>  
>   
>
>
>   
>  
> org.apache.maven.plugins
> maven-compiler-plugin
> 3.1
> 
>1.17
>1.17
> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>   
>
>
>   
>  org.apache.kafka
>  kafka-streams
>  ${kafka.version}
>   
>   
>  org.slf4j
>  slf4j-api
>  ${slf4j.version}
>   
>   
>  org.slf4j
>  slf4j-simple
>  ${slf4j.version}
>   
>
>
> ```
>
> command
>
> ```sh
> mvn clean package
> ```
>
> results with error
>
> ```
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project streams.examples: Fatal error compiling:
> error: invalid target release: 1.17 -> [Help 1]
> ```
>
> Java and Maven has been installed through SdkMan. Java 17.
>
> Can someone, please, suggest the solution?
>

Re: question java 1.7 support

[Nils Breunese]

Alexander Ushakov  wrote:

> 
>org.apache.maven.plugins
>maven-compiler-plugin
>3.1
>
>   1.17
>   1.17
>
> 
> 
> (…)
> 
> results with error
> 
> ```
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> (default-compile) on project streams.examples: Fatal error compiling:
> error: invalid target release: 1.17 -> [Help 1]
> ```
> 
> Java and Maven has been installed through SdkMan. Java 17.
> 
> Can someone, please, suggest the solution?

If you want to use Java 17, you should specify 17 instead of 1.17. Only 
releases up to and including Java 8 are specified as 1.x.

Nils.


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

question java 1.7 support

[Alexander Ushakov]

Hello!

I am trying to play with Apache Kafka and craft next pom.xml

```xml

http://maven.apache.org/POM/4.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
   4.0.0
   streams.examples
   streams.examples
   0.1
   jar
   Kafka Streams Demo Application
   
  UTF-8
  3.1.0
  1.7.7
  1.2.17
  1.17
   
   
  
 apache.snapshots
 Apache Development Snapshot Repository
 
https://repository.apache.org/content/repositories/snapshots/
 
false
 
 
true
 
  
   
   
  
 
org.apache.maven.plugins
maven-compiler-plugin
3.1

   1.17
   1.17

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
   
   
  
 org.apache.kafka
 kafka-streams
 ${kafka.version}
  
  
 org.slf4j
 slf4j-api
 ${slf4j.version}
  
  
 org.slf4j
 slf4j-simple
 ${slf4j.version}
  
   

```

command

```sh
mvn clean package
```

results with error

```
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project streams.examples: Fatal error compiling:
error: invalid target release: 1.17 -> [Help 1]
```

Java and Maven has been installed through SdkMan. Java 17.

Can someone, please, suggest the solution?

Re: Question for Maven Plugin developers/maintainers

[Hervé BOUTEMY]

= the maven-script part of https://maven.apache.org/plugin-tools/index.html

Le mardi 1 février 2022, 09:16:36 CET Tamás Cservenák a écrit :
> Howdy,
> 
> Yes, the reason for this question was to deprecate the "scripting" bit of
> maven-plugin-tools, as many of us did not see such a beast in a while
> 
> T
> 
> On Tue, Feb 1, 2022 at 2:10 AM Manfred Moser 
> 
> wrote:
> > Fair enough and good examples for using beanshell in the pom. My point was
> > mostly that there are alternatives.
> > 
> > Also from all I understand Tamás asked about implementing part of a plugin
> > in beanshell. That is what you are
> > avoiding by doing it in the POM. And if you were to implement a plugin I
> > would assume would also choose Java.
> > I know I would ;-)
> > 
> > 
> > Manfred
> > 
> > Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):
> > > I am replying to Manfred rather than to Tamás, because I am only
> > > contributing to one plugin, and it is not using any Beanshell stuff. But
> > > I do use Beanshell scripting in a few projects where it is difficult too
> > > avoid, because I have not found any proper plugins to do what I need.
> > > 
> > > Examples include:
> > >   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > >   
> > >  bsh-property, in order to unpack certain classes from Java 9+ JREs,
> > >  using the jimage executable. I am doing this in order to instrument
> > >  same classes and then prepend them to the bootclasspath using
> > >  '--path-module' in some situations. If Maven JMOD Plugin was not
> > >  dead, maybe that would be an alternative. But today it is not. You
> > >  cannot do a lot with that plugin. Besides, for the Java 8 profile
> > >  in the same project, I use Antrun with a simple unzip task in order
> > >  to extract the same classes from tools.jar. That is easier, no
> > >  extra BeanShell scripting needed.
> > >   
> > >   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> > >   
> > >  bsh-property, in order to create a marker file after some expensive
> > >  steps (downloading and unpacking certain dependencies in order to
> > >  create a specific directory structure), so that in later builds a
> > >  file-based property does not activate the same profile again,
> > >  avoiding the downloading and unpacking in later builds. Why I am
> > >  doing that is complicated. Basically, it is because not all the
> > >  files I am downloading are available on Maven Central, so I cannot
> > >  simply use the Dependency plugin.
> > > 
> > > An alternative to Beanshell would be Groovy scripting in the above
> > > cases, but pulling in heavy Groovy stuff for a little script in projects
> > > which otherwise do not use Groovy seems to be a bit costly.
> > > 
> > > So Beanshell as such might be dead to some people, but even I who
> > > otherwise claims to hate scripted builds cannot avoid it sometimes,
> > > basically because I am too lazy to write my own Maven plugins, because I
> > > do not wish to learn how to do so. Sometimes I just want to get
> > > something done and usually have tried 5 other ways to solve the same
> > > problem before yielding and resorting to Beanshell inside a POM.
> > > 
> > > --
> > > Alexander Kriegisch
> > > https://scrum-master.de
> > > 
> > > Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> > >> I think beanshell is long dead. Any plugin that uses it would be for a
> > >> very old Maven version and would need a lot of work when upgrading. So
> > >> we should be okay to deprecate
> > >> 
> > >> And in terms of ANT .. if there are any out there.. similar things
> > >> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> > >> is available as escape hatch as well.
> > >> 
> > >> And there is also
> > >> https://maven.apache.org/plugins/maven-scripting-plugin/
> > >> 
> > >> So overall.. I would say we are ok to deprecate that support.
> > >> 
> > >> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
> > >>> We'd like to get some feedback from anyone who implemented,
> > >>> maintained or plans to implement a Maven Plugin (Mojo):
> > >>> 
> > >>> Did any of you see a Ma

Re: Question for Maven Plugin developers/maintainers

[Tamás Cservenák]

Howdy,

Yes, the reason for this question was to deprecate the "scripting" bit of
maven-plugin-tools, as many of us did not see such a beast in a while

T

On Tue, Feb 1, 2022 at 2:10 AM Manfred Moser 
wrote:

> Fair enough and good examples for using beanshell in the pom. My point was
> mostly that there are alternatives.
>
> Also from all I understand Tamás asked about implementing part of a plugin
> in beanshell. That is what you are
> avoiding by doing it in the POM. And if you were to implement a plugin I
> would assume would also choose Java.
> I know I would ;-)
>
>
> Manfred
> Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):
>
> > I am replying to Manfred rather than to Tamás, because I am only
> > contributing to one plugin, and it is not using any Beanshell stuff. But
> > I do use Beanshell scripting in a few projects where it is difficult too
> > avoid, because I have not found any proper plugins to do what I need.
> > Examples include:
> >
> >   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> >  bsh-property, in order to unpack certain classes from Java 9+ JREs,
> >  using the jimage executable. I am doing this in order to instrument
> >  same classes and then prepend them to the bootclasspath using
> >  '--path-module' in some situations. If Maven JMOD Plugin was not
> >  dead, maybe that would be an alternative. But today it is not. You
> >  cannot do a lot with that plugin. Besides, for the Java 8 profile
> >  in the same project, I use Antrun with a simple unzip task in order
> >  to extract the same classes from tools.jar. That is easier, no
> >  extra BeanShell scripting needed.
> >
> >   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
> >  bsh-property, in order to create a marker file after some expensive
> >  steps (downloading and unpacking certain dependencies in order to
> >  create a specific directory structure), so that in later builds a
> >  file-based property does not activate the same profile again,
> >  avoiding the downloading and unpacking in later builds. Why I am
> >  doing that is complicated. Basically, it is because not all the
> >  files I am downloading are available on Maven Central, so I cannot
> >  simply use the Dependency plugin.
> >
> > An alternative to Beanshell would be Groovy scripting in the above
> > cases, but pulling in heavy Groovy stuff for a little script in projects
> > which otherwise do not use Groovy seems to be a bit costly.
> >
> > So Beanshell as such might be dead to some people, but even I who
> > otherwise claims to hate scripted builds cannot avoid it sometimes,
> > basically because I am too lazy to write my own Maven plugins, because I
> > do not wish to learn how to do so. Sometimes I just want to get
> > something done and usually have tried 5 other ways to solve the same
> > problem before yielding and resorting to Beanshell inside a POM.
> >
> > --
> > Alexander Kriegisch
> > https://scrum-master.de
> >
> >
> > Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> >
> >> I think beanshell is long dead. Any plugin that uses it would be for a
> >> very old Maven version and would need a lot of work when upgrading. So
> >> we should be okay to deprecate
> >>
> >> And in terms of ANT .. if there are any out there.. similar things
> >> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> >> is available as escape hatch as well.
> >>
> >> And there is also
> >> https://maven.apache.org/plugins/maven-scripting-plugin/
> >>
> >> So overall.. I would say we are ok to deprecate that support.
> >>
> >>
> >> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
> >>
> >>> We'd like to get some feedback from anyone who implemented,
> >>> maintained or plans to implement a Maven Plugin (Mojo):
> >>>
> >>> Did any of you see a Maven Plugin that is NOT implemented in Java
> >>> (but uses Ant or Beanshell scripting)?
> >>>
> >>> Currently implementing Maven Plugins with these scripting solutions
> >>> is possible, we are not aware of any uses of it. Hence, we would like
> >>> to deprecate support for these (naturally, based on user responses).
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Question for Maven Plugin developers/maintainers

[Manfred Moser]

Fair enough and good examples for using beanshell in the pom. My point was 
mostly that there are alternatives.

Also from all I understand Tamás asked about implementing part of a plugin in 
beanshell. That is what you are 
avoiding by doing it in the POM. And if you were to implement a plugin I would 
assume would also choose Java.
I know I would ;-) 


Manfred
Alexander Kriegisch wrote on 2022-01-31 16:57 (GMT -08:00):

> I am replying to Manfred rather than to Tamás, because I am only
> contributing to one plugin, and it is not using any Beanshell stuff. But
> I do use Beanshell scripting in a few projects where it is difficult too
> avoid, because I have not found any proper plugins to do what I need.
> Examples include:
> 
>   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
>  bsh-property, in order to unpack certain classes from Java 9+ JREs,
>  using the jimage executable. I am doing this in order to instrument
>  same classes and then prepend them to the bootclasspath using
>  '--path-module' in some situations. If Maven JMOD Plugin was not
>  dead, maybe that would be an alternative. But today it is not. You
>  cannot do a lot with that plugin. Besides, for the Java 8 profile
>  in the same project, I use Antrun with a simple unzip task in order
>  to extract the same classes from tools.jar. That is easier, no
>  extra BeanShell scripting needed.
> 
>   -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
>  bsh-property, in order to create a marker file after some expensive
>  steps (downloading and unpacking certain dependencies in order to
>  create a specific directory structure), so that in later builds a
>  file-based property does not activate the same profile again,
>  avoiding the downloading and unpacking in later builds. Why I am
>  doing that is complicated. Basically, it is because not all the
>  files I am downloading are available on Maven Central, so I cannot
>  simply use the Dependency plugin.
> 
> An alternative to Beanshell would be Groovy scripting in the above
> cases, but pulling in heavy Groovy stuff for a little script in projects
> which otherwise do not use Groovy seems to be a bit costly.
> 
> So Beanshell as such might be dead to some people, but even I who
> otherwise claims to hate scripted builds cannot avoid it sometimes,
> basically because I am too lazy to write my own Maven plugins, because I
> do not wish to learn how to do so. Sometimes I just want to get
> something done and usually have tried 5 other ways to solve the same
> problem before yielding and resorting to Beanshell inside a POM.
> 
> -- 
> Alexander Kriegisch
> https://scrum-master.de
> 
> 
> Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):
> 
>> I think beanshell is long dead. Any plugin that uses it would be for a
>> very old Maven version and would need a lot of work when upgrading. So
>> we should be okay to deprecate
>> 
>> And in terms of ANT .. if there are any out there.. similar things
>> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
>> is available as escape hatch as well.
>> 
>> And there is also
>> https://maven.apache.org/plugins/maven-scripting-plugin/
>> 
>> So overall.. I would say we are ok to deprecate that support.
>> 
>> 
>> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
>> 
>>> We'd like to get some feedback from anyone who implemented,
>>> maintained or plans to implement a Maven Plugin (Mojo):
>>> 
>>> Did any of you see a Maven Plugin that is NOT implemented in Java
>>> (but uses Ant or Beanshell scripting)?
>>> 
>>> Currently implementing Maven Plugins with these scripting solutions
>>> is possible, we are not aware of any uses of it. Hence, we would like
>>> to deprecate support for these (naturally, based on user responses).
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 

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

Re: Question for Maven Plugin developers/maintainers

[Alexander Kriegisch]

I am replying to Manfred rather than to Tamás, because I am only
contributing to one plugin, and it is not using any Beanshell stuff. But
I do use Beanshell scripting in a few projects where it is difficult too
avoid, because I have not found any proper plugins to do what I need.
Examples include:

  -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
 bsh-property, in order to unpack certain classes from Java 9+ JREs,
 using the jimage executable. I am doing this in order to instrument
 same classes and then prepend them to the bootclasspath using
 '--path-module' in some situations. If Maven JMOD Plugin was not
 dead, maybe that would be an alternative. But today it is not. You
 cannot do a lot with that plugin. Besides, for the Java 8 profile
 in the same project, I use Antrun with a simple unzip task in order
 to extract the same classes from tools.jar. That is easier, no
 extra BeanShell scripting needed.

  -- Using org.codehaus.mojo:build-helper-maven-plugin, goal
 bsh-property, in order to create a marker file after some expensive
 steps (downloading and unpacking certain dependencies in order to
 create a specific directory structure), so that in later builds a
 file-based property does not activate the same profile again,
 avoiding the downloading and unpacking in later builds. Why I am
 doing that is complicated. Basically, it is because not all the
 files I am downloading are available on Maven Central, so I cannot
 simply use the Dependency plugin.

An alternative to Beanshell would be Groovy scripting in the above
cases, but pulling in heavy Groovy stuff for a little script in projects
which otherwise do not use Groovy seems to be a bit costly.

So Beanshell as such might be dead to some people, but even I who
otherwise claims to hate scripted builds cannot avoid it sometimes,
basically because I am too lazy to write my own Maven plugins, because I
do not wish to learn how to do so. Sometimes I just want to get
something done and usually have tried 5 other ways to solve the same
problem before yielding and resorting to Beanshell inside a POM.

-- 
Alexander Kriegisch
https://scrum-master.de


Manfred Moser schrieb am 01.02.2022 05:12 (GMT +07:00):

> I think beanshell is long dead. Any plugin that uses it would be for a
> very old Maven version and would need a lot of work when upgrading. So
> we should be okay to deprecate
> 
> And in terms of ANT .. if there are any out there.. similar things
> will apply and https://maven.apache.org/plugins/maven-antrun-plugin/
> is available as escape hatch as well.
> 
> And there is also
> https://maven.apache.org/plugins/maven-scripting-plugin/
> 
> So overall.. I would say we are ok to deprecate that support.
> 
> 
> Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):
> 
>> We'd like to get some feedback from anyone who implemented,
>> maintained or plans to implement a Maven Plugin (Mojo):
>> 
>> Did any of you see a Maven Plugin that is NOT implemented in Java
>> (but uses Ant or Beanshell scripting)?
>> 
>> Currently implementing Maven Plugins with these scripting solutions
>> is possible, we are not aware of any uses of it. Hence, we would like
>> to deprecate support for these (naturally, based on user responses).

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

Re: Question for Maven Plugin developers/maintainers

[Manfred Moser]

I think beanshell is long dead. Any plugin that uses it would be for a very old 
Maven version and would need a lot of work when upgrading. So we should be okay 
to deprecate

And in terms of ANT .. if there are any out there.. similar things will apply 
and https://maven.apache.org/plugins/maven-antrun-plugin/ is available as 
escape hatch as well. 

And there is also https://maven.apache.org/plugins/maven-scripting-plugin/

So overall.. I would say we are ok to deprecate that support.

manfred

Tamás Cservenák wrote on 2022-01-28 05:52 (GMT -08:00):

> Howdy,
> 
> We'd like to get some feedback from anyone who implemented, maintained or
> plans to implement a Maven Plugin (Mojo):
> 
> Did any of you see a Maven Plugin that is NOT implemented in Java (but uses
> Ant or Beanshell scripting)?
> 
> Currently implementing Maven Plugins with these scripting solutions is
> possible, we are not aware of any uses of it. Hence, we would like to
> deprecate support for these (naturally, based on user responses).
> 
> Thanks in advance
> T
> 

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

Re: Question for Maven Plugin developers/maintainers

[Maarten Mulders]

On 28/01/2022 14:52, Tamás Cservenák wrote:


Howdy,

We'd like to get some feedback from anyone who implemented, maintained or
plans to implement a Maven Plugin (Mojo):

Did any of you see a Maven Plugin that is NOT implemented in Java (but uses
Ant or Beanshell scripting)?


If I recall correctly, I once saw something like that: an in-house 
developed Maven Plugin that leveraged Ant to do packaging of Tibco 
Business Works solution projects. Unfortunately, I don't have any 
contacts over there who I could ping to verify.



Currently implementing Maven Plugins with these scripting solutions is
possible, we are not aware of any uses of it. Hence, we would like to
deprecate support for these (naturally, based on user responses).


I would not consider the above a blocker for us to deprecate and 
eventually remove.



Thanks in advance
T


Maarten

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

Re: Question for Maven Plugin developers/maintainers

[Karl Heinz Marbaise]

On 28.01.22 14:52, Tamás Cservenák wrote:

Howdy,

We'd like to get some feedback from anyone who implemented, maintained or
plans to implement a Maven Plugin (Mojo):

Did any of you see a Maven Plugin that is NOT implemented in Java (but uses
Ant or Beanshell scripting)?


No...


Currently implementing Maven Plugins with these scripting solutions is
possible, we are not aware of any uses of it. Hence, we would like to
deprecate support for these (naturally, based on user responses).


Yes please.


Kind regards
Karl Heinz Marbaise

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

Question for Maven Plugin developers/maintainers

[Tamás Cservenák]

Howdy,

We'd like to get some feedback from anyone who implemented, maintained or
plans to implement a Maven Plugin (Mojo):

Did any of you see a Maven Plugin that is NOT implemented in Java (but uses
Ant or Beanshell scripting)?

Currently implementing Maven Plugins with these scripting solutions is
possible, we are not aware of any uses of it. Hence, we would like to
deprecate support for these (naturally, based on user responses).

Thanks in advance
T

Re: Question on dependencies not listed by the maven dependency:tree command

[Alexander Kriegisch]

It includes Log4J with scope 'provided'. You can see it in the POM, and
it is also listed in a separate category on the mvnrepository.com info
page.

-- 
Alexander Kriegisch
https://scrum-master.de

Bhagyasri K schrieb am 05.01.2022 17:57 (GMT +07:00):

> Hello,
> 
> I am using *pax-logging-log4j2*  as a direct dependency in my pom.xml. The
> artifact page has log4j2 as one of the dependencies as per mavenrepository
> .
> But when I run the mvn dependency:tree command, I am not seeing log4j2 as
> the transitive dependency. Can someone please help me understand the reason
> for this?
> 
> pom.xml:
> 
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
>   4.0.0
>   com.bcdevops.eng
>   log4j-java-project
>   jar
>   1.0-SNAPSHOT
>   log4j-java-project
>   http://maven.apache.org
>   
> 
> org.ops4j.pax.logging
> pax-logging-log4j2
> 1.10.2
> 
> 
>   
> 
> 
> mvn dependency:tree command output:
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
> 
> [INFO] Building log4j-java-project 1.0-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @
> log4j-java-project ---
> [INFO] com.bcdevops.eng:log4j-java-project:jar:1.0-SNAPSHOT
> [INFO] \- org.ops4j.pax.logging:pax-logging-log4j2:jar:1.10.2:compile
> [INFO]\- org.ops4j.pax.logging:pax-logging-api:jar:1.10.2:compile
> [INFO]
> 
> [INFO] BUILD SUCCESS
> 
> Thanks,
> Bhagyasri.
> 

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

Question on dependencies not listed by the maven dependency:tree command

[Bhagyasri K]

Hello,

I am using *pax-logging-log4j2*  as a direct dependency in my pom.xml. The
artifact page has log4j2 as one of the dependencies as per mavenrepository
.
But when I run the mvn dependency:tree command, I am not seeing log4j2 as
the transitive dependency. Can someone please help me understand the reason
for this?

pom.xml:

http://maven.apache.org/POM/4.0.0; xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;>
  4.0.0
  com.bcdevops.eng
  log4j-java-project
  jar
  1.0-SNAPSHOT
  log4j-java-project
  http://maven.apache.org
  

org.ops4j.pax.logging
pax-logging-log4j2
1.10.2


  


mvn dependency:tree command output:
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building log4j-java-project 1.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @
log4j-java-project ---
[INFO] com.bcdevops.eng:log4j-java-project:jar:1.0-SNAPSHOT
[INFO] \- org.ops4j.pax.logging:pax-logging-log4j2:jar:1.10.2:compile
[INFO]\- org.ops4j.pax.logging:pax-logging-api:jar:1.10.2:compile
[INFO]

[INFO] BUILD SUCCESS

Thanks,
Bhagyasri.

Re: Dumb question: How to deploy a command line app?

[Anders Hammar]

One can also use the assembly plugin [1] to create a distributable file
that contains all this. That's what I would do.
The standard build process will only build the artifact and put it in the
maven repo, which is what you're seeing currently.

[1] https://maven.apache.org/plugins/maven-assembly-plugin/

/Anders

On Thu, Sep 23, 2021 at 8:11 AM Mantas Gridinas  wrote:

> Use dependencies plugin and copy-dependencies goal. This will copy over all
> of your dependencies into target/dependency folder. .m2 catalog already
> contains your dependencies but in reapective subfolders. Ex. foo.bar:parser
> would be under .m2/repository/foo/bar/parser
>
> On Thu, Sep 23, 2021, 09:00 Bruno Melloni  wrote:
>
> > Given that the whole point of using Maven is to "not have to worry about
> > dependencies" I am having the most ironic (and probably trivial) problem:
> >
> > - Using Maven in Eclipse.
> >
> > - I wrote a very simple utility.  It builds as part of a JAR that will
> > normally be used by other apps, but this utility can be executed from
> > the command line.
> >
> > - So, to run the utility on a server I did a RunAs/Maven/Install.  It
> > placed the JAR in the expected .m2 location but... none of the JARs it
> > depends on are there.
> >
> >
> > How do I tell Eclipse to run a Maven Install that puts *everything*
> > needed by the project to run in one folder or folder tree?
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Dumb question: How to deploy a command line app?

[Mantas Gridinas]

Use dependencies plugin and copy-dependencies goal. This will copy over all
of your dependencies into target/dependency folder. .m2 catalog already
contains your dependencies but in reapective subfolders. Ex. foo.bar:parser
would be under .m2/repository/foo/bar/parser

On Thu, Sep 23, 2021, 09:00 Bruno Melloni  wrote:

> Given that the whole point of using Maven is to "not have to worry about
> dependencies" I am having the most ironic (and probably trivial) problem:
>
> - Using Maven in Eclipse.
>
> - I wrote a very simple utility.  It builds as part of a JAR that will
> normally be used by other apps, but this utility can be executed from
> the command line.
>
> - So, to run the utility on a server I did a RunAs/Maven/Install.  It
> placed the JAR in the expected .m2 location but... none of the JARs it
> depends on are there.
>
>
> How do I tell Eclipse to run a Maven Install that puts *everything*
> needed by the project to run in one folder or folder tree?
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Dumb question: How to deploy a command line app?

[Bruno Melloni]

Given that the whole point of using Maven is to "not have to worry about 
dependencies" I am having the most ironic (and probably trivial) problem:


- Using Maven in Eclipse.

- I wrote a very simple utility.  It builds as part of a JAR that will 
normally be used by other apps, but this utility can be executed from 
the command line.


- So, to run the utility on a server I did a RunAs/Maven/Install.  It 
placed the JAR in the expected .m2 location but... none of the JARs it 
depends on are there.



How do I tell Eclipse to run a Maven Install that puts *everything* 
needed by the project to run in one folder or folder tree?



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

Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users

[Bernd Eckenfels]

If you want to deploy a pre-configured ~/.m2/settings.xml you can do that 
perfectly fine with ansible, just configure it to generate missing parent 
directories. It is normal that dot files/dirs in user directory are created 
only on first use. This is not specific to RedHat, and there is also nothing 
special to the directory, just create it as needed and make sure it has the 
correct owner and permission.

We have good experiences with doing that in a developer workplace provisioning, 
but as mention by others we would not force ancient versions upon developers.

BTW you really need a internal repository Server anyway, if you have that you 
can also use it to download the actual maven archive for installation.

Gruss
Bernd

--
http://bernd.eckenfels.net

Von: christopher.mil...@gd-ms.com 
Gesendet: Thursday, August 19, 2021 6:43:34 PM
An: Maven Users List 
Betreff: RE: Question on installing Maven from Red Hat (RHEL8), missing .m2 
directory for users



Thanks for the reply.

I've worked with different version of RHEL for sometimes now and its my 
understanding that Red Hat packages older versions of software because they 
know it "should" work out of the box.

Forgot to mention, this is a air-gapped environment, so its hard to get things 
in and out of it, so going with the Maven release from Red Hat maybe our only 
option, but I want to test a tarball in a virtualized environment, see how that 
works too.



-Original Message-
From: Michael Osipov 
Sent: Wednesday, August 18, 2021 2:15 PM
To: users@maven.apache.org
Subject: Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 
directory for users


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

Please note that:

Am 2021-08-18 um 17:44 schrieb christopher.mil...@gd-ms.com:
> [user_a@rhel8-maven3 bin]$ mvn --version Apache Maven 3.5.4 (Red Hat
> 3.5.4-5)
   ^^^
Custom distributions are discouraged and not supported by us.

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



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

RE: Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users

[christopher.mil...@gd-ms.com]

Thanks for the reply. 

I've worked with different version of RHEL for sometimes now and its my 
understanding that Red Hat packages older versions of software because they 
know it "should" work out of the box. 

Forgot to mention, this is a air-gapped environment, so its hard to get things 
in and out of it, so going with the Maven release from Red Hat maybe our only 
option, but I want to test a tarball in a virtualized environment, see how that 
works too. 



-Original Message-
From: Michael Osipov  
Sent: Wednesday, August 18, 2021 2:15 PM
To: users@maven.apache.org
Subject: Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 
directory for users


External E-mail --- CAUTION: This email originated from outside GDMS. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.

Please note that:

Am 2021-08-18 um 17:44 schrieb christopher.mil...@gd-ms.com:
> [user_a@rhel8-maven3 bin]$ mvn --version Apache Maven 3.5.4 (Red Hat 
> 3.5.4-5)
   ^^^
Custom distributions are discouraged and not supported by us.

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



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

Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users

[Michael Osipov]

Please note that:

Am 2021-08-18 um 17:44 schrieb christopher.mil...@gd-ms.com:

[user_a@rhel8-maven3 bin]$ mvn --version
Apache Maven 3.5.4 (Red Hat 3.5.4-5)

  ^^^
Custom distributions are discouraged and not supported by us.

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

Re: Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users

[Greg Chabala]

The .m2 directory will be created automatically on first use, as I recall.
A non-trivial command that pulls some artifacts should be enough. You would
only be concerned with creating it yourself if you need to set up specific
values in settings.xml, which is your responsibility to create if needed.

The bigger concern is that your Red Hat package is so old.
https://maven.apache.org/docs/history.html The first time you have an issue
that requires technical help, people will ask you to try the current
version.

If you're going through the effort of making an Ansible Playbook, you might
as well install the current version from a tarball.

Also, as Maven falls under the umbrella of 'developer tools', one would
usually encourage developers to install their own tooling as needed. I
would be displeased if my workplace wanted to standardize on a three year
old version of Maven and script its installation for me.

On Wed, Aug 18, 2021 at 10:44 AM christopher.mil...@gd-ms.com <
christopher.mil...@gd-ms.com> wrote:

>
>
> Hi, this is on RHEL8, trying to standardized on how we install Maven where
> I work, so it's the same for each user.  Make it easy for setup and
> troubleshoot.
>
> From a RHEL8 workstation, I'm running the following command, as we have a
> repository to pull from:
>
>
> dnf install maven -y
>
>
> DNF pulls in all dependencies and installs successfully (we are sticking
> with Red Hat packages as to keep things as simple as possible), as I can
> confirm this with the following:
>
>
> [user_a@rhel8-maven3 bin]$ mvn --version
> Apache Maven 3.5.4 (Red Hat 3.5.4-5)
> Maven home: /usr/share/maven
> Java version: 1.8.0_282, vendor: Red Hat, Inc., runtime:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-4.el8.x86_64/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "4.18.0-305.el8.x86_64", arch: "amd64", family:
> "unix"
> [user_a@rhel8-maven3 bin]$
>
>
> However it didn't create a .m2 directory for any of the users.  Will this
> have to be created manually?  Along with creating the settings.xml file?  I
> didn't see anything in the documentation on how to create .m2.
>
> Our end goal is to create an Ansible Playbook to automate this install as
> well and want to have the correct steps.
>
> Thanks
>
>
>

Question on installing Maven from Red Hat (RHEL8), missing .m2 directory for users

[christopher.mil...@gd-ms.com]

Hi, this is on RHEL8, trying to standardized on how we install Maven where I 
work, so it's the same for each user.  Make it easy for setup and troubleshoot.

>From a RHEL8 workstation, I'm running the following command, as we have a 
>repository to pull from:


dnf install maven -y


DNF pulls in all dependencies and installs successfully (we are sticking with 
Red Hat packages as to keep things as simple as possible), as I can confirm 
this with the following:


[user_a@rhel8-maven3 bin]$ mvn --version
Apache Maven 3.5.4 (Red Hat 3.5.4-5)
Maven home: /usr/share/maven
Java version: 1.8.0_282, vendor: Red Hat, Inc., runtime: 
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.282.b08-4.el8.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.18.0-305.el8.x86_64", arch: "amd64", family: 
"unix"
[user_a@rhel8-maven3 bin]$


However it didn't create a .m2 directory for any of the users.  Will this have 
to be created manually?  Along with creating the settings.xml file?  I didn't 
see anything in the documentation on how to create .m2.

Our end goal is to create an Ansible Playbook to automate this install as well 
and want to have the correct steps.

Thanks

Maven Compiler + Annotations processor question

[Arnaud Héritier]

Hi team,

  That's a long time I didn't play with annotations processors and there is
something I don't understand.
  Maybe I get it wrong with annotations processors and/or with Maven
  What I want to accomplish is very similar to this post on stackoverflow:
https://cloudbees.atlassian.net/wiki/spaces/CE/blog/1294434773/Info%2BA%2Bnew%2Bhome%2Bfor%2BFastThread
  To summarise we have an annotation processor that we want to run the
module sources to generate automatically some tests.
  The problem is in the maven configuration. The proposed solution should
work from my POV:




org.apache.maven.plugins
maven-compiler-plugin



generate-test-classes

compile




org.my.UnitTestGenerationProcessor


${project.build.directory}/generated-test-sources/test-annotations

only






org.codehaus.mojo
build-helper-maven-plugin


add-test-source
generate-test-sources

add-test-source




${project.build.directory}/generated-test-sources/test-annotations








But it doesn't work and the call of generate-test-classes tries to compile
the generated test sources (even if proc=only) and it fails because the
Test classes are missing the test dependencies.

Any idea of what we could do wrong ?

-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Re: [compiler-plugin] Question about multiple compiler executions

[Lasse Lindqvist]

I think it is unintended. We have had the annotations processed in the same
main execution. But I have to say that some annotation processors such as
Lombok have caused problems with IDEs not functioning properly.

to 2. huhtik. 2020 klo 15.06 Benjamin Marwell (bmarw...@gmail.com)
kirjoitti:

> Hi everyone,
>
> In a project, I currently configured three executions of the maven
> compiler plugin.
>
> 1. proc:only, generate annotations for org.immutable
> 2. proc:only, generate annotations for hibernate-static-metamodel (not
> all modules)
> 3. proc:none, i.e. compile everything.
>
> For this to work, I have to set
> false to use
> incremental compilation (reversed property, this is a known issue).
> On the shell it works just fine.
>
> My question is: Is this setup "using maven the intended way"? I am
> asking, because no IDE supports this right now. Each time I touch a
> file which will be processed by an annotation processor, I need to
> execute "mvn clean compile -DskipTests". Clean IS necessary, because
> maven does not know that the resulting output of the generated sources
> will be different. Setting useIncrementalCompilation=true (or not
> setting it) will also not work, they will just overwrite each other -
> the third compilation execution will not find any generated sources.
>
> I would be happy to hear your experiences with this topic.
>
> Thanks,
> Ben
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[compiler-plugin] Question about multiple compiler executions

[Benjamin Marwell]

Hi everyone,

In a project, I currently configured three executions of the maven
compiler plugin.

1. proc:only, generate annotations for org.immutable
2. proc:only, generate annotations for hibernate-static-metamodel (not
all modules)
3. proc:none, i.e. compile everything.

For this to work, I have to set
false to use
incremental compilation (reversed property, this is a known issue).
On the shell it works just fine.

My question is: Is this setup "using maven the intended way"? I am
asking, because no IDE supports this right now. Each time I touch a
file which will be processed by an annotation processor, I need to
execute "mvn clean compile -DskipTests". Clean IS necessary, because
maven does not know that the resulting output of the generated sources
will be different. Setting useIncrementalCompilation=true (or not
setting it) will also not work, they will just overwrite each other -
the third compilation execution will not find any generated sources.

I would be happy to hear your experiences with this topic.

Thanks,
Ben

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

Re: Question about Apache Parent Pom and source-release-assembly

[Hervé BOUTEMY]

Le samedi 18 janvier 2020, 23:37:04 CET Enrico Olivelli a écrit :
> > yes, it's tempting to do so, but if this parameter is not documented, it's
> > because it's read-only then is not expected to be overridden. And given
> > you're
> > not the first one I saw to override it, MNG-5001 is absolutely required
> 
> Just for info my IDE suggested that there is such parameter.
> Maybe the IDE should not suggest to override read-only parameters
oh, you found the parameter because an IDE told you about it? that's sad :)
yes, please report to the IDE maintainers that this should not happen, and 
will fail in the future...

Regards,

Hervé

> 
> Not a big deal, if we enforce 'read only' then the build will fail
> 
> > >  I could change finalName root property without changing the artifactid
> > 
> > no, you can't, and this is for a reason: in the repository, every attached
> > sub-artifact is expected to have the same artifactId, then have a filename
> > starting with the artifactId. This is key to our convention, sorry.
> > 
> > Looking at Zookeeper distribution [1], what about renaming
> > zookeeper-assembly
> > module to apache-zookeeper and publish its content to central? It would be
> > the
> > equivalent to our apache-maven module.
> > And given you need a specific assembly for the bin distribution, this
> > would not
> > be an issue, isn't it?
> 
> I will try, thank you for this good suggestion
> 
> 
> Enrico
> 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://www-us.apache.org/dist/zookeeper/current/
> > 
> > > Thanks for your help
> > > Enrico
> > > 
> > > Il sab 18 gen 2020, 12:46 Hervé BOUTEMY  ha
> > 
> > scritto:
> > > > WARNING: finalName is read-only
> > > > There is a bug in Maven 3 that does not check, but this will be fixed
> > 
> > in
> > 
> > > > Maven
> > > > 3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure
> > > > 
> > > > Either you should rename parent artifact to zookeeper, then you'll
> > 
> > have to
> > 
> > > > rename the current zookeeper to zookeeper-server for example.
> > > > Either you're stuck with your specific assembly.
> > > > 
> > > > In Maven itself, we have 2 cases:
> > > > - Maven core, that has a specific assembly in apache-maven module
> > > > where
> > > > source-
> > > > release is published [2] with a specific src+bin and zip+tar.gz output
> > > > - every other multi-module project (surefire, jxr, doxia, archetype,
> > 
> > ...)
> > 
> > > > use
> > > > the standard Apache source-release assembly descriptor, with root
> > 
> > reactor
> > 
> > > > POM
> > > > artifactId being the name of the project (without any "parent")
> > > > 
> > > > Perhaps renaming your parent artifact to "apache-zookeeper" may be a
> > > > solution,
> > > > to avoid renaming the current zookeeper artifact, and getting a
> > > > apache-
> > > > zookeeper-*.tar.gz output
> > > > 
> > > > HTH
> > > > 
> > > > Hervé
> > > > 
> > > > [1] https://issues.apache.org/jira/browse/MNG-5001
> > > > 
> > > > [2]
> > 
> > https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/
> > 
> > > > Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> > > > > Self answer, I have cloned the execution but I have reused the
> > > > > common
> > > > > assembly descriptor. It is a trade off but it works
> > 
> > https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4b
> > 
> > > > a1>
> > > > 
> > > > > 8d15ab1
> > > > > 
> > > > > Enrico
> > > > > 
> > > > > Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> > > > > 
> > > > > eolive...@gmail.com> ha scritto:
> > > > > > Hi,
> > > > > > In Apache ZooKeeper community we want to switch to using the
> > 
> > "source
> > 
> > > > > > package" generated by the apache parent pom with the execution of
> > > > > > "source-release-assembly".
> > 
> > https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > 
> > > > > > What is the *best* way to achieve these goals (without redefining
> > 
> > the
> > 
> > > > full
> > > > 
> > > > > > execution):
> > > > > > 1) create a tar.gz file ?
> > > > > > 2) use a custom file name
> > > > > > 
> > > > > > 
> > > > > > 1) We have historically always distributed the sources in tar.gz
> > > > 
> > > > format,
> > > > 
> > > > > > the ZIP file works well but if we keep the usual format we will
> > 
> > give
> > 
> > > > less
> > > > 
> > > > > > troubles to downstream consumers
> > > > > > 
> > > > > > 2) Such execution is bound to the root project, that has "parent"
> > 
> > as
> > 
> > > > > > artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> > > > > > I would like it to be apache-zookeeper-3.6.0.tar.gz
> > > > > > 
> > > > > > Any comment/help is appreciated.
> > > > > > 
> > > > > > My personal solution would be to create a separate execution with
> > > > > > a
> > > > 
> > > > copy
> > > > 
> > > > > > and paste of the Apache Parent POM, but if will it is not ideal
> > > > > > 
> > > > > > Cheers
> > > > > > Enrico
> > > > 

Re: Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Il sab 18 gen 2020, 22:27 Hervé BOUTEMY  ha scritto:

> Le samedi 18 janvier 2020, 14:24:29 CET Enrico Olivelli a écrit :
> > Hervé
> > I don't know why but my change works as expected.
> >
> > I really can't change the artifact id of the main parent pom because it
> > will be a nuisance for consumers.
> >
> > So you think that my patch is working only because of a bug in Maven
> core?
> more than that, I'm sure it's the case and that MNG-5001 will fix the bug,
> then
> your build will fail
>
> >
> > I shouldn't be able to override finalName.
> yes, it's tempting to do so, but if this parameter is not documented, it's
> because it's read-only then is not expected to be overridden. And given
> you're
> not the first one I saw to override it, MNG-5001 is absolutely required
>

Just for info my IDE suggested that there is such parameter.
Maybe the IDE should not suggest to override read-only parameters

Not a big deal, if we enforce 'read only' then the build will fail


> >
> >  I could change finalName root property without changing the artifactid
> no, you can't, and this is for a reason: in the repository, every attached
> sub-artifact is expected to have the same artifactId, then have a filename
> starting with the artifactId. This is key to our convention, sorry.
>
> Looking at Zookeeper distribution [1], what about renaming
> zookeeper-assembly
> module to apache-zookeeper and publish its content to central? It would be
> the
> equivalent to our apache-maven module.
> And given you need a specific assembly for the bin distribution, this
> would not
> be an issue, isn't it?
>

I will try, thank you for this good suggestion


Enrico

>
> Regards,
>
> Hervé
>
> [1] https://www-us.apache.org/dist/zookeeper/current/
>
> >
> > Thanks for your help
> > Enrico
> >
> > Il sab 18 gen 2020, 12:46 Hervé BOUTEMY  ha
> scritto:
> > > WARNING: finalName is read-only
> > > There is a bug in Maven 3 that does not check, but this will be fixed
> in
> > > Maven
> > > 3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure
> > >
> > > Either you should rename parent artifact to zookeeper, then you'll
> have to
> > > rename the current zookeeper to zookeeper-server for example.
> > > Either you're stuck with your specific assembly.
> > >
> > > In Maven itself, we have 2 cases:
> > > - Maven core, that has a specific assembly in apache-maven module where
> > > source-
> > > release is published [2] with a specific src+bin and zip+tar.gz output
> > > - every other multi-module project (surefire, jxr, doxia, archetype,
> ...)
> > > use
> > > the standard Apache source-release assembly descriptor, with root
> reactor
> > > POM
> > > artifactId being the name of the project (without any "parent")
> > >
> > > Perhaps renaming your parent artifact to "apache-zookeeper" may be a
> > > solution,
> > > to avoid renaming the current zookeeper artifact, and getting a apache-
> > > zookeeper-*.tar.gz output
> > >
> > > HTH
> > >
> > > Hervé
> > >
> > > [1] https://issues.apache.org/jira/browse/MNG-5001
> > >
> > > [2]
> > >
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/
> > >
> > > Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> > > > Self answer, I have cloned the execution but I have reused the common
> > > > assembly descriptor. It is a trade off but it works
> > >
> > >
> https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4b
> > > a1>
> > > > 8d15ab1
> > > >
> > > > Enrico
> > > >
> > > > Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> > > >
> > > > eolive...@gmail.com> ha scritto:
> > > > > Hi,
> > > > > In Apache ZooKeeper community we want to switch to using the
> "source
> > > > > package" generated by the apache parent pom with the execution of
> > > > > "source-release-assembly".
> > > > >
> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > > > >
> > > > > What is the *best* way to achieve these goals (without redefining
> the
> > >
> > > full
> > >
> > > > > execution):
> > > > > 1) create a tar.gz file ?
> > > > > 2) use a custom file name
> > > > >
> > > > >
> > > > > 1) We have historically always distributed the sources in tar.gz
> > >
> > > format,
> > >
> > > > > the ZIP file works well but if we keep the usual format we will
> give
> > >
> > > less
> > >
> > > > > troubles to downstream consumers
> > > > >
> > > > > 2) Such execution is bound to the root project, that has "parent"
> as
> > > > > artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> > > > > I would like it to be apache-zookeeper-3.6.0.tar.gz
> > > > >
> > > > > Any comment/help is appreciated.
> > > > >
> > > > > My personal solution would be to create a separate execution with a
> > >
> > > copy
> > >
> > > > > and paste of the Apache Parent POM, but if will it is not ideal
> > > > >
> > > > > Cheers
> > > > > Enrico
> > >
> > > -
> > > To 

Re: Question about Apache Parent Pom and source-release-assembly

[Hervé BOUTEMY]

Le samedi 18 janvier 2020, 14:24:29 CET Enrico Olivelli a écrit :
> Hervé
> I don't know why but my change works as expected.
> 
> I really can't change the artifact id of the main parent pom because it
> will be a nuisance for consumers.
> 
> So you think that my patch is working only because of a bug in Maven core?
more than that, I'm sure it's the case and that MNG-5001 will fix the bug, then 
your build will fail

> 
> I shouldn't be able to override finalName.
yes, it's tempting to do so, but if this parameter is not documented, it's 
because it's read-only then is not expected to be overridden. And given you're 
not the first one I saw to override it, MNG-5001 is absolutely required

> 
>  I could change finalName root property without changing the artifactid
no, you can't, and this is for a reason: in the repository, every attached 
sub-artifact is expected to have the same artifactId, then have a filename 
starting with the artifactId. This is key to our convention, sorry.

Looking at Zookeeper distribution [1], what about renaming zookeeper-assembly 
module to apache-zookeeper and publish its content to central? It would be the 
equivalent to our apache-maven module.
And given you need a specific assembly for the bin distribution, this would not 
be an issue, isn't it?

Regards,

Hervé

[1] https://www-us.apache.org/dist/zookeeper/current/

> 
> Thanks for your help
> Enrico
> 
> Il sab 18 gen 2020, 12:46 Hervé BOUTEMY  ha scritto:
> > WARNING: finalName is read-only
> > There is a bug in Maven 3 that does not check, but this will be fixed in
> > Maven
> > 3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure
> > 
> > Either you should rename parent artifact to zookeeper, then you'll have to
> > rename the current zookeeper to zookeeper-server for example.
> > Either you're stuck with your specific assembly.
> > 
> > In Maven itself, we have 2 cases:
> > - Maven core, that has a specific assembly in apache-maven module where
> > source-
> > release is published [2] with a specific src+bin and zip+tar.gz output
> > - every other multi-module project (surefire, jxr, doxia, archetype, ...)
> > use
> > the standard Apache source-release assembly descriptor, with root reactor
> > POM
> > artifactId being the name of the project (without any "parent")
> > 
> > Perhaps renaming your parent artifact to "apache-zookeeper" may be a
> > solution,
> > to avoid renaming the current zookeeper artifact, and getting a apache-
> > zookeeper-*.tar.gz output
> > 
> > HTH
> > 
> > Hervé
> > 
> > [1] https://issues.apache.org/jira/browse/MNG-5001
> > 
> > [2]
> > https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/
> > 
> > Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> > > Self answer, I have cloned the execution but I have reused the common
> > > assembly descriptor. It is a trade off but it works
> > 
> > https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4b
> > a1> 
> > > 8d15ab1
> > > 
> > > Enrico
> > > 
> > > Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> > > 
> > > eolive...@gmail.com> ha scritto:
> > > > Hi,
> > > > In Apache ZooKeeper community we want to switch to using the "source
> > > > package" generated by the apache parent pom with the execution of
> > > > "source-release-assembly".
> > > > https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > > > 
> > > > What is the *best* way to achieve these goals (without redefining the
> > 
> > full
> > 
> > > > execution):
> > > > 1) create a tar.gz file ?
> > > > 2) use a custom file name
> > > > 
> > > > 
> > > > 1) We have historically always distributed the sources in tar.gz
> > 
> > format,
> > 
> > > > the ZIP file works well but if we keep the usual format we will give
> > 
> > less
> > 
> > > > troubles to downstream consumers
> > > > 
> > > > 2) Such execution is bound to the root project, that has "parent" as
> > > > artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> > > > I would like it to be apache-zookeeper-3.6.0.tar.gz
> > > > 
> > > > Any comment/help is appreciated.
> > > > 
> > > > My personal solution would be to create a separate execution with a
> > 
> > copy
> > 
> > > > and paste of the Apache Parent POM, but if will it is not ideal
> > > > 
> > > > Cheers
> > > > Enrico
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org





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

Re: Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Hervé
I don't know why but my change works as expected.

I really can't change the artifact id of the main parent pom because it
will be a nuisance for consumers.

So you think that my patch is working only because of a bug in Maven core?

I shouldn't be able to override finalName.

 I could change finalName root property without changing the artifactid

Thanks for your help
Enrico

Il sab 18 gen 2020, 12:46 Hervé BOUTEMY  ha scritto:

> WARNING: finalName is read-only
> There is a bug in Maven 3 that does not check, but this will be fixed in
> Maven
> 3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure
>
> Either you should rename parent artifact to zookeeper, then you'll have to
> rename the current zookeeper to zookeeper-server for example.
> Either you're stuck with your specific assembly.
>
> In Maven itself, we have 2 cases:
> - Maven core, that has a specific assembly in apache-maven module where
> source-
> release is published [2] with a specific src+bin and zip+tar.gz output
> - every other multi-module project (surefire, jxr, doxia, archetype, ...)
> use
> the standard Apache source-release assembly descriptor, with root reactor
> POM
> artifactId being the name of the project (without any "parent")
>
> Perhaps renaming your parent artifact to "apache-zookeeper" may be a
> solution,
> to avoid renaming the current zookeeper artifact, and getting a apache-
> zookeeper-*.tar.gz output
>
> HTH
>
> Hervé
>
> [1] https://issues.apache.org/jira/browse/MNG-5001
>
> [2]
> https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/
>
> Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> > Self answer, I have cloned the execution but I have reused the common
> > assembly descriptor. It is a trade off but it works
> >
> >
> https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4ba1
> > 8d15ab1
> >
> > Enrico
> >
> > Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> >
> > eolive...@gmail.com> ha scritto:
> > > Hi,
> > > In Apache ZooKeeper community we want to switch to using the "source
> > > package" generated by the apache parent pom with the execution of
> > > "source-release-assembly".
> > > https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > >
> > > What is the *best* way to achieve these goals (without redefining the
> full
> > > execution):
> > > 1) create a tar.gz file ?
> > > 2) use a custom file name
> > >
> > >
> > > 1) We have historically always distributed the sources in tar.gz
> format,
> > > the ZIP file works well but if we keep the usual format we will give
> less
> > > troubles to downstream consumers
> > >
> > > 2) Such execution is bound to the root project, that has "parent" as
> > > artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> > > I would like it to be apache-zookeeper-3.6.0.tar.gz
> > >
> > > Any comment/help is appreciated.
> > >
> > > My personal solution would be to create a separate execution with a
> copy
> > > and paste of the Apache Parent POM, but if will it is not ideal
> > >
> > > Cheers
> > > Enrico
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Question about Apache Parent Pom and source-release-assembly

[Hervé BOUTEMY]

WARNING: finalName is read-only
There is a bug in Maven 3 that does not check, but this will be fixed in Maven 
3.7.0 (see MNG-5001 [1]), then you'll get soon the expected failure

Either you should rename parent artifact to zookeeper, then you'll have to 
rename the current zookeeper to zookeeper-server for example.
Either you're stuck with your specific assembly.

In Maven itself, we have 2 cases:
- Maven core, that has a specific assembly in apache-maven module where source-
release is published [2] with a specific src+bin and zip+tar.gz output
- every other multi-module project (surefire, jxr, doxia, archetype, ...) use 
the standard Apache source-release assembly descriptor, with root reactor POM 
artifactId being the name of the project (without any "parent")

Perhaps renaming your parent artifact to "apache-zookeeper" may be a solution, 
to avoid renaming the current zookeeper artifact, and getting a apache-
zookeeper-*.tar.gz output

HTH

Hervé

[1] https://issues.apache.org/jira/browse/MNG-5001

[2] https://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/3.6.3/

Le vendredi 17 janvier 2020, 17:37:52 CET Enrico Olivelli a écrit :
> Self answer, I have cloned the execution but I have reused the common
> assembly descriptor. It is a trade off but it works
> 
> https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4ba1
> 8d15ab1
> 
> Enrico
> 
> Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
> 
> eolive...@gmail.com> ha scritto:
> > Hi,
> > In Apache ZooKeeper community we want to switch to using the "source
> > package" generated by the apache parent pom with the execution of
> > "source-release-assembly".
> > https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
> > 
> > What is the *best* way to achieve these goals (without redefining the full
> > execution):
> > 1) create a tar.gz file ?
> > 2) use a custom file name
> > 
> > 
> > 1) We have historically always distributed the sources in tar.gz format,
> > the ZIP file works well but if we keep the usual format we will give less
> > troubles to downstream consumers
> > 
> > 2) Such execution is bound to the root project, that has "parent" as
> > artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> > I would like it to be apache-zookeeper-3.6.0.tar.gz
> > 
> > Any comment/help is appreciated.
> > 
> > My personal solution would be to create a separate execution with a copy
> > and paste of the Apache Parent POM, but if will it is not ideal
> > 
> > Cheers
> > Enrico





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

Re: Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Self answer, I have cloned the execution but I have reused the common
assembly descriptor. It is a trade off but it works

https://github.com/apache/zookeeper/commit/9053f7c431bb17ed79c2be129b6ba4ba18d15ab1

Enrico

Il giorno ven 17 gen 2020 alle ore 08:50 Enrico Olivelli <
eolive...@gmail.com> ha scritto:

> Hi,
> In Apache ZooKeeper community we want to switch to using the "source
> package" generated by the apache parent pom with the execution of
> "source-release-assembly".
> https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381
>
> What is the *best* way to achieve these goals (without redefining the full
> execution):
> 1) create a tar.gz file ?
> 2) use a custom file name
>
>
> 1) We have historically always distributed the sources in tar.gz format,
> the ZIP file works well but if we keep the usual format we will give less
> troubles to downstream consumers
>
> 2) Such execution is bound to the root project, that has "parent" as
> artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
> I would like it to be apache-zookeeper-3.6.0.tar.gz
>
> Any comment/help is appreciated.
>
> My personal solution would be to create a separate execution with a copy
> and paste of the Apache Parent POM, but if will it is not ideal
>
> Cheers
> Enrico
>

Question about Apache Parent Pom and source-release-assembly

[Enrico Olivelli]

Hi,
In Apache ZooKeeper community we want to switch to using the "source
package" generated by the apache parent pom with the execution of
"source-release-assembly".
https://github.com/apache/maven-apache-parent/blob/master/pom.xml#L381

What is the *best* way to achieve these goals (without redefining the full
execution):
1) create a tar.gz file ?
2) use a custom file name


1) We have historically always distributed the sources in tar.gz format,
the ZIP file works well but if we keep the usual format we will give less
troubles to downstream consumers

2) Such execution is bound to the root project, that has "parent" as
artifact id, so the ZIP file name is like parent-3.6.0-sources.zip
I would like it to be apache-zookeeper-3.6.0.tar.gz

Any comment/help is appreciated.

My personal solution would be to create a separate execution with a copy
and paste of the Apache Parent POM, but if will it is not ideal

Cheers
Enrico

Re: Maven question - how to pull code from bitbucket repository as dependency

[Jason Young]

On Wed, Jun 12, 2019 at 1:04 AM Anders Hammar  wrote:

> Having a dependency to some other scm repo is not a good approach. If that
> changes your build could fail all of a sudden and you want consistency.
>

This is not true. The "big 3" VCSes each allow you to checkout a specific
tag or revision if you like. If both projects (the dependent and the
dependency) use the same VCS, then, at least in the cases of Git and SVN,
you have a VCS-specific feature, e.g. Git subrepos or SVN externals, to
work with the dependency's repo pretty seamlessly (though admittedly their
use is controversial, but let's not go on a tangent about it :) ).


> Your Maven project should typically be self contained. Any dependency
> should be a Maven artifact (that is immutable).
>

It is certainly preferable to make one Maven project depend on another when
possible, but keep in mind there are by necessity other kinds of
dependencies too: The JDK, system-level libraries not provided by some
JVMs, a SQL database, etc. You _can_ mavenize a lot of dependencies (like a
SQL database project) and gain Maven's dependency management, but that is
not invariably worth the cost of implementing and maintaining that
mavenization.

/Anders
>
> On Wed, Jun 12, 2019 at 7:50 AM Rajesh Deshpande <
> rajesh.deshpa...@gmail.com>
> wrote:
>
> > Hello,
> > I have a maven project that builds Java jar files. I wan to run a python
> > script as one of the goals in the verify phase. I am planning to use the
> > ant run plugin for running the python script. The python script is stored
> > in a separate repository that I would like to copy to my project root
> > folder using maven. Is this possible? What's the best way to approach
> this?
> >
> > Thanks!
> >
>

Re: Maven question - how to pull code from bitbucket repository as dependency

[Matthieu BROUILLARD]

If your script is hosted on SVN or git then you can also perhaps do a
simple GET on a well know resources (SHA1 or tag) on the raw file directly.
That way the download is easy and you have a reproducible build because you
target a fixed version of the script.

Matthieu

On Wed, Jun 12, 2019 at 8:11 AM Thorsten Heit  wrote:

> Hi,
>
> > I have a maven project that builds Java jar files. I wan to run a python
> > script as one of the goals in the verify phase. I am planning to use the
> > ant run plugin for running the python script. The python script is
> stored
> > in a separate repository that I would like to copy to my project root
> > folder using maven. Is this possible? What's the best way to approach
> this?
>
> Although I have to admin I never tried it ;-), but two ideas:
>
> 1) Use the JGit Ant task ([1]) to checkout your source code before you
> execute the python script from within the Ant task.
>
> 2) Add a second plugin configuration for maven scm that is being executed
> in the verify phase. Configure the scm plugin and add at least the
> (developer) connection url, and perhaps the destination (checkout)
> directory in which your script is to be stored. See [2].
>
>
>
>
> [1] https://wiki.eclipse.org/JGit/User_Guide#Ant_Tasks
> [2] https://maven.apache.org/scm/maven-scm-plugin/checkout-mojo.html
>
> HTH
>
> Thorsten

Re: Maven question - how to pull code from bitbucket repository as dependency

[Thorsten Heit]

Hi,
 
> I have a maven project that builds Java jar files. I wan to run a python
> script as one of the goals in the verify phase. I am planning to use the
> ant run plugin for running the python script. The python script is 
stored
> in a separate repository that I would like to copy to my project root
> folder using maven. Is this possible? What's the best way to approach 
this?

Although I have to admin I never tried it ;-), but two ideas:

1) Use the JGit Ant task ([1]) to checkout your source code before you 
execute the python script from within the Ant task.

2) Add a second plugin configuration for maven scm that is being executed 
in the verify phase. Configure the scm plugin and add at least the 
(developer) connection url, and perhaps the destination (checkout) 
directory in which your script is to be stored. See [2].




[1] https://wiki.eclipse.org/JGit/User_Guide#Ant_Tasks
[2] https://maven.apache.org/scm/maven-scm-plugin/checkout-mojo.html

HTH

Thorsten

Re: Maven question - how to pull code from bitbucket repository as dependency

[Anders Hammar]

Having a dependency to some other scm repo is not a good approach. If that
changes your build could fail all of a sudden and you want consistency.

Your Maven project should typically be self contained. Any dependency
should be a Maven artifact (that is immutable).

/Anders

On Wed, Jun 12, 2019 at 7:50 AM Rajesh Deshpande 
wrote:

> Hello,
> I have a maven project that builds Java jar files. I wan to run a python
> script as one of the goals in the verify phase. I am planning to use the
> ant run plugin for running the python script. The python script is stored
> in a separate repository that I would like to copy to my project root
> folder using maven. Is this possible? What's the best way to approach this?
>
> Thanks!
>

Maven question - how to pull code from bitbucket repository as dependency

[Rajesh Deshpande]

Hello,
I have a maven project that builds Java jar files. I wan to run a python
script as one of the goals in the verify phase. I am planning to use the
ant run plugin for running the python script. The python script is stored
in a separate repository that I would like to copy to my project root
folder using maven. Is this possible? What's the best way to approach this?

Thanks!

Question on shading plugin

[Jerry Peng]

Hello all,

I have a question about the maven shade plugin.

Is there a way to exclude a set of classes from being applied by the
shading/relocation rule.  I have a use case in which I have a set of
classes that need to import the shaded version of a class but another set
of classes need to import the non-shaded version of a class.  Can this be
done?

The exclusions in the relocation clause seem to mean I can exclude imports
of a certain pattern  but not exclude certain classes from being affect my
this relocation rule.


Thanks!

Best,

Jerry

Re: Question about the order maven-invoker-plugin executes the tests

[Zoltan Farkas]

pomIncludes did not work… wish there was  a way to order execution or specify 
some dependencies…

thanks

—Z

> On Oct 16, 2018, at 10:59 PM, Zoltan Farkas  
> wrote:
> 
> Thanks, my issue is that I am testing a plugin that validates API backward 
> compatibility and I have:
> 
> project v1, project v2, project v3, project v4
> 
> where the  artifact produced by project 2 is validated against the artifact  
> produced by project 1,  artifact produced by project v3 validated against v2 
> ...etc…
> 
> now  I could add some  of  them in a maven multi-project, but I  would have 
> to duplicate a lot of code to  achieve all  the test scenarios I want…
> 
> will try out pomIncludes…
> 
> thanks!
> 
> —Z
> 
> 
>> On Oct 16, 2018, at 5:35 PM, Anders Hammar  wrote:
>> 
>> Typically no test project should depend on other test projects, so you
>> shouldn't need to specify the order. But you could have some setup projects
>> that need to be run before the test projects. You can specify those with
>> the setupIncludes param [1].
>> 
>> Having said that, you could try specifying the order with the pomIncludes
>> param [2]. I don't know if it works and it sounds cumbersome to me to
>> always keep that parameter updated whenever you add a test project.
>> 
>> [1]
>> https://maven.apache.org/plugins/maven-invoker-plugin/integration-test-mojo.html#setupIncludes
>> [2]
>> https://maven.apache.org/plugins/maven-invoker-plugin/integration-test-mojo.html#pomIncludes
>> 
>> /Anders
>> 
>> On Tue, Oct 16, 2018 at 11:16 PM Zoltan Farkas 
>> wrote:
>> 
>>> Is there a way to control the order the tests configured at:
>>> src/it/projects ?
>>> 
>>> thanks!
>>> 
>>> —Z
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


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

Re: Question about the order maven-invoker-plugin executes the tests

[Zoltan Farkas]

Thanks, my issue is that I am testing a plugin that validates API backward 
compatibility and I have:

project v1, project v2, project v3, project v4

where the  artifact produced by project 2 is validated against the artifact  
produced by project 1,  artifact produced by project v3 validated against v2 
...etc…

now  I could add some  of  them in a maven multi-project, but I  would have to 
duplicate a lot of code to  achieve all  the test scenarios I want…

will try out pomIncludes…

thanks!

—Z


> On Oct 16, 2018, at 5:35 PM, Anders Hammar  wrote:
> 
> Typically no test project should depend on other test projects, so you
> shouldn't need to specify the order. But you could have some setup projects
> that need to be run before the test projects. You can specify those with
> the setupIncludes param [1].
> 
> Having said that, you could try specifying the order with the pomIncludes
> param [2]. I don't know if it works and it sounds cumbersome to me to
> always keep that parameter updated whenever you add a test project.
> 
> [1]
> https://maven.apache.org/plugins/maven-invoker-plugin/integration-test-mojo.html#setupIncludes
> [2]
> https://maven.apache.org/plugins/maven-invoker-plugin/integration-test-mojo.html#pomIncludes
> 
> /Anders
> 
> On Tue, Oct 16, 2018 at 11:16 PM Zoltan Farkas 
> wrote:
> 
>> Is there a way to control the order the tests configured at:
>> src/it/projects ?
>> 
>> thanks!
>> 
>> —Z
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 


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

Re: Question about the order maven-invoker-plugin executes the tests

[Anders Hammar]

Typically no test project should depend on other test projects, so you
shouldn't need to specify the order. But you could have some setup projects
that need to be run before the test projects. You can specify those with
the setupIncludes param [1].

Having said that, you could try specifying the order with the pomIncludes
param [2]. I don't know if it works and it sounds cumbersome to me to
always keep that parameter updated whenever you add a test project.

[1]
https://maven.apache.org/plugins/maven-invoker-plugin/integration-test-mojo.html#setupIncludes
[2]
https://maven.apache.org/plugins/maven-invoker-plugin/integration-test-mojo.html#pomIncludes

/Anders

On Tue, Oct 16, 2018 at 11:16 PM Zoltan Farkas 
wrote:

> Is there a way to control the order the tests configured at:
> src/it/projects ?
>
> thanks!
>
> —Z
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Question about the order maven-invoker-plugin executes the tests

[Zoltan Farkas]

Is there a way to control the order the tests configured at: 
src/it/projects ?

thanks!

—Z



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

Question about using a custom StackTraceWriter with the maven-surefire-plugin

[Zoltan Farkas]

Is it possible to register a custom writer with the maven-surefire-plugin?

let me know.

thank you.

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

Re: maven-resolver question: difference between DependencySelector and DependencyFilter?

[Laird Nelson]

On Mon, Feb 26, 2018 at 5:46 PM Laird Nelson  wrote:

> I'm noticing that when I rely on the default DependencySelector installed
> by MavenRepositorySystemUtils#newSession(), which incorporates optionality,
> scope, etc., I still get optional dependencies in my collected results.
>

I meant to include the javadoc reference in my previous message:
http://maven.apache.org/ref/3.3.9/maven-aether-provider/apidocs/org/apache/maven/repository/internal/MavenRepositorySystemUtils.html#newSession
()

Best,
Laird

maven-resolver question: difference between DependencySelector and DependencyFilter?

[Laird Nelson]

Hello:

DependencySelector (
https://maven.apache.org/resolver/apidocs/org/eclipse/aether/collection/DependencySelector.html)
has Javadocs that read (in part): "Decides what dependencies to include in
the dependency graph".

DependencyFilter (
https://maven.apache.org/resolver/apidocs/org/eclipse/aether/graph/DependencyFilter.html)
has Javadocs that read (in part): "A filter to include/exclude dependency
nodes during other operations.".

A DependencySelector is something that is set onto a
RepositorySystemSession and is "called from a hotspot" (i.e. it is central
to how the RepositorySystemSession works).  DependencyFilter is something
that is supplied to (probably among other things) a DependencyRequest (
https://maven.apache.org/resolver/apidocs/org/eclipse/aether/resolution/DependencyRequest.html#DependencyRequest(org.eclipse.aether.collection.CollectRequest,%20org.eclipse.aether.graph.DependencyFilter
).

I'm noticing that when I rely on the default DependencySelector installed
by MavenRepositorySystemUtils#newSession(), which incorporates optionality,
scope, etc., I still get optional dependencies in my collected results.
Shouldn't the session's DependencySelector take care of eliminating
optional dependencies when I ask maven-resolver to resolve my dependencies?

Best,
Laird

Re: Question regarding Maven's local repository use

[Paul Benedict]

Anders, I am researching my project/repository against your explanation. I
will follow up with a real answer once complete. Thanks for your response.

On Mon, Feb 5, 2018 at 3:25 PM, Anders Hammar <and...@hammar.net> wrote:

> I'd like to stress that my explanations are from what I recall. I could be
> wrong.
>
> If my memory serves me right and this is how it works, I believe it was
> just to prevent the scenario you're describing (switching between different
> repos) from causing the wrong result. The idea was then that if you change
> your repo/mirror config, your intention is to use the current declared
> repo(s)/mirror(s). So anything from some other repo(s) shouldn't be used.
> However, using the repo/mirror id is probably not the best solution; using
> the url would probably be better.
>
> So, in your scenario, you typically work with a corporate proxy/mirror
> (like Nexus) that only gives you access to procured artifacts. Then you
> want to use/test some artifact that the mirror don't allow, so you work
> directly towards central. Then you switch back to your procured mirror and
> Maven now prevents you from using the artifact that doesn't exist in the
> procured mirror.
> I'd say everything works as intended then. Maven stops you from using an
> artifact that you shouldn't be using according to your configuration. If
> you would like to use that artifact, you should be working towards central
> directly or your mirror should provide it.
> Do you see my point?
>
> /Anders
>
> On Mon, Feb 5, 2018 at 10:06 PM, Paul Benedict <pbened...@apache.org>
> wrote:
>
> > Anders, I have a question for your clarification. I think you're saying
> > that because some repositories aren't in best condition, this is a way to
> > make sure the intended artifact of the intended repository is downloaded?
> > Okay. If that's the case, that sounds like a really weird edge case that
> > shouldn't figure into normal use. If I ever encountered such a problem, a
> > developer should rely on dependency:purge-local-repository to trash the
> > bad
> > download.
> >
> > So is there any room for a Maven enhancement here? I am still not
> convinced
> > the current behavior is sensible as a default. I really want to allow my
> > repositories, with local artifacts pre-cached in my local repository, to
> go
> > offline without causing a build panic. What are anyone's thoughts on here
> > about how Maven could adopt behavior like I want? I could probably write
> a
> > patch but I'd like a "meeting of the minds" to turn this idea from good
> to
> > better.
> >
> > On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net>
> wrote:
> >
> > > IIRC this change was introduced as an artifact sometimes differ between
> > > repositories. They shouldn't do, but some repos aren't handled
> correctly.
> > > So if the repo id changes compared to the one stored for a locally
> cached
> > > artifact, Maven tries to download it again.
> > >
> > > /Anders
> > >
> > > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org>
> > > wrote:
> > >
> > > > I think you're right. However, I am still curious why Maven is acting
> > > like
> > > > it does -- in terms of requirements. Maven already has the artifact
> > > > locally. There's not a reason (and never a reason?) for it to ever be
> > > > retrieved again, right?
> > > >
> > > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net>
> > wrote:
> > > >
> > > > > What I think you're running into is that Maven keeps track of from
> > > which
> > > > > repo an artifact in the local repo was downloaded from. When you
> > > > > remove/restore the mirror config the repo id most likely changes
> > which
> > > > > causes Maven to try to download again.
> > > > > There should be a filed named _remote.repositories next to every
> > > artifact
> > > > > in the loca lrepo where you can find this info.
> > > > >
> > > > > IIRC this was a change between Maven 2 and Maven 3, or a change
> that
> > > > > happened very early in the life of Maven 3. Before that Maven
> didn't
> > > keep
> > > > > track of from where an artifact was downloaded.
> > > > >
> > > > > /Anders
> > > > >
> > > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <
> pbened...@apache.org>
> > > > > wrote

Re: Question regarding Maven's local repository use

[Anders Hammar]

I'd like to stress that my explanations are from what I recall. I could be
wrong.

If my memory serves me right and this is how it works, I believe it was
just to prevent the scenario you're describing (switching between different
repos) from causing the wrong result. The idea was then that if you change
your repo/mirror config, your intention is to use the current declared
repo(s)/mirror(s). So anything from some other repo(s) shouldn't be used.
However, using the repo/mirror id is probably not the best solution; using
the url would probably be better.

So, in your scenario, you typically work with a corporate proxy/mirror
(like Nexus) that only gives you access to procured artifacts. Then you
want to use/test some artifact that the mirror don't allow, so you work
directly towards central. Then you switch back to your procured mirror and
Maven now prevents you from using the artifact that doesn't exist in the
procured mirror.
I'd say everything works as intended then. Maven stops you from using an
artifact that you shouldn't be using according to your configuration. If
you would like to use that artifact, you should be working towards central
directly or your mirror should provide it.
Do you see my point?

/Anders

On Mon, Feb 5, 2018 at 10:06 PM, Paul Benedict <pbened...@apache.org> wrote:

> Anders, I have a question for your clarification. I think you're saying
> that because some repositories aren't in best condition, this is a way to
> make sure the intended artifact of the intended repository is downloaded?
> Okay. If that's the case, that sounds like a really weird edge case that
> shouldn't figure into normal use. If I ever encountered such a problem, a
> developer should rely on dependency:purge-local-repository to trash the
> bad
> download.
>
> So is there any room for a Maven enhancement here? I am still not convinced
> the current behavior is sensible as a default. I really want to allow my
> repositories, with local artifacts pre-cached in my local repository, to go
> offline without causing a build panic. What are anyone's thoughts on here
> about how Maven could adopt behavior like I want? I could probably write a
> patch but I'd like a "meeting of the minds" to turn this idea from good to
> better.
>
> On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> wrote:
>
> > IIRC this change was introduced as an artifact sometimes differ between
> > repositories. They shouldn't do, but some repos aren't handled correctly.
> > So if the repo id changes compared to the one stored for a locally cached
> > artifact, Maven tries to download it again.
> >
> > /Anders
> >
> > On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org>
> > wrote:
> >
> > > I think you're right. However, I am still curious why Maven is acting
> > like
> > > it does -- in terms of requirements. Maven already has the artifact
> > > locally. There's not a reason (and never a reason?) for it to ever be
> > > retrieved again, right?
> > >
> > > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net>
> wrote:
> > >
> > > > What I think you're running into is that Maven keeps track of from
> > which
> > > > repo an artifact in the local repo was downloaded from. When you
> > > > remove/restore the mirror config the repo id most likely changes
> which
> > > > causes Maven to try to download again.
> > > > There should be a filed named _remote.repositories next to every
> > artifact
> > > > in the loca lrepo where you can find this info.
> > > >
> > > > IIRC this was a change between Maven 2 and Maven 3, or a change that
> > > > happened very early in the life of Maven 3. Before that Maven didn't
> > keep
> > > > track of from where an artifact was downloaded.
> > > >
> > > > /Anders
> > > >
> > > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org>
> > > > wrote:
> > > >
> > > > > My Maven version is 3.3.9. For my typical use case, my settings.xml
> > > has a
> > > > >  of "central" that provides a procured subset of artifacts.
> > It
> > > > > contains nearly everything I might need to do a desktop build.
> > However,
> > > > > sometimes I need to connect to the real "central" directly to try
> and
> > > > test
> > > > > an experimental artifact; therefore I temporarily wipe out my
> > ,
> > > > let
> > > > > Maven resolve the artifact and place it in my local repository,
> and I

Re: Question regarding Maven's local repository use

[Paul Benedict]

Anders, I have a question for your clarification. I think you're saying
that because some repositories aren't in best condition, this is a way to
make sure the intended artifact of the intended repository is downloaded?
Okay. If that's the case, that sounds like a really weird edge case that
shouldn't figure into normal use. If I ever encountered such a problem, a
developer should rely on dependency:purge-local-repository to trash the bad
download.

So is there any room for a Maven enhancement here? I am still not convinced
the current behavior is sensible as a default. I really want to allow my
repositories, with local artifacts pre-cached in my local repository, to go
offline without causing a build panic. What are anyone's thoughts on here
about how Maven could adopt behavior like I want? I could probably write a
patch but I'd like a "meeting of the minds" to turn this idea from good to
better.

On Mon, Feb 5, 2018 at 12:56 PM, Anders Hammar <and...@hammar.net> wrote:

> IIRC this change was introduced as an artifact sometimes differ between
> repositories. They shouldn't do, but some repos aren't handled correctly.
> So if the repo id changes compared to the one stored for a locally cached
> artifact, Maven tries to download it again.
>
> /Anders
>
> On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict <pbened...@apache.org>
> wrote:
>
> > I think you're right. However, I am still curious why Maven is acting
> like
> > it does -- in terms of requirements. Maven already has the artifact
> > locally. There's not a reason (and never a reason?) for it to ever be
> > retrieved again, right?
> >
> > On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar <and...@hammar.net> wrote:
> >
> > > What I think you're running into is that Maven keeps track of from
> which
> > > repo an artifact in the local repo was downloaded from. When you
> > > remove/restore the mirror config the repo id most likely changes which
> > > causes Maven to try to download again.
> > > There should be a filed named _remote.repositories next to every
> artifact
> > > in the loca lrepo where you can find this info.
> > >
> > > IIRC this was a change between Maven 2 and Maven 3, or a change that
> > > happened very early in the life of Maven 3. Before that Maven didn't
> keep
> > > track of from where an artifact was downloaded.
> > >
> > > /Anders
> > >
> > > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict <pbened...@apache.org>
> > > wrote:
> > >
> > > > My Maven version is 3.3.9. For my typical use case, my settings.xml
> > has a
> > > >  of "central" that provides a procured subset of artifacts.
> It
> > > > contains nearly everything I might need to do a desktop build.
> However,
> > > > sometimes I need to connect to the real "central" directly to try and
> > > test
> > > > an experimental artifact; therefore I temporarily wipe out my
> ,
> > > let
> > > > Maven resolve the artifact and place it in my local repository, and I
> > can
> > > > test accordingly.
> > > >
> > > > Now this is where my trouble begins. After restoring my ,
> Maven
> > > > complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> > > > repository, resolution will not be reattempted until...".
> > > >
> > > > This is very confusing to me. The artifact version is NOT a snapshot.
> > > Yes,
> > > > I am online, but why does Maven need to verify the artifact in the
> > remote
> > > > repository given it already resides in my local repository? Since
> > > > non-snapshots can never be re-updated, I don't see a need for Maven
> to
> > > make
> > > > a remote connection. It seems unnecessary.
> > > >
> > > > Perhaps I am misunderstanding a requirement of Maven. I was really
> > > hoping I
> > > > could be disconnected from the artifact's remote repository, but
> > > evidently
> > > > not. Why is Maven acting this way?
> > > >
> > > > Thank you!
> > > >
> > > > Cheers,
> > > > Paul
> > > >
> > >
> >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>



-- 
Cheers,
Paul

Re: Question regarding Maven's local repository use

[Anders Hammar]

IIRC this change was introduced as an artifact sometimes differ between
repositories. They shouldn't do, but some repos aren't handled correctly.
So if the repo id changes compared to the one stored for a locally cached
artifact, Maven tries to download it again.

/Anders

On Mon, Feb 5, 2018 at 5:04 PM, Paul Benedict  wrote:

> I think you're right. However, I am still curious why Maven is acting like
> it does -- in terms of requirements. Maven already has the artifact
> locally. There's not a reason (and never a reason?) for it to ever be
> retrieved again, right?
>
> On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar  wrote:
>
> > What I think you're running into is that Maven keeps track of from which
> > repo an artifact in the local repo was downloaded from. When you
> > remove/restore the mirror config the repo id most likely changes which
> > causes Maven to try to download again.
> > There should be a filed named _remote.repositories next to every artifact
> > in the loca lrepo where you can find this info.
> >
> > IIRC this was a change between Maven 2 and Maven 3, or a change that
> > happened very early in the life of Maven 3. Before that Maven didn't keep
> > track of from where an artifact was downloaded.
> >
> > /Anders
> >
> > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict 
> > wrote:
> >
> > > My Maven version is 3.3.9. For my typical use case, my settings.xml
> has a
> > >  of "central" that provides a procured subset of artifacts. It
> > > contains nearly everything I might need to do a desktop build. However,
> > > sometimes I need to connect to the real "central" directly to try and
> > test
> > > an experimental artifact; therefore I temporarily wipe out my ,
> > let
> > > Maven resolve the artifact and place it in my local repository, and I
> can
> > > test accordingly.
> > >
> > > Now this is where my trouble begins. After restoring my , Maven
> > > complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> > > repository, resolution will not be reattempted until...".
> > >
> > > This is very confusing to me. The artifact version is NOT a snapshot.
> > Yes,
> > > I am online, but why does Maven need to verify the artifact in the
> remote
> > > repository given it already resides in my local repository? Since
> > > non-snapshots can never be re-updated, I don't see a need for Maven to
> > make
> > > a remote connection. It seems unnecessary.
> > >
> > > Perhaps I am misunderstanding a requirement of Maven. I was really
> > hoping I
> > > could be disconnected from the artifact's remote repository, but
> > evidently
> > > not. Why is Maven acting this way?
> > >
> > > Thank you!
> > >
> > > Cheers,
> > > Paul
> > >
> >
>
>
>
> --
> Cheers,
> Paul
>

Re: Question regarding Maven's local repository use

[Adam Sandor]

The issue here is that the build always runs in a brand new container so at
the start no artifacts are available locally. All the artifacts that are
fetched by the dependency:go-offline task will be cached in a Docker image
layer and reused in later builds if the pom.xml doesn’t change. This would
be great if the dependency:go-offline task actually downloaded all the
dependencies. Because it doesn’t do so every time you change your code a
lot of dependencies will get downloaded, even if not all.

On Mon, Feb 5, 2018 at 5:05 PM Paul Benedict  wrote:

> I think you're right. However, I am still curious why Maven is acting like
> it does -- in terms of requirements. Maven already has the artifact
> locally. There's not a reason (and never a reason?) for it to ever be
> retrieved again, right?
>
> On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar  wrote:
>
> > What I think you're running into is that Maven keeps track of from which
> > repo an artifact in the local repo was downloaded from. When you
> > remove/restore the mirror config the repo id most likely changes which
> > causes Maven to try to download again.
> > There should be a filed named _remote.repositories next to every artifact
> > in the loca lrepo where you can find this info.
> >
> > IIRC this was a change between Maven 2 and Maven 3, or a change that
> > happened very early in the life of Maven 3. Before that Maven didn't keep
> > track of from where an artifact was downloaded.
> >
> > /Anders
> >
> > On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict 
> > wrote:
> >
> > > My Maven version is 3.3.9. For my typical use case, my settings.xml
> has a
> > >  of "central" that provides a procured subset of artifacts. It
> > > contains nearly everything I might need to do a desktop build. However,
> > > sometimes I need to connect to the real "central" directly to try and
> > test
> > > an experimental artifact; therefore I temporarily wipe out my ,
> > let
> > > Maven resolve the artifact and place it in my local repository, and I
> can
> > > test accordingly.
> > >
> > > Now this is where my trouble begins. After restoring my , Maven
> > > complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> > > repository, resolution will not be reattempted until...".
> > >
> > > This is very confusing to me. The artifact version is NOT a snapshot.
> > Yes,
> > > I am online, but why does Maven need to verify the artifact in the
> remote
> > > repository given it already resides in my local repository? Since
> > > non-snapshots can never be re-updated, I don't see a need for Maven to
> > make
> > > a remote connection. It seems unnecessary.
> > >
> > > Perhaps I am misunderstanding a requirement of Maven. I was really
> > hoping I
> > > could be disconnected from the artifact's remote repository, but
> > evidently
> > > not. Why is Maven acting this way?
> > >
> > > Thank you!
> > >
> > > Cheers,
> > > Paul
> > >
> >
>
>
>
> --
> Cheers,
> Paul
>
-- 

Ádám Sándor

Senior Engineer / Consultant

Container Solutions 

0680126174

 

Re: Question regarding Maven's local repository use

[Paul Benedict]

I think you're right. However, I am still curious why Maven is acting like
it does -- in terms of requirements. Maven already has the artifact
locally. There's not a reason (and never a reason?) for it to ever be
retrieved again, right?

On Fri, Feb 2, 2018 at 1:40 AM, Anders Hammar  wrote:

> What I think you're running into is that Maven keeps track of from which
> repo an artifact in the local repo was downloaded from. When you
> remove/restore the mirror config the repo id most likely changes which
> causes Maven to try to download again.
> There should be a filed named _remote.repositories next to every artifact
> in the loca lrepo where you can find this info.
>
> IIRC this was a change between Maven 2 and Maven 3, or a change that
> happened very early in the life of Maven 3. Before that Maven didn't keep
> track of from where an artifact was downloaded.
>
> /Anders
>
> On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict 
> wrote:
>
> > My Maven version is 3.3.9. For my typical use case, my settings.xml has a
> >  of "central" that provides a procured subset of artifacts. It
> > contains nearly everything I might need to do a desktop build. However,
> > sometimes I need to connect to the real "central" directly to try and
> test
> > an experimental artifact; therefore I temporarily wipe out my ,
> let
> > Maven resolve the artifact and place it in my local repository, and I can
> > test accordingly.
> >
> > Now this is where my trouble begins. After restoring my , Maven
> > complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> > repository, resolution will not be reattempted until...".
> >
> > This is very confusing to me. The artifact version is NOT a snapshot.
> Yes,
> > I am online, but why does Maven need to verify the artifact in the remote
> > repository given it already resides in my local repository? Since
> > non-snapshots can never be re-updated, I don't see a need for Maven to
> make
> > a remote connection. It seems unnecessary.
> >
> > Perhaps I am misunderstanding a requirement of Maven. I was really
> hoping I
> > could be disconnected from the artifact's remote repository, but
> evidently
> > not. Why is Maven acting this way?
> >
> > Thank you!
> >
> > Cheers,
> > Paul
> >
>



-- 
Cheers,
Paul

Re: Question regarding Maven's local repository use

[Anders Hammar]

What I think you're running into is that Maven keeps track of from which
repo an artifact in the local repo was downloaded from. When you
remove/restore the mirror config the repo id most likely changes which
causes Maven to try to download again.
There should be a filed named _remote.repositories next to every artifact
in the loca lrepo where you can find this info.

IIRC this was a change between Maven 2 and Maven 3, or a change that
happened very early in the life of Maven 3. Before that Maven didn't keep
track of from where an artifact was downloaded.

/Anders

On Fri, Feb 2, 2018 at 2:05 AM, Paul Benedict  wrote:

> My Maven version is 3.3.9. For my typical use case, my settings.xml has a
>  of "central" that provides a procured subset of artifacts. It
> contains nearly everything I might need to do a desktop build. However,
> sometimes I need to connect to the real "central" directly to try and test
> an experimental artifact; therefore I temporarily wipe out my , let
> Maven resolve the artifact and place it in my local repository, and I can
> test accordingly.
>
> Now this is where my trouble begins. After restoring my , Maven
> complains: "Failure to find xxx:yyy:1.0.0  was cached in local
> repository, resolution will not be reattempted until...".
>
> This is very confusing to me. The artifact version is NOT a snapshot. Yes,
> I am online, but why does Maven need to verify the artifact in the remote
> repository given it already resides in my local repository? Since
> non-snapshots can never be re-updated, I don't see a need for Maven to make
> a remote connection. It seems unnecessary.
>
> Perhaps I am misunderstanding a requirement of Maven. I was really hoping I
> could be disconnected from the artifact's remote repository, but evidently
> not. Why is Maven acting this way?
>
> Thank you!
>
> Cheers,
> Paul
>

Question regarding Maven's local repository use

[Paul Benedict]

My Maven version is 3.3.9. For my typical use case, my settings.xml has a
 of "central" that provides a procured subset of artifacts. It
contains nearly everything I might need to do a desktop build. However,
sometimes I need to connect to the real "central" directly to try and test
an experimental artifact; therefore I temporarily wipe out my , let
Maven resolve the artifact and place it in my local repository, and I can
test accordingly.

Now this is where my trouble begins. After restoring my , Maven
complains: "Failure to find xxx:yyy:1.0.0  was cached in local
repository, resolution will not be reattempted until...".

This is very confusing to me. The artifact version is NOT a snapshot. Yes,
I am online, but why does Maven need to verify the artifact in the remote
repository given it already resides in my local repository? Since
non-snapshots can never be re-updated, I don't see a need for Maven to make
a remote connection. It seems unnecessary.

Perhaps I am misunderstanding a requirement of Maven. I was really hoping I
could be disconnected from the artifact's remote repository, but evidently
not. Why is Maven acting this way?

Thank you!

Cheers,
Paul

Re: Archetype Catalog Question

[Anders Hammar]

"internal" is a catalog that is bundled with the maven-archetype-plugin. It
would typically never be used as it is very small and probably stale.

"local" is the catalog that is in your local maven repo.

/Anders

On Tue, Jan 30, 2018 at 4:51 PM, KevinO <oneal.ke...@gmail.com> wrote:

> Quick question:
>
> What is the difference between a 'local' catalog and an 'internal' catalog?
>
> Thanks,
>
> Kevin
>

Archetype Catalog Question

[KevinO]

Quick question:

What is the difference between a 'local' catalog and an 'internal' catalog?

Thanks,

Kevin

jacoco-maven-plugin site generation question

[David Hoffer]

I am using jacoco-maven-plugin v0.8.0 to generate test code coverage
reports (and checks) to the build. This is working fine for normal dev
builds, e.g. mvn clean install.

However we also need to include these reports in the Maven site that is
generated and published that part is not working.

The build is a multi-module build and I see you have a link to some ways of
creating an aggregated report, https://github.com/jacoco/
jacoco/wiki/MavenMultiModule, however I am not to the part yet. Right now
I'm just trying to get it to publish the individual reports in the site
build.

The problem is that the site build is including JaCoCo but its labeled
as JaCoCo
Aggregate on each of the modules (and parent) and each of these point to
'target/site/jacoco-aggregate/index.html' however that folder does not
exist. The actual generated report is at target/site/jacoco-ut/index.html.

How can I configure JaCoCo so that it reports the correct name and location
for each report? I have tried various configuration options in the
reporting section but to no avail. It seems hard coded to use
ReportAggregateMojo when it should use ReportMojo (and optionally
ReportITMojo) and I need to provide the outputDirectory when used
indirectly via the site plugin. I will include my config below.

build...


org.jacoco
jacoco-maven-plugin



jacoco-pre-unit-test

prepare-agent




${project.build.directory}/coverage-reports/jacoco-ut.exec

surefireArgLine





jacoco-post-unit-test
test

report





${project.build.directory}/coverage-reports/jacoco-ut.exec


${project.reporting.outputDirectory}/jacoco-ut





jacoco-check
test

check



${project.build.directory}/coverage-reports/jacoco-ut.exec
true



BUNDLE



INSTRUCTION

COVEREDRATIO

${jacoco.percentage.instruction}



BRANCH

COVEREDRATIO

${jacoco.percentage.branch}










jacoco-pre-integration-test
pre-integration-test

prepare-agent



${jacoco.it.execution.data.file}

failsafeArgLine




jacoco-post-integration-test
post-integration-test

report




${jacoco.ut.execution.data.file}


${project.reporting.outputDirectory}/jacoco-it







org.apache.maven.plugins
maven-surefire-plugin
2.15


${surefireArgLine}

${skip.unit.tests}


**/IT*.java





org.apache.maven.plugins
maven-failsafe-plugin
2.15



integration-tests

integration-test
verify



${failsafeArgLine}

${skip.integration.tests}






org.apache.maven.plugins
maven-site-plugin
3.7



reporting...


org.jacoco
jacoco-maven-plugin
0.8.0



Note I'm not running IT tests yet. But ideally when we do I'd like to be
able to publish both sets of reports in the site.


My command line to generate the site is mvn clean package site

-Dave

Re: Javadoc question

[Martin Gainty]

doc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java
:280)
  [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:
160)
  [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:397)
  [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:167)
  [javadoc] at com.sun.tools.javadoc.Main.execute(Main.java:59)
  [javadoc] at com.sun.tools.javadoc.Main.main(Main.java:49)
  [javadoc] com.sun.tools.doclets.internal.toolkit.util.DocletAbortException
  [javadoc] at com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.
parseXML(LayoutParser.java:95)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.
build(ClassBuilder.java:117)
  [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFi
les(HtmlDoclet.java:186)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generat
eClassFiles(AbstractDoclet.java:183)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGe
neration(AbstractDoclet.java:125)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(A
bstractDoclet.java:83)
  [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDocle
t.java:63)
  [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:3
9)
  [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:57)
  [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:43)
  [javadoc] at java.lang.reflect.Method.invoke(Method.java:606)
  [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java
:280)
  [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:
160)
  [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:397)
  [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:167)
  [javadoc] at com.sun.tools.javadoc.Main.execute(Main.java:59)
  [javadoc] at com.sun.tools.javadoc.Main.main(Main.java:49)
  [javadoc] com.sun.tools.doclets.internal.toolkit.util.DocletAbortException
  [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFi
les(HtmlDoclet.java:190)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generat
eClassFiles(AbstractDoclet.java:183)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGe
neration(AbstractDoclet.java:125)
  [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(A
bstractDoclet.java:83)
  [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDocle
t.java:63)
  [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:3
9)
  [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces
sorImpl.java:57)
  [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet
hodAccessorImpl.java:43)
  [javadoc] at java.lang.reflect.Method.invoke(Method.java:606)
  [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java
:280)
  [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:
160)
  [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:397)
  [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:167)
  [javadoc] at com.sun.tools.javadoc.Main.execute(Main.java:59)
  [javadoc] at com.sun.tools.javadoc.Main.main(Main.java:49)
  [javadoc] Generating /woden/woden-dist/target/DISTRO~1/WODEN-~1.0M1
/html/org/apache/woden/xml/ArgumentArrayAttr.html...

BUILD SUCCESSFUL
Total time: 20 seconds


the error suggests at least one of the parameters needs to be a URL but since 
javadoc javadoc is non-existent i dont know

what the binary is complaining about
does anyone have a decompiler i can use?


Thanks James
Martin
__
Quid est arca?





From: Richard W. Adams <rwada...@up.com>
Sent: Monday, June 5, 2017 8:34 AM
To: Maven Users List
Subject: Re: Javadoc question

This seems to be relevant to your issue:

https://stackoverflow.com/questions/13183675/eclipse-javadoc-generation-fails-with-illegalargumentexception
[https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-i...@2.png?v=73d79a89bded]<https://stackoverflow.com/questions/13183675/eclipse-javadoc-generation-fails-with-illegalargumentexception>

Eclipse JavaDoc Generation fails with 
IllegalArgumentException?<https://stackoverflow.com/questions/13183675/eclipse-javadoc-generation-fails-with-illegalargumentexception>
stackoverflow.com
When I attempt to export or generate a javadoc for any of my javadoc commented 
classes I was always getting an error, until recently where it has just been

Re: Javadoc question

[Richard W. Adams]

This seems to be relevant to your issue: 

https://stackoverflow.com/questions/13183675/eclipse-javadoc-generation-fails-with-illegalargumentexception
_

Cogitare extra arca archa



From:   Martin Gainty <mgai...@hotmail.com>
To: "users@maven.apache.org" <users@maven.apache.org>
Date:   06/04/2017 07:41 AM
Subject:    Javadoc question



This email originated from outside of the company.  Please use discretion 
if opening attachments or clicking on links.

i was running this thru maven-javadoc-plugin but saw 
IllegalArgumentException

so I am now attempting to produce Javadoc here is command:


/woden/woden-dist/target/DISTRO~1/WODEN-~1.0M1>javadoc.exe -d 
"/woden/WODEN-~3/target/DISTRO~1/WODEN-~1.0M1/html" -sourcepath 
"/woden/WODEN-~3/target/DISTRO~1/WODEN-~1.0M1" org.apache.woden.xpointer
Loading source files for package org.apache.woden.xpointer...
Constructing Javadoc information...
Standard Doclet version 1.8.0_40
Building tree for all the packages and classes...
Generating /woden/WODEN-~3/target/DISTRO~1/WODEN-~1.0M1/html/org/apac
he/woden/xpointer/ElementPointerPart.html...
java.lang.IllegalArgumentException
at sun.net.www.ParseUtil.decode(Unknown Source)
at sun.misc.URLClassPath$FileLoader.(Unknown Source)
at sun.misc.URLClassPath$3.run(Unknown Source)
at sun.misc.URLClassPath$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.misc.URLClassPath.getLoader(Unknown Source)
at sun.misc.URLClassPath.getLoader(Unknown Source)
at sun.misc.URLClassPath.getNextLoader(Unknown Source)
at sun.misc.URLClassPath.access$100(Unknown Source)
at sun.misc.URLClassPath$1.next(Unknown Source)
at sun.misc.URLClassPath$1.hasMoreElements(Unknown Source)
at java.net.URLClassLoader$3$1.run(Unknown Source)
at java.net.URLClassLoader$3$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(Unknown Source)
at java.net.URLClassLoader$3.hasMoreElements(Unknown Source)
at sun.misc.CompoundEnumeration.next(Unknown Source)
at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source)
at java.util.ServiceLoader$LazyIterator.hasNextService(Unknown 
Source)
at java.util.ServiceLoader$LazyIterator.hasNext(Unknown Source)
at java.util.ServiceLoader$1.hasNext(Unknown Source)
at javax.xml.parsers.FactoryFinder$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.xml.parsers.FactoryFinder.findServiceProvider(Unknown 
Source)
at javax.xml.parsers.FactoryFinder.find(Unknown Source)
at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source)
at 
com.sun.tools.doclets.internal.toolkit.builders.LayoutParser.parseXML
(LayoutParser.java:89)
at 
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(Cl
assBuilder.java:120)
at 
com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(Html
Doclet.java:189)
at 
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFi
les(AbstractDoclet.java:192)
at 
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration
(AbstractDoclet.java:137)
at 
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractD
oclet.java:82)
at 
com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:8
0)
at com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
at 
com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
at com.sun.tools.javadoc.Start.begin(Start.java:219)
at com.sun.tools.javadoc.Start.begin(Start.java:205)
at com.sun.tools.javadoc.Main.execute(Main.java:64)
at com.sun.tools.javadoc.Main.main(Main.java:54)
javadoc: error - java.lang.IllegalArgumentException
1 error


if i had to guess i would say sourcepath is an invalid URL but the usage 
for Javadoc doesnt say sourcepath is URL


i find no help with Javadoc/javadoc where "javadoc working examples" page 
produce 404's

http://www.oracle.com/technetwork/java/javase/documentation/index-137483.html#findjavadoc


Javadoc FAQ - Oracle<
http://www.oracle.com/technetwork/java/javase/documentation/index-137483.html#findjavadoc
>
www.oracle.com
Javadoc Tool Home Page has links to all documentation and