Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)

[Guang Chao]

+1

On Thu, May 9, 2019 at 2:32 PM Bernd Prager  wrote:

> +1
>
> On 9/5/62 01:25, Robert Scholte wrote:
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects and decide if it is worth maintaining.
> >
> > The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
> component that could be used to easily resolve Maven project dependencies.
> The last (and only) released version is 1.0 in September 2009.(
> https://maven.apache.org/shared/maven-artifact-resolver/ [
> https://maven.apache.org/shared/maven-artifact-resolver/] ).
> > This library should not be confused with Artifact Resolver
> (maven-resolver), previously known as Aether. As you can see the naming
> will cause confusion.
> > The library that aims the same goal for Artifact Resolver is another
> shared component called maven-artifact-transfer (which by now is not just
> the transfer part or Artifact Resolver, but a bridge for both Sonatype
> Aether as used in Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+.
> This way Maven plugins and extensions can be compatible with any Maven 3
> release)
> >
> > I therefore propose that we retire the maven-artifact-resolver.
> >
> > I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html [
> https://maven.apache.org/developers/retirement-plan-plugins.html]
> >
> > The vote is open for 72 hours.
> >
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> --
> Bernd Prager
>
> Mobile: +66.91.770.5758
> Skype: bernd.pra...@outlook.com
> PGP Public
> Key: https://pgp.mit.edu/pks/lookup?op=get=0xBDA6C225628DB3CD
> PGP Fingerprint: 0AA3 952C F211 E98A CD18 9E55 BDA6 C225 628D B3CD
>
>
>
>


-- 
Guang 

Re: Maven 3.6.1 & Central Sync Requirements

[Olivier Lamy]

Hi
You have to report this here https://issues.sonatype.org/projects/MVNCENTRAL
and/or the mailing list ossrh-us...@sonatype.org
HTH
Olivier

On Fri, 10 May 2019 at 11:34, Anthony Whitford  wrote:

> My open source project upgraded to Maven 3.6.1 and added
> child.scm.url.inherit.append.path=“false” to the scm tag to correct the
> Source Code Management links:
>
>   http://oss.sonatype.org/>:
> Sources Validation
> POM Validation
> Javadoc Validation
>
> Each validation reports:
>
> > Illegal POM: /org/projectlombok/lombok-maven/
> 1.18.8.0/lombok-maven-1.18.8.0.pom Unknown attribute
> 'child.scm.url.inherit.append.path' for tag 'scm' (position: START_TAG seen
> .../modules>\n\n scm child.scm.url.inherit.append.path="false">...
> @39:50)
>
> Who needs to fix this?  Is this on anyones radar?
>
>

-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy

Maven 3.6.1 & Central Sync Requirements

[Anthony Whitford]

My open source project upgraded to Maven 3.6.1 and added 
child.scm.url.inherit.append.path=“false” to the scm tag to correct the Source 
Code Management links:

  http://oss.sonatype.org/>:
Sources Validation
POM Validation
Javadoc Validation

Each validation reports:

> Illegal POM: 
> /org/projectlombok/lombok-maven/1.18.8.0/lombok-maven-1.18.8.0.pom Unknown 
> attribute 'child.scm.url.inherit.append.path' for tag 'scm' (position: 
> START_TAG seen .../modules>\n\n scm 
> child.scm.url.inherit.append.path="false">... @39:50)

Who needs to fix this?  Is this on anyones radar?

Re: Concurrency issue while running Maven on Jenkins host

[Jason Young]

IME, the default settings for plugins in Jenkins are sometimes objectively
incorrect. One example is the setting Karl referred to. More specifically,
if you are using the Maven plugin for Jenkins, got to your job config ->
Build -> Advanced -> Use private Maven repository. The default setting of
using one repo for all jobs is only correct if you never run more than one
Maven job at a time. Instead, set it to "Local to the executor" to avoid
concurrent access and maximize cache reuse, or "Local to the workspace" for
more isolation. (My Jenkins installation might be old.)

On Thu, May 9, 2019 at 9:33 AM Karl Heinz Marbaise 
wrote:

> Hi,
>
> On 09.05.19 16:09, Frizz wrote:
> >   I regularly suffer from corrupted maven-metadata-local.xml files on my
> > Jenkins host in directory /home/jenkins/.m2/.../some-project/
>
>
> I suppose you are using the local cache for all your jobs?
>
> If so this is the problem. The cache is and was intended for running a
> single build on it...If you run on a CI solution like Jenkins you should
> use the cache per job ...
>
> Kind regards
> Karl Heinz Marbaise
>
>
> >
> > E.g. extra lines added to the end of the maven-metadata-local.xml file
> like
> > this:
> > ...
> >
> > 
> > astUpdated>
> >
> > 
> >
> > Do I suffer from concurrency issues? Like the one described here (created
> > 2007, but still unresolved):
> https://issues.apache.org/jira/browse/MNG-2802
> >
> > What could I do to mitigate the issue?
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Concurrency issue while running Maven on Jenkins host

[Karl Heinz Marbaise]

Hi,

On 09.05.19 16:09, Frizz wrote:

  I regularly suffer from corrupted maven-metadata-local.xml files on my
Jenkins host in directory /home/jenkins/.m2/.../some-project/



I suppose you are using the local cache for all your jobs?

If so this is the problem. The cache is and was intended for running a
single build on it...If you run on a CI solution like Jenkins you should
use the cache per job ...

Kind regards
Karl Heinz Marbaise




E.g. extra lines added to the end of the maven-metadata-local.xml file like
this:
...
   

astUpdated>
   


Do I suffer from concurrency issues? Like the one described here (created
2007, but still unresolved): https://issues.apache.org/jira/browse/MNG-2802

What could I do to mitigate the issue?



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

Concurrency issue while running Maven on Jenkins host

[Frizz]

 I regularly suffer from corrupted maven-metadata-local.xml files on my
Jenkins host in directory /home/jenkins/.m2/.../some-project/

E.g. extra lines added to the end of the maven-metadata-local.xml file like
this:
...
  

astUpdated>
  


Do I suffer from concurrency issues? Like the one described here (created
2007, but still unresolved): https://issues.apache.org/jira/browse/MNG-2802

What could I do to mitigate the issue?

Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)

[Enrico Olivelli]

+1

Enrico

Il gio 9 mag 2019, 08:32 Bernd Prager  ha scritto:

> +1
>
> On 9/5/62 01:25, Robert Scholte wrote:
> > Hi,
> >
> > The Apache Maven project consist of about 100 (sub)projects. Due to the
> small number of volunteers and the huge amount of code to maintain we're
> missing enough space to make real progress on all these projects, including
> our ambitious ideas for the next major version(s) of Maven itself.
> > To be able to gain more focus we need to criticize the current
> subprojects and decide if it is worth maintaining.
> >
> > The Maven Artifact Resolution API (maven-artifact-resolver) is a shared
> component that could be used to easily resolve Maven project dependencies.
> The last (and only) released version is 1.0 in September 2009.(
> https://maven.apache.org/shared/maven-artifact-resolver/ [
> https://maven.apache.org/shared/maven-artifact-resolver/] ).
> > This library should not be confused with Artifact Resolver
> (maven-resolver), previously known as Aether. As you can see the naming
> will cause confusion.
> > The library that aims the same goal for Artifact Resolver is another
> shared component called maven-artifact-transfer (which by now is not just
> the transfer part or Artifact Resolver, but a bridge for both Sonatype
> Aether as used in Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+.
> This way Maven plugins and extensions can be compatible with any Maven 3
> release)
> >
> > I therefore propose that we retire the maven-artifact-resolver.
> >
> > I don't think it makes sense to do a final release. Instead we should
> update the documentation and the freeze the codebase.
> >
> > The process for retiring a plugin is described here:
> > https://maven.apache.org/developers/retirement-plan-plugins.html [
> https://maven.apache.org/developers/retirement-plan-plugins.html]
> >
> > The vote is open for 72 hours.
> >
> > [ ] +1 Yes, it's about time
> > [ ] -1 No, because...
> --
> Bernd Prager
>
> Mobile: +66.91.770.5758
> Skype: bernd.pra...@outlook.com
> PGP Public
> Key: https://pgp.mit.edu/pks/lookup?op=get=0xBDA6C225628DB3CD
> PGP Fingerprint: 0AA3 952C F211 E98A CD18 9E55 BDA6 C225 628D B3CD
>
>
>
>

Re: [surefire] possible bug: cannot set line.separator in systemPropertyVariables

[Tibor Digana]

It sounds like you don't have a problem with Surefire nothing but the
debugger in your IDE.
If not, then again "where you see the issue?   E.g. in surefire-report
files in directory target/surefire-reports/ ?".

> I'd like to be able to debug that failure even though my own OS is
> Unixy.
> Does anybody know a proven method to do that in surefire,
> or a reason why it is impractical and should not be attempted?

Just read the docu:
https://maven.apache.org/surefire/maven-surefire-plugin/examples/debugging.html

If you use IDEA, this plugin may help
https://github.com/harishkannarao/MavenSurefireFailsafeExamples

On Thu, May 9, 2019 at 7:53 AM John Passaro 
wrote:

> Thanks folks for your input.
>
> Reading on the user list archive, I'm realizing my premise may have been
> unclear if you only read it here:
> I didn't use a literal 0x0A byte in the pom, I used the xml entity.
> I'll put it as a java expression in hopes that clients do not render it
> as a literal line feed and potentially cause further confusion:
> "&" + "#x0A;"
>
> On 2019/05/07 21:06:43, Tibor Digana  wrote:
> > line.separator cannot be set as system property, use
> > -Dline.separator=... instead
>
> Is there a way to do this and quote the desired value? I would guess the
> line feed would be interpreted as a word boundary and the effect would be
> to set line.separator to the empty string.
>
> > What version of plugin you use?
> 2.18.1.
>
> > Where you see the stack trace? In console, in text report or XML report?
>
> It most obviously showed up in a place where my tests are comparing a stack
> trace generated by calling guava Throwables.getStackTraceAsString(),
> to an expected constant that includes plain unix-style line feeds.
> When the pom has line.separator, those stack traces are rendered without
> any line breaks at all, and the test fails. I can also see the
> weird-looking
> stack trace, and many others with the same problem, on the console.
>
> > Perhaps we have to see your project. You can post the code with POM on
> Gist
> > but I think we cannot help you more unless we see the POM and try out.
>
> This is fair. Unfortunately I'm not at liberty to share my code
> (proprietary).
> Tried to make a minimum complete reproducible example using
> mvn archetype:generate
> -DarchetypeArtifactId=maven-archetype-quickstart
> -DarchetypeVersion=1.4,
> but I was unable to reproduce the problem.
> If there's anything else I can answer about the pom I'd be happy to do so.
>
> I'd also like to call brief attention to my big picture:
> if tests are passing on a LF system and not on a CRLF system,
> I'd like to be able to debug that failure even though my own OS is
> Unixy. Does anybody know a proven method to do that in surefire,
> or a reason why it is impractical and should not be attempted?
> Such information could make this whole conversation moot.
>
> On 2019/05/07 21:11:41, Laird Nelson  wrote:
> >
> > (a) I thought  in a forked>
> > execution were indeed passed on the command line as -D arguments,
>
> How can I tell whether execution is forked for my project?
> "grep fork pom.xml" prints nothing.
>
> > (b) the behavior may have to do instead with the fact that whitespace in
> XML is>
> > generally not significant so after  is expanded it is effectively>
> > stripped/trimmed from the XML yielding the empty string
>
> This strikes me as the most likely explanation.
>
> > (c) the OP>
> > could try CDATA and an actual line separator character instead, maybe?>
>
> Tried this both on my project and on the MCRE I mentioned above.
> Each behaved the same as with the &-based entity.
>
> Thanks all. I'm very grateful for your time and input.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [VOTE] Retired Maven Artifact Resolution API (Maven2)

[Bernd Prager]

+1

On 9/5/62 01:25, Robert Scholte wrote:
> Hi,
>
> The Apache Maven project consist of about 100 (sub)projects. Due to the small 
> number of volunteers and the huge amount of code to maintain we're missing 
> enough space to make real progress on all these projects, including our 
> ambitious ideas for the next major version(s) of Maven itself.
> To be able to gain more focus we need to criticize the current subprojects 
> and decide if it is worth maintaining.
>
> The Maven Artifact Resolution API (maven-artifact-resolver) is a shared 
> component that could be used to easily resolve Maven project dependencies. 
> The last (and only) released version is 1.0 in September 2009.( 
> https://maven.apache.org/shared/maven-artifact-resolver/ 
> [https://maven.apache.org/shared/maven-artifact-resolver/] ).
> This library should not be confused with Artifact Resolver (maven-resolver), 
> previously known as Aether. As you can see the naming will cause confusion.
> The library that aims the same goal for Artifact Resolver is another shared 
> component called maven-artifact-transfer (which by now is not just the 
> transfer part or Artifact Resolver, but a bridge for both Sonatype Aether as 
> used in Maven 3.0.x and Eclipse Aether as used in Maven 3.1.x+. This way 
> Maven plugins and extensions can be compatible with any Maven 3 release)
>
> I therefore propose that we retire the maven-artifact-resolver.
>
> I don't think it makes sense to do a final release. Instead we should update 
> the documentation and the freeze the codebase.
>
> The process for retiring a plugin is described here:
> https://maven.apache.org/developers/retirement-plan-plugins.html 
> [https://maven.apache.org/developers/retirement-plan-plugins.html]
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
-- 
Bernd Prager
 
Mobile: +66.91.770.5758 
Skype: bernd.pra...@outlook.com 
PGP Public
Key: https://pgp.mit.edu/pks/lookup?op=get=0xBDA6C225628DB3CD 
PGP Fingerprint: 0AA3 952C F211 E98A CD18 9E55 BDA6 C225 628D B3CD