[jira] [Commented] (MNG-6691) Maven protocol specification

2019-07-05 Thread Cservenak, Tamas (JIRA)


[ 
https://issues.apache.org/jira/browse/MNG-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879126#comment-16879126
 ] 

Cservenak, Tamas commented on MNG-6691:
---

Well, in my opinion, best doco is source, and it is up there. You can start by 
looking into Maven Wagon for start (ie. what it does, when issues HEAD, when 
GET, what it does with HTTP 429 response etc.). But frankly, am really unsure 
that you really want yet another Maven repo manager out there, unless you have 
some very good reasons to do so.

Am not aware of any spec, moreover, as maven transport is pluggable (multiple 
wagons can implement HTTP, but there is also takari okhttp transport, etc), and 
Aether by itself has transport, so IMO there is so broad area to doco on Maven 
side, nearly impossible.

On the other hand, you have very good starting point: something like Jetty 
default servlet (or resource handler) for example, as if you use it to "host" 
artifacts, it will "just work". So, what am implying, is that if you go MRM 
route, you basically need a full HTTP support, and you will not mistake. As I 
said, different wagons, aether transport etc may behave wildly different, so 
you have no "one target" to implement. Or to reverse, implement HTTP is your 
best bet.

> Maven protocol specification
> 
>
> Key: MNG-6691
> URL: https://issues.apache.org/jira/browse/MNG-6691
> Project: Maven
>  Issue Type: Wish
>  Components: Documentation:  General
>Reporter: dzikoysk
>Priority: Trivial
>  Labels: documentation
>
> There is a lot of guides and docs about "How to start" on 
> [maven.apache.org|https://maven.apache.org/] with maven as developer who 
> wants to use maven in a project, but I'm not able to find something for 
> people working with repository managers. Is there any technical specification 
> of maven http/protocol specification/rest api and what's required from a 
> custom repository manager to serve requests properly or the only way is to 
> search in maven/other repositories like nexus, artifcatory sources?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (MNG-6581) Maven deploys version metadata multiple times

2019-01-28 Thread Cservenak, Tamas (JIRA)


 [ 
https://issues.apache.org/jira/browse/MNG-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MNG-6581:
--
Affects Version/s: 3.3.9

> Maven deploys version metadata multiple times
> -
>
> Key: MNG-6581
> URL: https://issues.apache.org/jira/browse/MNG-6581
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.3.9, 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0, 3.5.1
>Reporter: Cservenak, Tamas
>Priority: Blocker
>
> This causes problems like MDEPLOY-221 is.
> Problem:
> Maven deploys version metadata multiple times. Seems it is triggered by any 
> plugin that attaches artifact to MavenProject?
> This happens with all 2.x m-deploy-p. 3.0.0-M1 fails.
> Expected:
> Maven deploy version (and any other) metadata only once with proper 
> timestmaps (those that have the deployed artifacts) whatever count of 
> attached artifacts are there.
> Reproducer:
> [https://github.com/cstamas/mvn-md-bug]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (MNG-6581) Maven deploys version metadata multiple times

2019-01-28 Thread Cservenak, Tamas (JIRA)


 [ 
https://issues.apache.org/jira/browse/MNG-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MNG-6581:
--
Description: 
This causes problems like MDEPLOY-221 is.

Problem:

Maven deploys version metadata multiple times. Seems it is triggered by any 
plugin that attaches artifact to MavenProject?

This happens with all 2.x m-deploy-p. 3.0.0-M1 fails.

Expected:

Maven deploy version (and any other) metadata only once with proper timestmaps 
(those that have the deployed artifacts) whatever count of attached artifacts 
are there.

Reproducer:

[https://github.com/cstamas/mvn-md-bug]

  was:
This causes problems like MDEPLOY-221 is.

Problem:

Maven deploys version metadata multiple times. Seems it is triggered by any 
plugin that attaches artifact to MavenProject?

Expected:

Maven deploy version (and any other) metadata only once with proper timestmaps 
(those that have the deployed artifacts) whatever count of attached artifacts 
are there.

Reproducer:

https://github.com/cstamas/mvn-md-bug


> Maven deploys version metadata multiple times
> -
>
> Key: MNG-6581
> URL: https://issues.apache.org/jira/browse/MNG-6581
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories
>Affects Versions: 3.5.0, 3.5.2, 3.5.3, 3.5.4, 3.6.0, 3.5.1
>Reporter: Cservenak, Tamas
>Priority: Blocker
>
> This causes problems like MDEPLOY-221 is.
> Problem:
> Maven deploys version metadata multiple times. Seems it is triggered by any 
> plugin that attaches artifact to MavenProject?
> This happens with all 2.x m-deploy-p. 3.0.0-M1 fails.
> Expected:
> Maven deploy version (and any other) metadata only once with proper 
> timestmaps (those that have the deployed artifacts) whatever count of 
> attached artifacts are there.
> Reproducer:
> [https://github.com/cstamas/mvn-md-bug]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MNG-6581) Maven deploys version metadata multiple times

2019-01-28 Thread Cservenak, Tamas (JIRA)
Cservenak, Tamas created MNG-6581:
-

 Summary: Maven deploys version metadata multiple times
 Key: MNG-6581
 URL: https://issues.apache.org/jira/browse/MNG-6581
 Project: Maven
  Issue Type: Bug
  Components: Artifacts and Repositories
Affects Versions: 3.5.1, 3.6.0, 3.5.4, 3.5.3, 3.5.2, 3.5.0
Reporter: Cservenak, Tamas


This causes problems like MDEPLOY-221 is.

Problem:

Maven deploys version metadata multiple times. Seems it is triggered by any 
plugin that attaches artifact to MavenProject?

Expected:

Maven deploy version (and any other) metadata only once with proper timestmaps 
(those that have the deployed artifacts) whatever count of attached artifacts 
are there.

Reproducer:

https://github.com/cstamas/mvn-md-bug



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8

2018-11-02 Thread Cservenak, Tamas (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16673260#comment-16673260
 ] 

Cservenak, Tamas commented on SUREFIRE-1588:


Tested staged 3.0.0-M1 and it works fine on my machine (where I spotted 
initially the issue).

Linux Mint 19 + openjdk 8 (8u181-b13-1ubuntu0.18.04.1)

Cool beans!

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8

2018-10-31 Thread Cservenak, Tamas (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670209#comment-16670209
 ] 

Cservenak, Tamas commented on SUREFIRE-1588:


A maven-surefire 2.22.1 patch that "works for me":
[https://github.com/apache/maven-surefire/pull/197]

 

But word of warnings: if you build the PR as-is, you a) will *make surefire 
plugin java7* (is java6 currently), and b) will *replace official surefire 
plugin 2.22.1 in your local repo* (something you really don't want unless you 
know what are you doing)

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8

2018-10-31 Thread Cservenak, Tamas (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated SUREFIRE-1588:
---
Summary: Surefire manifest jar classloading broken on latest Debian/Ubuntu 
Java8  (was: Surefire 2.22.1 (and maybe other versions too) are broken on 
latest Ubuntu Java8)

> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1588) Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu Java8

2018-10-31 Thread Cservenak, Tamas (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670107#comment-16670107
 ] 

Cservenak, Tamas commented on SUREFIRE-1588:


Re fix: 
[https://github.com/apache/maven-surefire/blob/7149edc6f24fa8bff06372e24a177e86d4960d8c/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/JarManifestForkConfiguration.java#L110]

 

As the manifest should contain relative paths only (unlike absolute as now), 
and generated "manifest jar" is not meant to be relocated, it could easily 
calculated the relative paths of the classpath entries, and use them instead?

> Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu 
> Java8
> 
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (SUREFIRE-1589) mvn test does not run any test error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

2018-10-31 Thread Cservenak, Tamas (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas resolved SUREFIRE-1589.

Resolution: Duplicate

> mvn test does not run any test error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter
> -
>
> Key: SUREFIRE-1589
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1589
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: tibi
>Priority: Major
>
> when running mvn test on a fresh jhipster* project i get the following error:
>  
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter
> this is the output on console:
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 47.236 s
> [INFO] Finished at: 2018-10-31T13:54:49+01:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
> project stand-bystand: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /home/tibi/git/mvntest/target/surefire-reports for 
> the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/tibi/git/mvntest && 
> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 
> -javaagent:/home/tibi/.m2/repository/org/jacoco/org.jacoco.agent/0.8.2/org.jacoco.agent-0.8.2-runtime.jar=destfile=/home/tibi/git/mvntest/target/test-results/coverage/jacoco/jacoco.exec
>  -Djava.security.egd=file:/dev/./urandom -Xmx256m -jar 
> /home/tibi/git/mvntest/target/surefire/surefirebooter9169551205789441059.jar 
> /home/tibi/git/mvntest/target/surefire 2018-10-31T13-54-48_997-jvmRun1 
> surefire4367139397955700461tmp surefire_09091753917082460771tmp
> [ERROR] Error occurred in starting fork, check output in log
>  
>  
> *jhipster is a java angular project generator. i use it for a year and mvn 
> test worked fine up to today.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1588) Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu Java8

2018-10-31 Thread Cservenak, Tamas (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670087#comment-16670087
 ] 

Cservenak, Tamas commented on SUREFIRE-1588:


Currently several workarounds exists, none of them are w/o problems:
 # Set {{useSystemClassLoader}} = false in POM (this may work if your app is 
"well behaved", see 
[https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html]
 # Set {{jdk.net.URLClassPath.disableClassPathURLCheck=true}} system property 
on forked JVM (see {{argLine}} configuration)

On my setup (again, this is project dependant, see 1. bullet), both works ok.

> Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu 
> Java8
> 
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SUREFIRE-1589) mvn test does not run any test error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter

2018-10-31 Thread Cservenak, Tamas (JIRA)


[ 
https://issues.apache.org/jira/browse/SUREFIRE-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16670076#comment-16670076
 ] 

Cservenak, Tamas commented on SUREFIRE-1589:


"and mvn test worked fine up to today."... what OS are you on? If 
Ubuntu/Debian/Mint (or some derivative), Java updates were sent out yesterday. 
See SUREFIRE-1588 in that case.

> mvn test does not run any test error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter
> -
>
> Key: SUREFIRE-1589
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1589
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: tibi
>Priority: Major
>
> when running mvn test on a fresh jhipster* project i get the following error:
>  
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter
> this is the output on console:
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 47.236 s
> [INFO] Finished at: 2018-10-31T13:54:49+01:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:2.22.0:test (default-test) on 
> project stand-bystand: There are test failures.
> [ERROR] 
> [ERROR] Please refer to /home/tibi/git/mvntest/target/surefire-reports for 
> the individual test results.
> [ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
> [date].dumpstream and [date]-jvmRun[N].dumpstream.
> [ERROR] The forked VM terminated without properly saying goodbye. VM crash or 
> System.exit called?
> [ERROR] Command was /bin/sh -c cd /home/tibi/git/mvntest && 
> /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 
> -javaagent:/home/tibi/.m2/repository/org/jacoco/org.jacoco.agent/0.8.2/org.jacoco.agent-0.8.2-runtime.jar=destfile=/home/tibi/git/mvntest/target/test-results/coverage/jacoco/jacoco.exec
>  -Djava.security.egd=file:/dev/./urandom -Xmx256m -jar 
> /home/tibi/git/mvntest/target/surefire/surefirebooter9169551205789441059.jar 
> /home/tibi/git/mvntest/target/surefire 2018-10-31T13-54-48_997-jvmRun1 
> surefire4367139397955700461tmp surefire_09091753917082460771tmp
> [ERROR] Error occurred in starting fork, check output in log
>  
>  
> *jhipster is a java angular project generator. i use it for a year and mvn 
> test worked fine up to today.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SUREFIRE-1588) Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu Java8

2018-10-31 Thread Cservenak, Tamas (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated SUREFIRE-1588:
---
Description: 
See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
Manifest class path entries to be relative, as defined in [2].

Hence, surefire booter and rest of Maven classpath, that uses absolute URLs are 
simply discarded.

Example error:
{noformat}
# Created at 2018-10-30T21:34:43.339
Error: Could not find or load main class 
org.apache.maven.surefire.booter.ForkedBooter{noformat}
using the new property 
{{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
all the entries from the surefire JAR are simply ignored.

 

[1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]

[2] 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath

[3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]

  was:
See issue [1], but in short: latest Java8 on Ubuntu family of Linuxes (am on 
Mint, Ubuntu derivative) contains this patch [3], and eforces Manifest class 
path entries to be relative, as defined in [2].

Hence, surefire booter and rest of Maven classpath, that uses absolute URLs are 
simply discarded.

Example error:
{noformat}
# Created at 2018-10-30T21:34:43.339
Error: Could not find or load main class 
org.apache.maven.surefire.booter.ForkedBooter{noformat}
using the new property 
{{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
all the entries from the surefire JAR are simply ignored.

 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925

[2] 
[https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath[1]

[3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]


> Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu 
> Java8
> 
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of 
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces 
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2] 
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SUREFIRE-1588) Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu Java8

2018-10-30 Thread Cservenak, Tamas (JIRA)


 [ 
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated SUREFIRE-1588:
---
Description: 
See issue [1], but in short: latest Java8 on Ubuntu family of Linuxes (am on 
Mint, Ubuntu derivative) contains this patch [3], and eforces Manifest class 
path entries to be relative, as defined in [2].

Hence, surefire booter and rest of Maven classpath, that uses absolute URLs are 
simply discarded.

Example error:
{noformat}
# Created at 2018-10-30T21:34:43.339
Error: Could not find or load main class 
org.apache.maven.surefire.booter.ForkedBooter{noformat}
using the new property 
{{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
all the entries from the surefire JAR are simply ignored.

 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925

[2] 
[https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath[1]

[3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]

  was:
See issue [1], but in short: latest Java8 on Ubuntu family of Linuxes (am on 
Mint, Ubuntu derivative) contains this patch [2].

It enforces Class-Path entries as relative. Hence, surefire booter and rest of 
Maven classpath, that uses absolute URLs are simply discarded.

 

[1] 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath[1]

[2] https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac


> Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu 
> Java8
> 
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
>  Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu family of Linuxes (am on 
> Mint, Ubuntu derivative) contains this patch [3], and eforces Manifest class 
> path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs 
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class 
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property 
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that 
> all the entries from the surefire JAR are simply ignored.
>  
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925
> [2] 
> [https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath|https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath[1]
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (SUREFIRE-1588) Surefire 2.22.1 (and maybe other versions too) are broken on latest Ubuntu Java8

2018-10-30 Thread Cservenak, Tamas (JIRA)
Cservenak, Tamas created SUREFIRE-1588:
--

 Summary: Surefire 2.22.1 (and maybe other versions too) are broken 
on latest Ubuntu Java8
 Key: SUREFIRE-1588
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
 Project: Maven Surefire
  Issue Type: Bug
Affects Versions: 2.22.1
Reporter: Cservenak, Tamas


See issue [1], but in short: latest Java8 on Ubuntu family of Linuxes (am on 
Mint, Ubuntu derivative) contains this patch [2].

It enforces Class-Path entries as relative. Hence, surefire booter and rest of 
Maven classpath, that uses absolute URLs are simply discarded.

 

[1] 
https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath[1]

[2] https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Closed] (MINDEXER-24) Publish indexer site

2017-11-28 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-24.

Resolution: Fixed

> Publish indexer site
> 
>
> Key: MINDEXER-24
> URL: https://issues.apache.org/jira/browse/MINDEXER-24
> Project: Maven Indexer
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
> Fix For: 6.0.0
>
>
> Publish indexer site
> http://maven.apache.org/maven-indexer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-83.

Resolution: Fixed

> Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new 
> ones) so that it is possible to add artifact files one by one
> --
>
> Key: MINDEXER-83
> URL: https://issues.apache.org/jira/browse/MINDEXER-83
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> The currently existing method only accepts a list of files. This assumes you 
> already have a list of the files. However, this is inconvenient for use if 
> you have the artifact files coming one by one (for example when deploying an 
> artifact over over HTTP).
> This method should be re-worked and it would be great if some new methods 
> could be introduced for when adding files which belong to a particular 
> artifact.
> It would also be great if there could be methods that accept (File file, 
> Artifact artifact, ..) when adding and updating an artifact to the index.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one

2017-11-24 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265224#comment-16265224
 ] 

Cservenak, Tamas commented on MINDEXER-83:
--

Merged as 
https://github.com/apache/maven-indexer/commit/339eec6052a74fea91a99da2e33cbbd6a95aee3f

> Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new 
> ones) so that it is possible to add artifact files one by one
> --
>
> Key: MINDEXER-83
> URL: https://issues.apache.org/jira/browse/MINDEXER-83
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> The currently existing method only accepts a list of files. This assumes you 
> already have a list of the files. However, this is inconvenient for use if 
> you have the artifact files coming one by one (for example when deploying an 
> artifact over over HTTP).
> This method should be re-worked and it would be great if some new methods 
> could be introduced for when adding files which belong to a particular 
> artifact.
> It would also be great if there could be methods that accept (File file, 
> Artifact artifact, ..) when adding and updating an artifact to the index.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-108) Lift restriction on leading wildcard queries

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-108.
-
Resolution: Fixed

> Lift restriction on leading wildcard queries
> 
>
> Key: MINDEXER-108
> URL: https://issues.apache.org/jira/browse/MINDEXER-108
> Project: Maven Indexer
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Andreas Sewe
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> The {{DefaultQueryCreator}} prevents queries with leading wildcard:
> {noformat}
> if ( query.startsWith( "*" ) || query.startsWith( "?" ) )
> {
> throw new ParseException( "Query cannot start with '*' or '?'!" );
> }
> {noformat}
> While this was necessary in older versions of Lucene, the version used now 
> happily executes such queries. The restriction can thus be lifted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions

2017-11-24 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265215#comment-16265215
 ] 

Cservenak, Tamas commented on MINDEXER-88:
--

https://github.com/apache/maven-indexer/commit/ad07405c06b422cb529d3badaa1b6b376699c9c1
https://github.com/apache/maven-indexer/commit/fc801678e2e46513e4dda8973bcb06ef4f105b69

> Clean up the plugin versions and possibly upgrade the plugins to their latest 
> versions
> --
>
> Key: MINDEXER-88
> URL: https://issues.apache.org/jira/browse/MINDEXER-88
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> When building with Maven 3.2.1, the following warning can be seen:
> {code}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-core:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-cli:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-examples:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:maven-indexer:pom:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 499, column 
> 15
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> {code}
> Essentially, these versions should be set and furthermore, the plugin 
> versions should be updated to their latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-88.

Resolution: Fixed

> Clean up the plugin versions and possibly upgrade the plugins to their latest 
> versions
> --
>
> Key: MINDEXER-88
> URL: https://issues.apache.org/jira/browse/MINDEXER-88
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> When building with Maven 3.2.1, the following warning can be seen:
> {code}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-core:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-cli:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-examples:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:maven-indexer:pom:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 499, column 
> 15
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> {code}
> Essentially, these versions should be set and furthermore, the plugin 
> versions should be updated to their latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas reassigned MINDEXER-88:


Assignee: Cservenak, Tamas

> Clean up the plugin versions and possibly upgrade the plugins to their latest 
> versions
> --
>
> Key: MINDEXER-88
> URL: https://issues.apache.org/jira/browse/MINDEXER-88
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> When building with Maven 3.2.1, the following warning can be seen:
> {code}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-core:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-cli:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-examples:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:maven-indexer:pom:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 499, column 
> 15
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> {code}
> Essentially, these versions should be set and furthermore, the plugin 
> versions should be updated to their latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Reopened] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas reopened MINDEXER-88:
--

> Clean up the plugin versions and possibly upgrade the plugins to their latest 
> versions
> --
>
> Key: MINDEXER-88
> URL: https://issues.apache.org/jira/browse/MINDEXER-88
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> When building with Maven 3.2.1, the following warning can be seen:
> {code}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-core:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-cli:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-examples:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:maven-indexer:pom:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 499, column 
> 15
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> {code}
> Essentially, these versions should be set and furthermore, the plugin 
> versions should be updated to their latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-24) Publish indexer site

2017-11-24 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265139#comment-16265139
 ] 

Cservenak, Tamas commented on MINDEXER-24:
--

Do we need anything more with this issue? Or should I move it out of 6.0 fix 
version to continue with release?

> Publish indexer site
> 
>
> Key: MINDEXER-24
> URL: https://issues.apache.org/jira/browse/MINDEXER-24
> Project: Maven Indexer
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
> Fix For: 6.0
>
>
> Publish indexer site
> http://maven.apache.org/maven-indexer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-81) Make ArtifactInfo extensible

2017-11-24 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265136#comment-16265136
 ] 

Cservenak, Tamas commented on MINDEXER-81:
--

Completely agreed and the comment above is in agreement with foreseen change. 
Still, am moving this change out of 6.0 release, as it would introduce breaking 
change (ArtifactInfo would need to be rewritten), will be done post 6.0

> Make ArtifactInfo extensible
> 
>
> Key: MINDEXER-81
> URL: https://issues.apache.org/jira/browse/MINDEXER-81
> Project: Maven Indexer
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
>
> Make ArtifactInfo extensible, a followup of MINDEXER-32



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (MINDEXER-81) Make ArtifactInfo extensible

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-81:
-
Fix Version/s: (was: 6.0)

> Make ArtifactInfo extensible
> 
>
> Key: MINDEXER-81
> URL: https://issues.apache.org/jira/browse/MINDEXER-81
> Project: Maven Indexer
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
>
> Make ArtifactInfo extensible, a followup of MINDEXER-32



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one

2017-11-24 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265135#comment-16265135
 ] 

Cservenak, Tamas commented on MINDEXER-83:
--

"Sneaked" into PR
https://github.com/apache/maven-indexer/pull/21

> Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new 
> ones) so that it is possible to add artifact files one by one
> --
>
> Key: MINDEXER-83
> URL: https://issues.apache.org/jira/browse/MINDEXER-83
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> The currently existing method only accepts a list of files. This assumes you 
> already have a list of the files. However, this is inconvenient for use if 
> you have the artifact files coming one by one (for example when deploying an 
> artifact over over HTTP).
> This method should be re-worked and it would be great if some new methods 
> could be introduced for when adding files which belong to a particular 
> artifact.
> It would also be great if there could be methods that accept (File file, 
> Artifact artifact, ..) when adding and updating an artifact to the index.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas reassigned MINDEXER-83:


Assignee: Cservenak, Tamas

> Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new 
> ones) so that it is possible to add artifact files one by one
> --
>
> Key: MINDEXER-83
> URL: https://issues.apache.org/jira/browse/MINDEXER-83
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> The currently existing method only accepts a list of files. This assumes you 
> already have a list of the files. However, this is inconvenient for use if 
> you have the artifact files coming one by one (for example when deploying an 
> artifact over over HTTP).
> This method should be re-worked and it would be great if some new methods 
> could be introduced for when adding files which belong to a particular 
> artifact.
> It would also be great if there could be methods that accept (File file, 
> Artifact artifact, ..) when adding and updating an artifact to the index.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-87) Remove legacy marked code

2017-11-24 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16265131#comment-16265131
 ] 

Cservenak, Tamas commented on MINDEXER-87:
--

Moving out of 6.x release, as according to ML feedback, folks are using 
(locally built) master, and this change may introduce incompatible changes (as 
new API, the {{Indexer}} does not fully cover {{NexusIndexer}}, so moving post 
6.0

> Remove legacy marked code
> -
>
> Key: MINDEXER-87
> URL: https://issues.apache.org/jira/browse/MINDEXER-87
> Project: Maven Indexer
>  Issue Type: Bug
>Reporter: Cservenak, Tamas
>
> Remove legacy code and also some of the unneded cruft (yes, we do plan to 
> break API a bit).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (MINDEXER-87) Remove legacy marked code

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-87:
-
Fix Version/s: (was: 6.0)

> Remove legacy marked code
> -
>
> Key: MINDEXER-87
> URL: https://issues.apache.org/jira/browse/MINDEXER-87
> Project: Maven Indexer
>  Issue Type: Bug
>Reporter: Cservenak, Tamas
>
> Remove legacy code and also some of the unneded cruft (yes, we do plan to 
> break API a bit).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Assigned] (MINDEXER-108) Lift restriction on leading wildcard queries

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas reassigned MINDEXER-108:
-

Assignee: Cservenak, Tamas

> Lift restriction on leading wildcard queries
> 
>
> Key: MINDEXER-108
> URL: https://issues.apache.org/jira/browse/MINDEXER-108
> Project: Maven Indexer
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Andreas Sewe
>Assignee: Cservenak, Tamas
> Fix For: 6.0
>
>
> The {{DefaultQueryCreator}} prevents queries with leading wildcard:
> {noformat}
> if ( query.startsWith( "*" ) || query.startsWith( "?" ) )
> {
> throw new ParseException( "Query cannot start with '*' or '?'!" );
> }
> {noformat}
> While this was necessary in older versions of Lucene, the version used now 
> happily executes such queries. The restriction can thus be lifted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-106) ClassNotFoundException (org.sonatype.aether.version.InvalidVersionSpecificationException) under recent Maven versions

2017-11-24 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-106.
-
Resolution: Fixed

Release 6.x makes maven-indexer compatible with maven 3.1+. With it, now same 
problem will stand for 3.0- line of maven, but they can still use older 
releases.

> ClassNotFoundException 
> (org.sonatype.aether.version.InvalidVersionSpecificationException) under 
> recent Maven versions
> -
>
> Key: MINDEXER-106
> URL: https://issues.apache.org/jira/browse/MINDEXER-106
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
>Reporter: Andreas Sewe
> Fix For: 6.0
>
>
> It is impossible to use the latest released {{indexer-core}} (version 5.1.1) 
> in a mojo executing under a recent version of Maven (3.5.0):
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: 
> org/sonatype/aether/version/InvalidVersionSpecificationException
>   at 
> org.apache.maven.index.context.IndexUtils.constructArtifactInfo(IndexUtils.java:111)
>   at 
> org.apache.maven.index.context.IndexUtils.updateDocument(IndexUtils.java:135)
>   at 
> org.apache.maven.index.updater.IndexDataReader.readIndex(IndexDataReader.java:92)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.unpackIndexData(DefaultIndexUpdater.java:509)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:197)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:862)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
>   ...
> Caused by: java.lang.ClassNotFoundException: 
> org.sonatype.aether.version.InvalidVersionSpecificationException
>   at 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-108) Lift restriction on leading wildcard queries

2017-11-23 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264805#comment-16264805
 ] 

Cservenak, Tamas commented on MINDEXER-108:
---

What versions of lucene accepts {{*}} as prefix? Current master uses Lucene 5.x 
and it does not accept it...

> Lift restriction on leading wildcard queries
> 
>
> Key: MINDEXER-108
> URL: https://issues.apache.org/jira/browse/MINDEXER-108
> Project: Maven Indexer
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Andreas Sewe
> Fix For: 6.0
>
>
> The {{DefaultQueryCreator}} prevents queries with leading wildcard:
> {noformat}
> if ( query.startsWith( "*" ) || query.startsWith( "?" ) )
> {
> throw new ParseException( "Query cannot start with '*' or '?'!" );
> }
> {noformat}
> While this was necessary in older versions of Lucene, the version used now 
> happily executes such queries. The restriction can thus be lifted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-88.

Resolution: Fixed

Fixed with https://github.com/apache/maven-indexer/pull/21



> Clean up the plugin versions and possibly upgrade the plugins to their latest 
> versions
> --
>
> Key: MINDEXER-88
> URL: https://issues.apache.org/jira/browse/MINDEXER-88
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
>
> When building with Maven 3.2.1, the following warning can be seen:
> {code}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-core:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-cli:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-examples:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:maven-indexer:pom:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 499, column 
> 15
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> {code}
> Essentially, these versions should be set and furthermore, the plugin 
> versions should be updated to their latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-88:
-
Fix Version/s: 6.0

> Clean up the plugin versions and possibly upgrade the plugins to their latest 
> versions
> --
>
> Key: MINDEXER-88
> URL: https://issues.apache.org/jira/browse/MINDEXER-88
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Martin Todorov
> Fix For: 6.0
>
>
> When building with Maven 3.2.1, the following warning can be seen:
> {code}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-core:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-cli:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:indexer-examples:jar:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ 
> org.apache.maven.indexer:maven-indexer:6.0-SNAPSHOT, 
> /root/.jenkins/jobs/maven-indexer/workspace/pom.xml, line 499, column 15
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for org.apache.maven.indexer:maven-indexer:pom:6.0-SNAPSHOT
> [WARNING] 'reporting.plugins.plugin.version' for 
> org.apache.maven.plugins:maven-javadoc-plugin is missing. @ line 499, column 
> 15
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> {code}
> Essentially, these versions should be set and furthermore, the plugin 
> versions should be updated to their latest versions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-39) study how to have maven-indexer non plexus/sisu dependant

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-39.

Resolution: Fixed

Fixed, indexer core is not plexus anymore

> study how to have maven-indexer non plexus/sisu dependant
> -
>
> Key: MINDEXER-39
> URL: https://issues.apache.org/jira/browse/MINDEXER-39
> Project: Maven Indexer
>  Issue Type: Sub-task
>Reporter: Olivier Lamy (*$^¨%`£)
> Fix For: 6.0
>
>
> The current impl is heavy container dependant (plexus/sisu).
> It could be nice to have something using pure/standard injection (@Inject).
> As it will be easy reusable in other DI container



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-49.

Resolution: Won't Fix

We cannot "guess" the classifier if it contains dots for now. 

Best "workaround" is to not use dots in classifier.

> M2GavCalculator does not parse GAV correctly for classifiers with dots
> --
>
> Key: MINDEXER-49
> URL: https://issues.apache.org/jira/browse/MINDEXER-49
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 4.1.1, 4.1.2
> Environment: all
>Reporter: René Zanner
>Priority: Critical
>
> When having a classifier with dots (classifier.with.dots) and an extension 
> with or without dots (e.g. tar.gz), the calculation of Gav changes classifier 
> and type/extension to something clearly not intended:
> || ||Attached artifact definition||M2GavCalculator result||
> ||classifier|classifier.with.dots|classifier|
> ||extension/type|tar.gz|with.dots.tar.gz|
> The problem seems to be located in lines 136ff, 175ff *and* 216ff (do you 
> have a code duplication issue as well? ;-) ): 
> {code}
> int nExtPos = tail.indexOf( '.' );
> ...
> ext = tail.substring( nExtPos + 1 );
> classifier = tail.charAt( 0 ) == '-' ? tail.substring( 1, nExtPos ) : null;
> {code}
> This code assumes that the classifier ends at the first dot in the "tail" 
> (which is everything after the version number).
> Since Maven allows dots in classifiers _as well as in extensions_, the 
> parsing has to be made more intelligent. So, it is not enough to just turn 
> the parsing around and use the part after the last dot as extension and 
> before it as classifier (that's why I used the 'tar.gz' extension in my 
> example above).
> I do not have a solution for this except checking for well-known extensions 
> (tar.gz, xml, jar, zip, a.s.o.) and build the classifier/extension parsing 
> around it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-80) Drop Plexus as DI, use JSR330

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-80.

Resolution: Fixed

> Drop Plexus as DI, use JSR330
> -
>
> Key: MINDEXER-80
> URL: https://issues.apache.org/jira/browse/MINDEXER-80
> Project: Maven Indexer
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> Drop Plexus as required dependency, switch to JSR330
> This would also imply:
> * dropping all plexus related deps (annos, container)
> * use of SISU as container
> * use of SLF4J for logging
> * use of guava instead of p-u
> Still, with SISU plexus shim, it should be is possible to use the library 
> with plx components too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-80) Drop Plexus as DI, use JSR330

2017-11-23 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264787#comment-16264787
 ] 

Cservenak, Tamas commented on MINDEXER-80:
--

This is fixed, but p-u use is still in and will remain in, as we use modello 
and other stuff that already pulls in p-u. Unsure about switch to guava, 
actually I'd back out of it :)

> Drop Plexus as DI, use JSR330
> -
>
> Key: MINDEXER-80
> URL: https://issues.apache.org/jira/browse/MINDEXER-80
> Project: Maven Indexer
>  Issue Type: Improvement
>Reporter: Cservenak, Tamas
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> Drop Plexus as required dependency, switch to JSR330
> This would also imply:
> * dropping all plexus related deps (annos, container)
> * use of SISU as container
> * use of SLF4J for logging
> * use of guava instead of p-u
> Still, with SISU plexus shim, it should be is possible to use the library 
> with plx components too.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (MINDEXER-106) ClassNotFoundException (org.sonatype.aether.version.InvalidVersionSpecificationException) under recent Maven versions

2017-11-23 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264782#comment-16264782
 ] 

Cservenak, Tamas commented on MINDEXER-106:
---

Aether was sonatype first, then donated to eclipse. Similar issue like maven 
3.0 vs 3.1+ (affected by package change).

Indexer is will use {{org.apache.maven.resolver:maven-resolver-api}} (that due 
to compatibility uses {{org.eclipse.aether}} package name.

> ClassNotFoundException 
> (org.sonatype.aether.version.InvalidVersionSpecificationException) under 
> recent Maven versions
> -
>
> Key: MINDEXER-106
> URL: https://issues.apache.org/jira/browse/MINDEXER-106
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
>Reporter: Andreas Sewe
> Fix For: 6.0
>
>
> It is impossible to use the latest released {{indexer-core}} (version 5.1.1) 
> in a mojo executing under a recent version of Maven (3.5.0):
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: 
> org/sonatype/aether/version/InvalidVersionSpecificationException
>   at 
> org.apache.maven.index.context.IndexUtils.constructArtifactInfo(IndexUtils.java:111)
>   at 
> org.apache.maven.index.context.IndexUtils.updateDocument(IndexUtils.java:135)
>   at 
> org.apache.maven.index.updater.IndexDataReader.readIndex(IndexDataReader.java:92)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.unpackIndexData(DefaultIndexUpdater.java:509)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:197)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:862)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
>   ...
> Caused by: java.lang.ClassNotFoundException: 
> org.sonatype.aether.version.InvalidVersionSpecificationException
>   at 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (MINDEXER-106) ClassNotFoundException (org.sonatype.aether.version.InvalidVersionSpecificationException) under recent Maven versions

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-106:
--
Fix Version/s: 6.0

> ClassNotFoundException 
> (org.sonatype.aether.version.InvalidVersionSpecificationException) under 
> recent Maven versions
> -
>
> Key: MINDEXER-106
> URL: https://issues.apache.org/jira/browse/MINDEXER-106
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T21:39:06+02:00)
>Reporter: Andreas Sewe
> Fix For: 6.0
>
>
> It is impossible to use the latest released {{indexer-core}} (version 5.1.1) 
> in a mojo executing under a recent version of Maven (3.5.0):
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: 
> org/sonatype/aether/version/InvalidVersionSpecificationException
>   at 
> org.apache.maven.index.context.IndexUtils.constructArtifactInfo(IndexUtils.java:111)
>   at 
> org.apache.maven.index.context.IndexUtils.updateDocument(IndexUtils.java:135)
>   at 
> org.apache.maven.index.updater.IndexDataReader.readIndex(IndexDataReader.java:92)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.unpackIndexData(DefaultIndexUpdater.java:509)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.loadIndexDirectory(DefaultIndexUpdater.java:197)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.access$300(DefaultIndexUpdater.java:76)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater$LuceneIndexAdaptor.setIndexFile(DefaultIndexUpdater.java:642)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:862)
>   at 
> org.apache.maven.index.updater.DefaultIndexUpdater.fetchAndUpdateIndex(DefaultIndexUpdater.java:157)
>   ...
> Caused by: java.lang.ClassNotFoundException: 
> org.sonatype.aether.version.InvalidVersionSpecificationException
>   at 
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
>   at 
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (MINDEXER-108) Lift restriction on leading wildcard queries

2017-11-23 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-108:
--
Fix Version/s: 6.0

> Lift restriction on leading wildcard queries
> 
>
> Key: MINDEXER-108
> URL: https://issues.apache.org/jira/browse/MINDEXER-108
> Project: Maven Indexer
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Andreas Sewe
> Fix For: 6.0
>
>
> The {{DefaultQueryCreator}} prevents queries with leading wildcard:
> {noformat}
> if ( query.startsWith( "*" ) || query.startsWith( "?" ) )
> {
> throw new ParseException( "Query cannot start with '*' or '?'!" );
> }
> {noformat}
> While this was necessary in older versions of Lucene, the version used now 
> happily executes such queries. The restriction can thus be lifted.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Closed] (MINDEXER-99) improve performance loss introduced in MINDEXER-77

2017-03-31 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-99.

Resolution: Fixed

> improve performance loss introduced in MINDEXER-77
> --
>
> Key: MINDEXER-99
> URL: https://issues.apache.org/jira/browse/MINDEXER-99
> Project: Maven Indexer
>  Issue Type: Improvement
>Affects Versions: 6.0
>Reporter: Tomas Stupka
> Fix For: 6.0
>
>
> even though lucene upgrade from 3.6 to 4.8.1 significantly reduced disk space 
> usage, the unfortunate tradeoff is, that the indexer now needs approximately 
> 2.5  times longer - 120s vs 300s, measured by using the indexer in current 
> NetBeans dev build.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (MINDEXER-102) Forward port OSGI related index-reader changes to master (Changes relative to MINDEXER-100 branch)

2017-03-31 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-102.
-
Resolution: Fixed

> Forward port OSGI related index-reader changes to master (Changes relative to 
> MINDEXER-100 branch) 
> ---
>
> Key: MINDEXER-102
> URL: https://issues.apache.org/jira/browse/MINDEXER-102
> Project: Maven Indexer
>  Issue Type: Task
>Affects Versions: 6.0
>Reporter: Simon Spero
> Fix For: 6.0
>
>
> Forward port the OSGI related changes to index-reader from MINDEXER-97 .
> Changes must be made relative to MINDEXER-100 branch



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (MINDEXER-101) Forward port OSGI improvements (MINDEXER-97) to master

2017-03-31 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-101:
--
Fix Version/s: 6.0

> Forward port OSGI improvements (MINDEXER-97) to master
> --
>
> Key: MINDEXER-101
> URL: https://issues.apache.org/jira/browse/MINDEXER-101
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Simon Spero
> Fix For: 6.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (MINDEXER-101) Forward port OSGI improvements (MINDEXER-97) to master

2017-03-31 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-101.
-

> Forward port OSGI improvements (MINDEXER-97) to master
> --
>
> Key: MINDEXER-101
> URL: https://issues.apache.org/jira/browse/MINDEXER-101
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Simon Spero
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (MINDEXER-101) Forward port OSGI improvements (MINDEXER-97) to master

2017-03-31 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas resolved MINDEXER-101.
---
Resolution: Fixed

> Forward port OSGI improvements (MINDEXER-97) to master
> --
>
> Key: MINDEXER-101
> URL: https://issues.apache.org/jira/browse/MINDEXER-101
> Project: Maven Indexer
>  Issue Type: Task
>Reporter: Simon Spero
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (MINDEXER-100) Forward port changes in 5.1.2-SNAPSHOT (maven-indexer-5.x) to 6.0.0-SNAPSHOT (master)

2017-03-31 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas closed MINDEXER-100.
-
Resolution: Fixed

> Forward port changes in 5.1.2-SNAPSHOT (maven-indexer-5.x) to 6.0.0-SNAPSHOT 
> (master)
> -
>
> Key: MINDEXER-100
> URL: https://issues.apache.org/jira/browse/MINDEXER-100
> Project: Maven Indexer
>  Issue Type: Task
>Affects Versions: 6.0
>Reporter: Simon Spero
> Fix For: 6.0
>
>
> The master branch and the 5.x branch have diverged, with new components  like 
> the index-reader module not included in master.
>   
> I have submitted github pull requests against the 5.x  (MINDEXER-97) which 
> should also be included in master. 
> Commits 5.x made since the  divergence from master should be reviewed, and 
> forward ported to master if still relevant 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (WAGON-452) Missing exception handling when maven.wagon.http.ssl.ignore.validity.dates flag is set to 'true'

2016-10-14 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/WAGON-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15574951#comment-15574951
 ] 

Cservenak, Tamas commented on WAGON-452:


This feature is definitely broken, just tried directly to use it (as that above 
is from a project, so _it could be project env messing around_, but seems is 
not). Most straightforward attempt:
{noformat}
cstamas@Slartibartfast tmp]$ mvn deploy:deploy-file -Dfile=tika-out.zip 
-Durl=https://otto.takari.io/service/local/staging/deploy/maven2 
-DgroupId=io.takari.test -DartifactId=test -Dversion=1.0 
-Dmaven.wagon.http.ssl.insecure=true 
-Dmaven.wagon.http.ssl.ignore.validity.dates=true
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=512m; 
support was removed in 8.0
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building Maven Stub Project (No POM) 1
[INFO] 
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy-file (default-cli) @ standalone-pom 
---
Uploading: 
https://otto.takari.io/service/local/staging/deploy/maven2/io/takari/test/test/1.0/test-1.0.zip
Uploading: 
https://otto.takari.io/service/local/staging/deploy/maven2/io/takari/test/test/1.0/test-1.0.pom
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 1.173 s
[INFO] Finished at: 2016-10-14T12:44:27+02:00
[INFO] Final Memory: 9M/254M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file (default-cli) on 
project standalone-pom: Failed to deploy artifacts: Could not transfer artifact 
io.takari.test:test:zip:1.0 from/to remote-repository 
(https://otto.takari.io/service/local/staging/deploy/maven2): 
sun.security.validator.ValidatorException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: timestamp check failed: 
NotAfter: Fri Oct 14 01:59:59 CEST 2016 -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[cstamas@Slartibartfast tmp]$ 
{noformat}

> Missing exception handling when maven.wagon.http.ssl.ignore.validity.dates 
> flag is set to 'true'
> 
>
> Key: WAGON-452
> URL: https://issues.apache.org/jira/browse/WAGON-452
> Project: Maven Wagon
>  Issue Type: Bug
>  Components: wagon-http
>Affects Versions: 2.10
>Reporter: Vítor Teixeira
>  Labels: easyfix, maven, security
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> On org.apache.maven.wagon.providers.http.RelaxedTrustStrategy exception 
> handling is missing.
> With maven.wagon.http.ssl.ignore.validity.dates=true the following exception 
> is thrown:
> sun.security.validator.ValidatorException: PKIX path validation failed: 
> java.security.cert.CertPathValidatorException: timestamp check failed: 
> NotAfter: Tue Dec 29 23:59:59 GMT 2015 -> [Help 1]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (WAGON-452) Missing exception handling when maven.wagon.http.ssl.ignore.validity.dates flag is set to 'true'

2016-10-14 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/WAGON-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15574927#comment-15574927
 ] 

Cservenak, Tamas commented on WAGON-452:


Same here, or at least something similar, the "ignore validity dates" did not 
work for me with HTTPS server having {{NotAfter}} expired.

Though **I did set both properties, as ignore validity dates requires ssl 
insecure too** to work: used on cmd line:
{{-Dmaven.wagon.http.ssl.insecure=true -D 
maven.wagon.http.ssl.ignore.validity.dates=true}}

Build failed and this is exception I got:
{noformat}
[INFO] [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy (default-deploy) on 
project additions: Failed to deploy artifacts: Could not transfer artifact 
io.takari.nexus:additions:pom:1.6.1 from/to takari.releases 
(https://otto.takari.io/service/local/staging/deploy/maven2): 
sun.security.validator.ValidatorException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: timestamp check failed: 
NotAfter: Fri Oct 14 01:59:59 CEST 2016 -> [Help 1]
[INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to 
execute goal org.apache.maven.plugins:maven-deploy-plugin:2.6:deploy 
(default-deploy) on project additions: Failed to deploy artifacts: Could not 
transfer artifact io.takari.nexus:additions:pom:1.6.1 from/to takari.releases 
(https://otto.takari.io/service/local/staging/deploy/maven2): 
sun.security.validator.ValidatorException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: timestamp check failed
[INFO]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
[INFO]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[INFO]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[INFO]  at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
[INFO]  at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
[INFO]  at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[INFO]  at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
[INFO]  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
[INFO]  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
[INFO]  at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
[INFO]  at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[INFO]  at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
[INFO]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[INFO]  at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[INFO]  at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[INFO]  at java.lang.reflect.Method.invoke(Method.java:498)
[INFO]  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[INFO]  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[INFO]  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[INFO]  at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[INFO] Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to 
deploy artifacts: Could not transfer artifact 
io.takari.nexus:additions:pom:1.6.1 from/to takari.releases 
(https://otto.takari.io/service/local/staging/deploy/maven2): 
sun.security.validator.ValidatorException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: timestamp check failed
[INFO]  at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:192)
[INFO]  at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[INFO]  at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
[INFO]  ... 20 more
[INFO] Caused by: 
org.apache.maven.artifact.deployer.ArtifactDeploymentException: Failed to 
deploy artifacts: Could not transfer artifact 
io.takari.nexus:additions:pom:1.6.1 from/to takari.releases 
(https://otto.takari.io/service/local/staging/deploy/maven2): 
sun.security.validator.ValidatorException: PKIX path validation failed: 
java.security.cert.CertPathValidatorException: timestamp check failed
[INFO]  at 
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:143)
[INFO]  at 
org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:148)
[INFO]  ... 22 more
[INFO] Caused by: org.eclipse.aether.deployment.DeploymentException: Failed to 
deploy artifacts: Could not transfer artifact 
io.takari.nexus:additions:pom:1.6.1 from/to 

[jira] [Commented] (MNG-6008) Aether code import to git

2016-09-15 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-6008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15492697#comment-15492697
 ] 

Cservenak, Tamas commented on MNG-6008:
---

What happens with https://github.com/apache/maven-aether as it is still there 
(while new mirror is also there).

> Aether code import to git
> -
>
> Key: MNG-6008
> URL: https://issues.apache.org/jira/browse/MNG-6008
> Project: Maven
>  Issue Type: Sub-task
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Need a temporary maven-aether.git repository to start working on license 
> headers etc... while defining if we can continue to use the Aether name
> If not, in the future, we'll need to rename the repo



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (MNG-6086) Eclipse.org site is down, and you are unable to build Maven?

2016-09-07 Thread Cservenak, Tamas (JIRA)
Cservenak, Tamas created MNG-6086:
-

 Summary: Eclipse.org site is down, and you are unable to build 
Maven?
 Key: MNG-6086
 URL: https://issues.apache.org/jira/browse/MNG-6086
 Project: Maven
  Issue Type: Bug
  Components: Bootstrap & Build
Reporter: Cservenak, Tamas


Was trying to build Maven locally, just to see it is failing (actually, too way 
long was stuck in console). Had no idea what is happening until I did {{-X}}, 
to see it is {{maven-remote-resources-plugin}} (see below).

I am quite surprised to see, that if {{eclipse.org}} site is down (as in this 
moment), one cannot build Apache Maven, and I find it quite ironic.

{noformat}
[DEBUG] URLResourceLoader: Exception when looking for 
'http://www.eclipse.org/legal/epl-v10.html' at ''
java.net.SocketException: Unexpected end of file from server
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:792)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:789)
at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:647)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1536)
at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
at java.net.URL.openStream(URL.java:1045)
at 
org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:73)
at 
org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
at 
org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
at sun.reflect.GeneratedMethodAccessor69.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.doInvoke(UberspectImpl.java:395)
at 
org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:384)
at 
org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:173)
at 
org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:280)
at 
org.apache.velocity.runtime.parser.node.ASTReference.value(ASTReference.java:567)
at 
org.apache.velocity.runtime.parser.node.ASTExpression.value(ASTExpression.java:71)
at 
org.apache.velocity.runtime.parser.node.ASTSetDirective.render(ASTSetDirective.java:142)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at 
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at 
org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:87)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at 
org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420)
at 
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
at 
org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
at 
org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420)
at 
org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
at 
org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
at 
org.apache.velocity.runtime.RuntimeInstance.render(RuntimeInstance.java:1378)
at 
org.apache.velocity.runtime.RuntimeInstance.evaluate(RuntimeInstance.java:1314)
at org.apache.velocity.app.Velocity.evaluate(Velocity.java:254)
at 
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1218)
at 
org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:520)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
 

[jira] [Created] (MINDEXER-96) Create library that is able to consume published index without all the fuss of existing indexer

2015-10-30 Thread Cservenak, Tamas (JIRA)
Cservenak, Tamas created MINDEXER-96:


 Summary: Create library that is able to consume published index 
without all the fuss of existing indexer
 Key: MINDEXER-96
 URL: https://issues.apache.org/jira/browse/MINDEXER-96
 Project: Maven Indexer
  Issue Type: New Feature
Reporter: Cservenak, Tamas
 Fix For: 5.1.2


The idea is to be able to consume the published index without the need of the 
maven-indexer, for example to push the maven indexer published index into some 
other indexing system. The library should be easy to integrate, have low 
footprint, and support incremental updates too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MINDEXER-94) no temp file cleanup in WagonFetcher after an error

2015-10-30 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-94:
-
Fix Version/s: 5.1.2

> no temp file cleanup in WagonFetcher after an error
> ---
>
> Key: MINDEXER-94
> URL: https://issues.apache.org/jira/browse/MINDEXER-94
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
>Reporter: Tomas Stupka
>Priority: Minor
> Fix For: 5.1.2
>
> Attachments: deleteTempFile.diff
>
>
> see o.a.m.index.updater.WagonHelper.WagonFetcher.retrieve(name) in 
> indexer.core 5.1.1
> a temp file is created to store the remote index, but in case that the 
> following retrieve( name, target ) call throws an exception, then no attempt 
> is made to remove this file. 
> The problem typically happens in cases when there is no remote index file 
> available and also that the temp folder might become polluted after a while - 
> e.g in a scenario like we have encountered in NetBeans - see also 
> https://netbeans.org/bugzilla/show_bug.cgi?id=246409
> see also attached fix suggestion ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (MINDEXER-94) no temp file cleanup in WagonFetcher after an error

2015-10-30 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas resolved MINDEXER-94.
--
Resolution: Fixed

https://github.com/apache/maven-indexer/commit/7a0e7ad3d92fc121c2c1e49414d2c1099d945db4

Thanks for the patch!

> no temp file cleanup in WagonFetcher after an error
> ---
>
> Key: MINDEXER-94
> URL: https://issues.apache.org/jira/browse/MINDEXER-94
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
>Reporter: Tomas Stupka
>Priority: Minor
> Fix For: 5.1.2
>
> Attachments: deleteTempFile.diff
>
>
> see o.a.m.index.updater.WagonHelper.WagonFetcher.retrieve(name) in 
> indexer.core 5.1.1
> a temp file is created to store the remote index, but in case that the 
> following retrieve( name, target ) call throws an exception, then no attempt 
> is made to remove this file. 
> The problem typically happens in cases when there is no remote index file 
> available and also that the temp folder might become polluted after a while - 
> e.g in a scenario like we have encountered in NetBeans - see also 
> https://netbeans.org/bugzilla/show_bug.cgi?id=246409
> see also attached fix suggestion ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (MINDEXER-95) suboptimal indexing execution in DefaultIndexUpdater

2015-10-30 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas resolved MINDEXER-95.
--
Resolution: Fixed

> suboptimal indexing execution in DefaultIndexUpdater
> 
>
> Key: MINDEXER-95
> URL: https://issues.apache.org/jira/browse/MINDEXER-95
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
>Reporter: Tomas Stupka
> Fix For: 5.1.2
>
> Attachments: mvn-indexer.diff
>
>
> while profiling the maven.indexer 5.1.1 usage in NetBeans, the following 
> turned out:
> - o.a.m.index.updater.IndexDataReader 
> too slow reading of the gzipped file - can be significantly improved via 
> DataInputStream initialization
> - o.a.m.index.context.NexusAnalyzer   
> too much time spent in LetterOrDigitTokenizer. - can be improved by 
> reusing the CharTokenizer-s
> - not neccessary optimize calls
> .optimize() seems to have a minor effect on query times, but is 
> disproportionally expensive during index creation time. In case you do not 
> want to remove it, please at least consider an option for the client code to 
> disable optimize calls.
> - o.a.m.index.context.NexusIndexWriter
> slight improvements in indexing time where achieved by tweaking the 
> NexusIndexWriter config. In case you do not want to change them, please 
> consider a way for the client code to have more control about the writer 
> configuration.
> for particular cases and fix suggestion in code see also attached diff file 
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MINDEXER-95) suboptimal indexing execution in DefaultIndexUpdater

2015-10-30 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983668#comment-14983668
 ] 

Cservenak, Tamas commented on MINDEXER-95:
--

Partially applied patch:
https://github.com/apache/maven-indexer/commit/c193888287ca04a7e6038dddf596b13124769180

NexusAnalyzer change introduces NPEs in all UTs and as such was rejected (also, 
is wrong as Tokenizer may change depending on field).

NexusIndexWriter now offers a factory for IndexWriterConfig.

Thanks for the patch!

> suboptimal indexing execution in DefaultIndexUpdater
> 
>
> Key: MINDEXER-95
> URL: https://issues.apache.org/jira/browse/MINDEXER-95
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
>Reporter: Tomas Stupka
> Fix For: 5.1.2
>
> Attachments: mvn-indexer.diff
>
>
> while profiling the maven.indexer 5.1.1 usage in NetBeans, the following 
> turned out:
> - o.a.m.index.updater.IndexDataReader 
> too slow reading of the gzipped file - can be significantly improved via 
> DataInputStream initialization
> - o.a.m.index.context.NexusAnalyzer   
> too much time spent in LetterOrDigitTokenizer. - can be improved by 
> reusing the CharTokenizer-s
> - not neccessary optimize calls
> .optimize() seems to have a minor effect on query times, but is 
> disproportionally expensive during index creation time. In case you do not 
> want to remove it, please at least consider an option for the client code to 
> disable optimize calls.
> - o.a.m.index.context.NexusIndexWriter
> slight improvements in indexing time where achieved by tweaking the 
> NexusIndexWriter config. In case you do not want to change them, please 
> consider a way for the client code to have more control about the writer 
> configuration.
> for particular cases and fix suggestion in code see also attached diff file 
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (MINDEXER-95) suboptimal indexing execution in DefaultIndexUpdater

2015-10-30 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas updated MINDEXER-95:
-
Fix Version/s: 5.1.2

> suboptimal indexing execution in DefaultIndexUpdater
> 
>
> Key: MINDEXER-95
> URL: https://issues.apache.org/jira/browse/MINDEXER-95
> Project: Maven Indexer
>  Issue Type: Bug
>Affects Versions: 5.1.1
>Reporter: Tomas Stupka
> Fix For: 5.1.2
>
> Attachments: mvn-indexer.diff
>
>
> while profiling the maven.indexer 5.1.1 usage in NetBeans, the following 
> turned out:
> - o.a.m.index.updater.IndexDataReader 
> too slow reading of the gzipped file - can be significantly improved via 
> DataInputStream initialization
> - o.a.m.index.context.NexusAnalyzer   
> too much time spent in LetterOrDigitTokenizer. - can be improved by 
> reusing the CharTokenizer-s
> - not neccessary optimize calls
> .optimize() seems to have a minor effect on query times, but is 
> disproportionally expensive during index creation time. In case you do not 
> want to remove it, please at least consider an option for the client code to 
> disable optimize calls.
> - o.a.m.index.context.NexusIndexWriter
> slight improvements in indexing time where achieved by tweaking the 
> NexusIndexWriter config. In case you do not want to change them, please 
> consider a way for the client code to have more control about the writer 
> configuration.
> for particular cases and fix suggestion in code see also attached diff file 
> ...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (MINDEXER-96) Create library that is able to consume published index without all the fuss of existing indexer

2015-10-30 Thread Cservenak, Tamas (JIRA)

[ 
https://issues.apache.org/jira/browse/MINDEXER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14983687#comment-14983687
 ] 

Cservenak, Tamas commented on MINDEXER-96:
--

Done in 
https://github.com/apache/maven-indexer/commit/af8783d8fc8dcab6ef6d9a17d04858fd725037a0

> Create library that is able to consume published index without all the fuss 
> of existing indexer
> ---
>
> Key: MINDEXER-96
> URL: https://issues.apache.org/jira/browse/MINDEXER-96
> Project: Maven Indexer
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
> Fix For: 5.1.2
>
>
> The idea is to be able to consume the published index without the need of the 
> maven-indexer, for example to push the maven indexer published index into 
> some other indexing system. The library should be easy to integrate, have low 
> footprint, and support incremental updates too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (MINDEXER-96) Create library that is able to consume published index without all the fuss of existing indexer

2015-10-30 Thread Cservenak, Tamas (JIRA)

 [ 
https://issues.apache.org/jira/browse/MINDEXER-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cservenak, Tamas resolved MINDEXER-96.
--
Resolution: Fixed

> Create library that is able to consume published index without all the fuss 
> of existing indexer
> ---
>
> Key: MINDEXER-96
> URL: https://issues.apache.org/jira/browse/MINDEXER-96
> Project: Maven Indexer
>  Issue Type: New Feature
>Reporter: Cservenak, Tamas
> Fix For: 5.1.2
>
>
> The idea is to be able to consume the published index without the need of the 
> maven-indexer, for example to push the maven indexer published index into 
> some other indexing system. The library should be easy to integrate, have low 
> footprint, and support incremental updates too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)