[jira] [Updated] (MINDEXER-232) There should be constants for the different index creator types and these should be documented somewhere
[ https://issues.apache.org/jira/browse/MINDEXER-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-232: Description: h1. Description There don't appear to be any constants for the possible index creator types. They also don't appear to be documented. This makes it harder to understand what index creator types exist and how they can be used. h1. Task List * (off) Define constants for the different index creator types. * (off) Refactor the code so that it uses these constants. * (off) Add documentation that outlines what these index creators types are used for. ** (off) Clarify what the default indexers are. ** (off) Clarify what indexers are used to create the indexes for Maven Central. was: h1. Description There don't appear to be any constants for the possible index creator types. They also don't appear to be documented. This makes it harder to understand what index creator types exist and how they can be used. h1. Task List * (off) Define constants for the different index creator types. * (off) Refactor the code so that it uses these constants. * (off) Add documentation that outlines what these index creators types are used for. ** (off) Clarify what the default indexers are. ** (off) Clarify what indexers are used to create the indexes for Maven Central. > There should be constants for the different index creator types and these > should be documented somewhere > > > Key: MINDEXER-232 > URL: https://issues.apache.org/jira/browse/MINDEXER-232 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov >Priority: Major > > h1. Description > There don't appear to be any constants for the possible index creator types. > They also don't appear to be documented. This makes it harder to understand > what index creator types exist and how they can be used. > h1. Task List > * (off) Define constants for the different index creator types. > * (off) Refactor the code so that it uses these constants. > * (off) Add documentation that outlines what these index creators types are > used for. > ** (off) Clarify what the default indexers are. > ** (off) Clarify what indexers are used to create the indexes for Maven > Central. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-232) There should be constants for the different index creator types and these should be documented somewhere
Martin Todorov created MINDEXER-232: --- Summary: There should be constants for the different index creator types and these should be documented somewhere Key: MINDEXER-232 URL: https://issues.apache.org/jira/browse/MINDEXER-232 Project: Maven Indexer Issue Type: Task Reporter: Martin Todorov h1. Description There don't appear to be any constants for the possible index creator types. They also don't appear to be documented. This makes it harder to understand what index creator types exist and how they can be used. h1. Task List * (off) Define constants for the different index creator types. * (off) Refactor the code so that it uses these constants. * (off) Add documentation that outlines what these index creators types are used for. ** (off) Clarify what the default indexers are. ** (off) Clarify what indexers are used to create the indexes for Maven Central. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINDEXER-231) The sha256 and bundle license fields appear to be empty for all artifacts in the maven index from Maven Central indexes
Martin Todorov created MINDEXER-231: --- Summary: The sha256 and bundle license fields appear to be empty for all artifacts in the maven index from Maven Central indexes Key: MINDEXER-231 URL: https://issues.apache.org/jira/browse/MINDEXER-231 Project: Maven Indexer Issue Type: Task Reporter: Martin Todorov The sha256 and bundle license fields appear to be empty for all artifacts in the maven index from Maven Central indexes. Is this on purpose, is the data not being parsed/stored correctly, or is Maven Central just choosing not to divulge this information? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINDEXER-142) Add proper documentation with real life examples
[
https://issues.apache.org/jira/browse/MINDEXER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491925#comment-17491925
]
Martin Todorov commented on MINDEXER-142:
-
Okay, that sounds great! I just hope this task doesn't get ignored, or
downgraded as priority. In my opinion, it's quite important and should be
handled by someone who really knows the intricacies and peculiarities of how
all this works, which means it should be one of the core developers.
Thanks! :)
> Add proper documentation with real life examples
>
>
> Key: MINDEXER-142
> URL: https://issues.apache.org/jira/browse/MINDEXER-142
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Priority: Major
>
> *Task Description*
> It would be great to have some proper documentation and not a few cryptic
> lines and some Javadocs.
> The current official documentation is published
> [here|https://maven.apache.org/maven-indexer/] and it contains very little
> useful information. Someone who first encounters the project will need to do
> a lot of digging around in order to extract the useful information they need
> (mostly by poking around the test code, running through a debugger and hoping
> to find what they are looking for).
> This project has few and very rare contributions (sometimes as bursts of pull
> requests which take forever to be reviewed and merged), mainly because people
> feel intimidated to try and make improvements on it, hence the very slow pace
> of development and low activity.
> In my opinion, if it gets some better documentation and, if it's a
> requirement to continuously improve the documentation (could be done as a
> check list item in a github issue/pull request template), the project will
> have a better development pace, as more people will be able to understand it
> well enough to make actual changes.
> [~cstamas]: Would this be something you could look into as part of the
> upcoming {{6.1.0}} release?
> *Task List*
> Some ideas of things to cover:
> * (off) Define key concepts.
> * (off) Explain how the indexer works.
> * (off) Describe how the index downloading/updating works and what the
> acceptable frequencies of downloading are.
> * (off) Add code examples (and expand on this with actual explanations).
> * (off) Add links to the example code, as the current documentation doesn't
> mention that there is such.
> * (off) Cover any other important topics that come to mind and might be
> useful.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (MINDEXER-142) Add proper documentation with real life examples
[
https://issues.apache.org/jira/browse/MINDEXER-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINDEXER-142:
Description:
*Task Description*
It would be great to have some proper documentation and not a few cryptic lines
and some Javadocs.
The current official documentation is published
[here|https://maven.apache.org/maven-indexer/] and it contains very little
useful information. Someone who first encounters the project will need to do a
lot of digging around in order to extract the useful information they need
(mostly by poking around the test code, running through a debugger and hoping
to find what they are looking for).
This project has few and very rare contributions (sometimes as bursts of pull
requests which take forever to be reviewed and merged), mainly because people
feel intimidated to try and make improvements on it, hence the very slow pace
of development and low activity.
In my opinion, if it gets some better documentation and, if it's a requirement
to continuously improve the documentation (could be done as a check list item
in a github issue/pull request template), the project will have a better
development pace, as more people will be able to understand it well enough to
make actual changes.
[~cstamas]: Would this be something you could look into as part of the upcoming
{{6.1.0}} release?
*Task List*
Some ideas of things to cover:
* (off) Define key concepts.
* (off) Explain how the indexer works.
* (off) Describe how the index downloading/updating works and what the
acceptable frequencies of downloading are.
* (off) Add code examples (and expand on this with actual explanations).
* (off) Add links to the example code, as the current documentation doesn't
mention that there is such.
* (off) Cover any other important topics that come to mind and might be useful.
was:
# Task Description
It would be great to have some proper documentation and not a few cryptic lines
and some Javadocs.
The current official documentation is published
[here|https://maven.apache.org/maven-indexer/] and it contains very little
useful information. Someone who first encounters the project will need to do a
lot of digging around in order to extract the useful information they need
(mostly by poking around the test code, running through a debugger and hoping
to find what they are looking for).
This project has few and very rare contributions (sometimes as bursts of pull
requests which take forever to be reviewed and merged), mainly because people
feel intimidated to try and make improvements on it, hence the very slow pace
of development and low activity.
In my opinion, if it gets some better documentation and, if it's a requirement
to continuously improve the documentation (could be done as a check list item
in a github issue/pull request template), the project will have a better
development pace, as more people will be able to understand it well enough to
make actual changes.
[~cstamas]: Would this be something you could look into as part of the upcoming
{{6.1.0}} release?
# Task List
Some ideas of things to cover:
* (off) Define key concepts.
* (off) Explain how the indexer works.
* (off) Describe how the index downloading/updating works and what the
acceptable frequencies of downloading are.
* (off) Add code examples (and expand on this with actual explanations).
* (off) Add links to the example code, as the current documentation doesn't
mention that there is such.
* (off) Cover any other important topics that come to mind and might be useful.
> Add proper documentation with real life examples
>
>
> Key: MINDEXER-142
> URL: https://issues.apache.org/jira/browse/MINDEXER-142
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Priority: Major
>
> *Task Description*
> It would be great to have some proper documentation and not a few cryptic
> lines and some Javadocs.
> The current official documentation is published
> [here|https://maven.apache.org/maven-indexer/] and it contains very little
> useful information. Someone who first encounters the project will need to do
> a lot of digging around in order to extract the useful information they need
> (mostly by poking around the test code, running through a debugger and hoping
> to find what they are looking for).
> This project has few and very rare contributions (sometimes as bursts of pull
> requests which take forever to be reviewed and merged), mainly because people
> feel intimidated to try and make improvements on it, hence the very slow pace
> of development and low activity.
> In my opinion, if it gets some better documentation and, if it's a
> requirement to continuously improve the documentation (could be done as a
> check list item in a github issue/pull
[jira] [Created] (MINDEXER-142) Add proper documentation with real life examples
Martin Todorov created MINDEXER-142:
---
Summary: Add proper documentation with real life examples
Key: MINDEXER-142
URL: https://issues.apache.org/jira/browse/MINDEXER-142
Project: Maven Indexer
Issue Type: Task
Reporter: Martin Todorov
# Task Description
It would be great to have some proper documentation and not a few cryptic lines
and some Javadocs.
The current official documentation is published
[here|https://maven.apache.org/maven-indexer/] and it contains very little
useful information. Someone who first encounters the project will need to do a
lot of digging around in order to extract the useful information they need
(mostly by poking around the test code, running through a debugger and hoping
to find what they are looking for).
This project has few and very rare contributions (sometimes as bursts of pull
requests which take forever to be reviewed and merged), mainly because people
feel intimidated to try and make improvements on it, hence the very slow pace
of development and low activity.
In my opinion, if it gets some better documentation and, if it's a requirement
to continuously improve the documentation (could be done as a check list item
in a github issue/pull request template), the project will have a better
development pace, as more people will be able to understand it well enough to
make actual changes.
[~cstamas]: Would this be something you could look into as part of the upcoming
{{6.1.0}} release?
# Task List
Some ideas of things to cover:
* (off) Define key concepts.
* (off) Explain how the indexer works.
* (off) Describe how the index downloading/updating works and what the
acceptable frequencies of downloading are.
* (off) Add code examples (and expand on this with actual explanations).
* (off) Add links to the example code, as the current documentation doesn't
mention that there is such.
* (off) Cover any other important topics that come to mind and might be useful.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (MINDEXER-136) Set up Github Actions
[
https://issues.apache.org/jira/browse/MINDEXER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17486363#comment-17486363
]
Martin Todorov commented on MINDEXER-136:
-
Ah, it looks like someone already set this up (since I last checked a while
ago). This can be closed.
> Set up Github Actions
> -
>
> Key: MINDEXER-136
> URL: https://issues.apache.org/jira/browse/MINDEXER-136
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Priority: Major
>
> It would be quite helpful, if we could use Github Actions to check if the
> {{maven-indexer}} builds properly under different OS (sometimes it's quirkly
> under Windows), as well as different versions of the JDK.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (MINDEXER-136) Set up Github Actions
Martin Todorov created MINDEXER-136:
---
Summary: Set up Github Actions
Key: MINDEXER-136
URL: https://issues.apache.org/jira/browse/MINDEXER-136
Project: Maven Indexer
Issue Type: Task
Reporter: Martin Todorov
It would be quite helpful, if we could use Github Actions to check if the
{{maven-indexer}} builds properly under different OS (sometimes it's quirkly
under Windows), as well as different versions of the JDK.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212371#comment-17212371
]
Martin Todorov edited comment on MNG-6604 at 10/13/20, 8:49 AM:
The second link to MRESOLVER-131 is broken.
was (Author: carlspring):
The second link )to MRESOLVER=131) is broken.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17212371#comment-17212371
]
Martin Todorov commented on MNG-6604:
-
The second link )to MRESOLVER=131) is broken.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0
>
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MRESOURCES-132) Copying of files with permissions broken
[
https://issues.apache.org/jira/browse/MRESOURCES-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160739#comment-17160739
]
Martin Todorov commented on MRESOURCES-132:
---
[~khmarbaise], [~olamy],
Could you please re-open this issue?
> Copying of files with permissions broken
>
>
> Key: MRESOURCES-132
> URL: https://issues.apache.org/jira/browse/MRESOURCES-132
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: copy
>Affects Versions: 2.4.3
> Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 22:16:01+0300)
> Java version: 1.6.0_19
> Java home: /java/jdk1.6.0_19/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux" version: "2.6.28.5" arch: "i386" Family: "unix"
>Reporter: Martin Todorov
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> Files with permissions are not copied with the permissions as illustrated
> below:
> {noformat}
> root@carlspring:/java/opensource/build-force/zipper-plugin# ls -al `find .
> -name *perm*`
> -rwxr--r-- 1 root root 8 2010-12-09 20:48
> ./src/test/resources/zip/file.with.permission.sh*
> -rw-r--r-- 1 root root 8 2010-12-09 22:56
> ./target/test-classes/zip/file.with.permission.sh
> {noformat}
> Notice the 'x' permission missing from the copied file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878856#comment-16878856
]
Martin Todorov commented on MNG-6604:
-
In this day and age saying the such a widely used tool for building code like
Maven will not support multiple VM access will be madness. I'm not a core Maven
developer, but I've been using it and developing plugins and tooling around it
since it first popped up many years ago. CI build farms need this to be
properly implemented.
I think that we need to focus on implementing a proper locking mechanism that
works for multiple JVM-s.
I get your point about the complexity of fine-tuning this. I don't think one
should worry about large files, as much as tracking inactivity on files (a JVM
may have terminated and left a file behind and then lock things for other
JVM-s; if this has happened an easy way to check it would be to simply see when
the last file write activity happened and see, if the {{maxInactivity}} time
has been exceeded).
What are the classes of importance, if somebody would like to dig into this?
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16878844#comment-16878844
]
Martin Todorov commented on MNG-6604:
-
Could this perhaps be solved by using one of these two options:
* Have a daemon for Maven that controls downloads. When an artifact needs to be
resolved from a different instance of Maven running in a different JVM, it
would connect to the daemon and see, if there already is a download for this in
progress and wait for it.
* Have a temporary directory to which the artifacts are written, instead of
local repository. When an artifact needs to be resolved from a different
instance of Maven running in a different JVM, check the temporary directory for
the artifact and check, if the size is growing every X milliseconds and wait.
If there has been 15 seconds of inactivity. then the download is assumed dead
and the querying instance of Maven, can feel free to restart the download.
{{LockableFileWriter}} is possibly another alternative.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16816267#comment-16816267
]
Martin Todorov commented on MNG-6604:
-
Many thanks for your help, [~michael-o] and [~igorf]!
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814853#comment-16814853
]
Martin Todorov commented on MNG-6604:
-
[~igorf],
Thanks for confirming that the {{takari-local-repository}} is broken (as we
thought) and that it's not us misconfiguring something! :)
We tried using {{-Daether.connector.resumeDownload=false}}, but this,
unfortunately, did not help.
[~michael-o],
What sort of information would help you guys further investigate this?
Do you guys have anything else you could advise that we try?
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813903#comment-16813903
]
Martin Todorov commented on MNG-6604:
-
[~jvanzyl], [~igorf],
As authors of the {{takari-local-repository}}, would you mind sharing your
thoughts, or giving some hints on how we could overcome this? We have 24-core
machines and we would like to use them to their maximum potential. We have a
lot of parallelized tests as well using JUnit 5.
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812839#comment-16812839
]
Martin Todorov edited comment on MNG-6604 at 4/8/19 10:01 PM:
--
[~michael-o],
We're really not happy about having to drop the {{-T2C}} option, as it will
significantly increase our build times.
Would it be possible to include a fix for this in the upcoming {{3.6.1}}, or
could you please postpone it until this has been resolved? In essence, this
means that the parallel builds don't actually really work. Well, at least not
when you need to use them in a CI server.
What further details would you need in order to investigate and fix this?
was (Author: carlspring):
We're really not happy about having to drop the {{-T2C}} option, as it will
significantly increase our build times.
Would it be possible to include a fix for this in the upcoming {{3.6.1}}, or
could you please postpone it until this has been resolved? In essence, this
means that the parallel builds don't actually really work. Well, at least not
when you need to use them in a CI server.
What further details would you need in order to investigate and fix this?
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6604) Intermittent failures while downloading GAVs from Nexus
[
https://issues.apache.org/jira/browse/MNG-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812839#comment-16812839
]
Martin Todorov commented on MNG-6604:
-
We're really not happy about having to drop the {{-T2C}} option, as it will
significantly increase our build times.
Would it be possible to include a fix for this in the upcoming {{3.6.1}}, or
could you please postpone it until this has been resolved? In essence, this
means that the parallel builds don't actually really work. Well, at least not
when you need to use them in a CI server.
What further details would you need in order to investigate and fix this?
> Intermittent failures while downloading GAVs from Nexus
> ---
>
> Key: MNG-6604
> URL: https://issues.apache.org/jira/browse/MNG-6604
> Project: Maven
> Issue Type: Bug
> Components: Command Line, Toolchains
>Affects Versions: 3.6.0
> Environment: Nexus OSS 3.15.2-01
> Docker 18.09.2 on Ubuntu 18.04.2 LTS
> Gitlab runner 11.8.0
>Reporter: Ivan Rizzante
>Priority: Major
> Attachments: docker-env.txt, log.txt
>
>
> Hello
> we're running maven 3.6.0 builds in a docker container and we use Nexus OSS
> configured as proxy for Maven Central.
> While running our builds using Gitlab CI, we're experiencing intermittent
> build failures because Maven cannot find artifacts in Nexus which we verified
> they are actually available.
> Error example below:
> {noformat}
> 20744 [main] [ERROR] Failed to execute goal on project EcotransitWSClient:
> Could not resolve dependencies for project
> it.sdb.ecotransit:EcotransitWSClient:jar:7.0.1-SNAPSHOT: Could not transfer
> artifact commons-beanutils:commons-beanutils:jar:1.9.3 from/to nexus
> (http://maven-repo.sdb.it:8081/repository/maven-public/):
> /builds/sdb/webportal/.m2/repository/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.jar.part
> (No such file or directory) -> [Help 1]
> {noformat}
> I attached the full maven build log and our Docker env settings.
> We tried disabling the keep alive and also disabling the connection pooling
> but nothing seems to fix the issue.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://issues.apache.org/jira/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406710#comment-16406710
]
Martin Todorov commented on MINDEXER-49:
[~paleozogt],
My understanding is that the {{maven-metadata.xml}} files are not used during
the indexing. Also, based on your reasoning, if you have artifact files on the
file system and these are (for some reason) not defined in the
{{maven-metadata.xml}}, then the artifacts will not be indexed. Theoretically,
this can be done the way you're proposing, but it will slow down the
re-indexing significantly when used at a much larger scale than just a few
files.
> 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
(v7.6.3#76005)
[jira] [Comment Edited] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://issues.apache.org/jira/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406583#comment-16406583
]
Martin Todorov edited comment on MINDEXER-49 at 3/20/18 4:21 PM:
-
[~paleozogt],
The problem is more due to the the following:
* One POM file can define one artifact. (Sure, you can use the
build-helper-maven-plugin to add additional ones, but they are never reflected
in the uploaded POM file).
* You can't always guess the extension properly. You can guess simple
extensions like jar, war, zip, but will fail with parsing the extensions for
tar.gz, tar.bz2 and so on, unless you have an exact list of all possible
extensions...
So, if you were to scan a directory that contains such artifacts, how would you
locate the artifacts?
How would you figure out what the extension is?
How would you know where the classifier ends when you have a complex extension
like the above? You will end up getting classifiers like gcc4.4.5.tar. Clearly,
this is not what you'd want.
If you have suggestions and advice, do share!
was (Author: carlspring):
[~paleozogt],
The problem is more along due to the following:
* One POM file can define one artifact. (Sure, you can use the
build-helper-maven-plugin to add additional ones, but they are never reflected
in the uploaded POM file).
* You can't always guess the extension properly. You can guess simple
extensions like jar, war, zip, but will fail with parsing the extensions for
tar.gz, tar.bz2 and so on, unless you have an exact list of all possible
extensions...
So, if you were to scan a directory that contains such artifacts, how would you
locate the artifacts?
How would you figure out what the extension is?
How would you know where the classifier ends when you have a complex extension
like the above? You will end up getting classifiers like gcc4.4.5.tar. Clearly,
this is not what you'd want.
If you have suggestions and advice, do share!
> 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
(v7.6.3#76005)
[jira] [Commented] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://issues.apache.org/jira/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406583#comment-16406583
]
Martin Todorov commented on MINDEXER-49:
[~paleozogt],
The problem is more along due to the following:
* One POM file can define one artifact. (Sure, you can use the
build-helper-maven-plugin to add additional ones, but they are never reflected
in the uploaded POM file).
* You can't always guess the extension properly. You can guess simple
extensions like jar, war, zip, but will fail with parsing the extensions for
tar.gz, tar.bz2 and so on, unless you have an exact list of all possible
extensions...
So, if you were to scan a directory that contains such artifacts, how would you
locate the artifacts?
How would you figure out what the extension is?
How would you know where the classifier ends when you have a complex extension
like the above? You will end up getting classifiers like gcc4.4.5.tar. Clearly,
this is not what you'd want.
If you have suggestions and advice, do share!
> 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
(v7.6.3#76005)
[jira] [Commented] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://issues.apache.org/jira/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16406227#comment-16406227
]
Martin Todorov commented on MINDEXER-49:
[~paleozogt],
Yeah, I understand your use case, but this opens up a different set of
problems. For example, given the following paths:
com/foo/bar/1.2/bar-1.2-gcc4.4.5.tar.gz
com/foo/bar/1.2-SNAPSHOT/bar-1.2-20180320.115830-5-gcc4.4.5.tar.gz
com/foo/bar/1.2-SNAPSHOT/bar-1.2-20180320.115830-5-gcc4.4.5.zip
When you have to parse the strings above, how will you know what is an
extension and what is a classifier...? (For the sake of both simplicity,
efficiency and speed, don't assume you can parse the .pom file).
If you could describe how this would work given the clarifications above, then
sure, somebody could probably implement it. At the moment, there is no clear
understanding of how to do this, (or so I'd say).
> 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
(v7.6.3#76005)
[jira] [Created] (MASSEMBLY-830) Cannot handle relocated artifacts
Martin Todorov created MASSEMBLY-830:
Summary: Cannot handle relocated artifacts
Key: MASSEMBLY-830
URL: https://issues.apache.org/jira/browse/MASSEMBLY-830
Project: Maven Assembly Plugin
Issue Type: Bug
Components: dependencySet
Affects Versions: 2.6
Environment: $ mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: C:\java\apache\maven-3.3.9
Java version: 1.8.0_92, vendor: Oracle Corporation
Java home: C:\java\jdk1.8.0_92\jre
Default locale: en_GB, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
Reporter: Martin Todorov
Priority: Blocker
When one of the transitive dependencies is relocated, the
{{maven-assembly-plugin}} doesn't follow the relocation and check the POM of
the relocated artifact, but uses the actual POM artifact that declares the
relocation. Since this POM doesn't define a version for the artifact, the build
fails with:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single (make-assembly) on
project blah: Execution make-assembly of goal
org.apache.maven.plugins:maven-assembly-plugin:2.6:single failed: For artifact
{com.foo:bar:null:jar}: The version cannot be empty. -> [Help 1]
{code}
As this is a transitive dependency of a third-party library, we have no control
over it and have attempted to define:
* An {{}} for this artifact in the dependency which requires it.
* A direct dependency (as the very first {{}}) to the relocated
artifact (which has a version defined in the {{pom.xml}}).
Unfortunately, neither of these helped.
This is the POM with the relocation:
{code}
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd " xmlns="
http://maven.apache.org/POM/4.0.0 "
xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance";>
4.0.0
com.foo
bar
b
1.5
{code}
Please, advise!
Many thanks in advance!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315932#comment-15315932
]
Martin Todorov commented on MINVOKER-182:
-
...Right... It only now, when re-reading this, that I realized this is being
caused by a transitive dependency of a dependency we recently introduced.
Thanks for the hint!
> Different groovy versions on test classpath can cause ClassCastException
>
>
> Key: MINVOKER-182
> URL: https://issues.apache.org/jira/browse/MINVOKER-182
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Andrew Schurman
>Priority: Minor
>
> When {{addTestClassPath}} is set and you have a different version of groovy
> than invoker on your classpath, you will run into {{ClassCastException}} when
> pre-/post- build hooks are run for tests. This occurs due to invoker creating
> groovy scripts in its version of groovy, but using a different version of
> groovy as the runtime (since test classpath elements are loaded first when
> {{addTestClassPath=true}}).
> In my specific case, I had a transitive dependency on groovy 1.7, but invoker
> uses groovy 2.0. Being transitive does make it harder to spot, but
> more importantly you may not have access to the dependency that depends on
> groovy. This could make swapping groovy versions impossible depending on the
> gap between versions.
> Stack trace:
> {code}
> groovy.lang.GroovyRuntimeException: Failed to create Script instance for
> class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot be
> cast to groovy.lang.GroovyObject
> at
> org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:443)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:625)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:516)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:556)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:527)
> at
> org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:249)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:177)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1692)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1360)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1210)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:723)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: Script1 cannot be cast to
> groovy.lang.GroovyObject
>
[jira] [Comment Edited] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315921#comment-15315921
]
Martin Todorov edited comment on MINVOKER-182 at 6/5/16 4:03 PM:
-
I am getting this as well with:
{code}
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /java/apache/maven-3.3.9
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /java/jdk1.8.0_65/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.5.0-6-default", arch: "amd64", family: "unix"
{code}
The exception:
{code}
Running post-build script:
/java/jenkins/jobs/project1/jobs/project1-web-integration-tests/workspace/target/it/deploy-and-delete/verify.groovy
groovy.lang.GroovyRuntimeException: Failed to create Script instance for class:
class Script1. Reason: java.lang.ClassCastException: Script1 cannot be cast to
groovy.lang.GroovyObject
at
org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:447)
at groovy.lang.GroovyShell.parse(GroovyShell.java:686)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:568)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:608)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:579)
at
org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:249)
at
org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:177)
at
org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1746)
at
org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1415)
at
org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1262)
at
org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:737)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
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)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at
org.jvnet.hudson.maven3.launcher.Maven32Launcher.main(Maven32Launcher.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:330)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:238)
at jenkins.maven3.agent.Maven32Main.launch(Maven32Main.java:186)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:136)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:71)
at hudson.remoting.UserRequest.perform(UserRequest.java:152)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:332)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassCastException: Script1 cannot be cast to
[jira] [Commented] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315926#comment-15315926
]
Martin Todorov commented on MINVOKER-182:
-
[~barrie], [~rfscholte],
Perhaps you have some ideas?
> Different groovy versions on test classpath can cause ClassCastException
>
>
> Key: MINVOKER-182
> URL: https://issues.apache.org/jira/browse/MINVOKER-182
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Andrew Schurman
>Priority: Minor
>
> When {{addTestClassPath}} is set and you have a different version of groovy
> than invoker on your classpath, you will run into {{ClassCastException}} when
> pre-/post- build hooks are run for tests. This occurs due to invoker creating
> groovy scripts in its version of groovy, but using a different version of
> groovy as the runtime (since test classpath elements are loaded first when
> {{addTestClassPath=true}}).
> In my specific case, I had a transitive dependency on groovy 1.7, but invoker
> uses groovy 2.0. Being transitive does make it harder to spot, but
> more importantly you may not have access to the dependency that depends on
> groovy. This could make swapping groovy versions impossible depending on the
> gap between versions.
> Stack trace:
> {code}
> groovy.lang.GroovyRuntimeException: Failed to create Script instance for
> class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot be
> cast to groovy.lang.GroovyObject
> at
> org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:443)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:625)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:516)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:556)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:527)
> at
> org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:249)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:177)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1692)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1360)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1210)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:723)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.ClassCastException: Script1 cannot be cast to
> groovy.lang.GroovyObject
> at
> org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:421)
> ... 32 more
> {
[jira] [Comment Edited] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315921#comment-15315921
]
Martin Todorov edited comment on MINVOKER-182 at 6/5/16 3:48 PM:
-
I am getting this as well with:
{code}
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /java/apache/maven-3.3.9
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /java/jdk1.8.0_65/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.5.0-6-default", arch: "amd64", family: "unix"
{code}
Plugin configuration:
{code}
org.apache.maven.plugins
maven-invoker-plugin
2.0.0
true
clean
verify
src/it/settings.xml
${project.build.directory}/it
true
invoker-integration-tests
run
test
org.codehaus.groovy
groovy-all
2.4.6
{code}
I also have:
{code}
org.codehaus.groovy
groovy-all
2.4.6
test
{code}
And that doesn't seem to help.
Is there a way around this? I mean, this was all working fine for our project
till a few days ago. There have been no changes to the said project in a long
while and the code was running these integration tests just fine for a long
time (we're using the {{maven-invoker-plugin}} to simulate Maven behavior
against another project, so our CI was set up to invoke these test when there
were changes to the other project).
I've also posted this on Stackoverflow, as I wasn't initially sure whether it
was a bug, or not:
-
http://stackoverflow.com/questions/37642843/weird-maven-invoker-plugin-exception-java-lang-classcastexception-script1-cann
>From the discussion in this bug report and [this
>discussion|http://maven.40175.n5.nabble.com/Maven-invoker-plugin-addTestClassPath-failing-but-manually-adding-as-dependency-works-td5843422.html],
> I am under the impression that other people have been able to find a
>workaround, but adding the {{groovy-all}} dependency doesn't seem to be making
>a difference in my case at all.
Please advise!
was (Author: carlspring):
I am getting this as well with:
{code}
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /java/apache/maven-3.3.9
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /java/jdk1.8.0_65/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.5.0-6-default", arch: "amd64", family: "unix"
{code}
Plugin configuration:
{code}
org.apache.maven.plugins
maven-invoker-plugin
2.0.0
true
clean
verify
src/it/settings.xml
${project.build.directory}/it
true
invoker-integration-tests
run
test
org.codehaus.groovy
groovy-all
2.4.6
{code}
I also have:
{code}
org.codehaus.groovy
groovy-all
2.4.6
test
{code}
And that doesn't seem to help.
Is there a way around this? I mean, this was all working fine for our project
till a few days ago. There have been no changes to the said project in a long
while and the code was running these integration tests just fine for a long
time (we're using the {{maven-invoker-plugin}} to simulate Maven behavior
against another project, so our CI was set up to invoke these test when th
[jira] [Commented] (MINVOKER-182) Different groovy versions on test classpath can cause ClassCastException
[
https://issues.apache.org/jira/browse/MINVOKER-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15315921#comment-15315921
]
Martin Todorov commented on MINVOKER-182:
-
I am getting this as well with:
{code}
mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T16:41:47+00:00)
Maven home: /java/apache/maven-3.3.9
Java version: 1.8.0_65, vendor: Oracle Corporation
Java home: /java/jdk1.8.0_65/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.5.0-6-default", arch: "amd64", family: "unix"
{code}
Plugin configuration:
{code}
org.apache.maven.plugins
maven-invoker-plugin
2.0.0
true
clean
verify
src/it/settings.xml
${project.build.directory}/it
true
invoker-integration-tests
run
test
org.codehaus.groovy
groovy-all
2.4.6
{code}
I also have:
{code}
org.codehaus.groovy
groovy-all
2.4.6
test
{code}
And that doesn't seem to help.
Is there a way around this? I mean, this was all working fine for our project
till a few days ago. There have been no changes to the said project in a long
while and the code was running these integration tests just fine for a long
time (we're using the {{maven-invoker-plugin}} to simulate Maven behavior
against another project, so our CI was set up to invoke these test when there
were changes to the other project).
> Different groovy versions on test classpath can cause ClassCastException
>
>
> Key: MINVOKER-182
> URL: https://issues.apache.org/jira/browse/MINVOKER-182
> Project: Maven Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.8
>Reporter: Andrew Schurman
>Priority: Minor
>
> When {{addTestClassPath}} is set and you have a different version of groovy
> than invoker on your classpath, you will run into {{ClassCastException}} when
> pre-/post- build hooks are run for tests. This occurs due to invoker creating
> groovy scripts in its version of groovy, but using a different version of
> groovy as the runtime (since test classpath elements are loaded first when
> {{addTestClassPath=true}}).
> In my specific case, I had a transitive dependency on groovy 1.7, but invoker
> uses groovy 2.0. Being transitive does make it harder to spot, but
> more importantly you may not have access to the dependency that depends on
> groovy. This could make swapping groovy versions impossible depending on the
> gap between versions.
> Stack trace:
> {code}
> groovy.lang.GroovyRuntimeException: Failed to create Script instance for
> class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot be
> cast to groovy.lang.GroovyObject
> at
> org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:443)
> at groovy.lang.GroovyShell.parse(GroovyShell.java:625)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:516)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:556)
> at groovy.lang.GroovyShell.evaluate(GroovyShell.java:527)
> at
> org.apache.maven.shared.scriptinterpreter.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.executeRun(ScriptRunner.java:249)
> at
> org.apache.maven.shared.scriptinterpreter.ScriptRunner.run(ScriptRunner.java:177)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1692)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1360)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:1210)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:723)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.M
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[
https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733885#comment-14733885
]
Martin Todorov commented on MRELEASE-649:
-
As I haven't seen a fix for this, I assume it is still not working.
The very simplest way to test it would be to either define a {{}} in a
{{}} (or not even necessarily inside one). Set it's version
to a SNAPSHOT.
I believe the same was valid for SNAPSHOT dependencies of plugins as well.
> release:prepare - ignores SNAPSHOT version in pluginManagement section
> --
>
> Key: MRELEASE-649
> URL: https://issues.apache.org/jira/browse/MRELEASE-649
> Project: Maven Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1
>Reporter: Marcus Linke
>
> When release prepare a project with a pom.xml that defines a SNAPSHOT version
> in its section, the plugin should detect that and ask the
> user for the release version as is does it for dependencies versions already.
> This is especially needed if the project to be released is of package type
> 'pom' and acts as a parent pom for other projects. Otherwise this raises an
> error later when try to release one of these child projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733835#comment-14733835 ] Martin Todorov commented on MRELEASE-649: - I don't have the permissions to do so, but I still believe this is a valid request that needs to be addressed. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRELEASE-649) release:prepare - ignores SNAPSHOT version in pluginManagement section
[ https://issues.apache.org/jira/browse/MRELEASE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14733782#comment-14733782 ] Martin Todorov commented on MRELEASE-649: - [~michael-o], Was this ever fixed? This is a serious issue. > release:prepare - ignores SNAPSHOT version in pluginManagement section > -- > > Key: MRELEASE-649 > URL: https://issues.apache.org/jira/browse/MRELEASE-649 > Project: Maven Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.1 >Reporter: Marcus Linke > > When release prepare a project with a pom.xml that defines a SNAPSHOT version > in its section, the plugin should detect that and ask the > user for the release version as is does it for dependencies versions already. > This is especially needed if the project to be released is of package type > 'pom' and acts as a parent pom for other projects. Otherwise this raises an > error later when try to release one of these child projects. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MRELEASE-572) release:prepare does not check for existing tag and updates the tag in a wrong way
[ https://jira.codehaus.org/browse/MRELEASE-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358064#comment-358064 ] Martin Todorov commented on MRELEASE-572: - I don't think this task should be closed. @Jens Beyer: Could you check if the issue can still be reproduced? If it still re-occurs, let's re-open this task. > release:prepare does not check for existing tag and updates the tag in a > wrong way > -- > > Key: MRELEASE-572 > URL: https://jira.codehaus.org/browse/MRELEASE-572 > Project: Maven Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-9 >Reporter: Jens Beyer > > If the targetted release tag already exists (like accidentally re-releasing a > version), release:prepare does not complain about already existing tag, and > updates the tag in a wrong way. > Example: I call mvn release:prepare on my-project-1.0.0-SNAPSHOT. The tag > my-project-1.0.0 already exists. > Expected result: mvn fails with the error "version tag my-project-1.0.0 > already exists in SCM" > Current result: my-project-1.0.0 tag (!) is updated, with a new subdirectory > called 'my-project', below that is the expected result of the re-release; the > old data of the tag is still present. > I'd rather never update a tag (hence I'd like it to fail). That's why I > tagged it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5685) Profile with multiple conditions gets activated incorrectly
[
https://jira.codehaus.org/browse/MNG-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov closed MNG-5685.
---
Resolution: Not A Bug
As @rfscholte pointed out, this was a mistake on my side.
> Profile with multiple conditions gets activated incorrectly
> ---
>
> Key: MNG-5685
> URL: https://jira.codehaus.org/browse/MNG-5685
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Martin Todorov
>
> Consider the following simple profile:
> {code}
> ...
>
> some-profile
>
>
> !skipTests
>
> false
>
> ...
>
> ...
> {code}
> I would expect that this profile will not be active by default. Furthermore,
> it will not be active if the tests are skipped.
> However, if you execute:
> {code}
> mvn help:active-profiles
> {code}
> you will see:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building foo-bar: baz 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
> org.foo.bar:baz ---
> [INFO]
> Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - some-profile (source: org.foo.bar:baz:1.0-SNAPSHOT)
> {code}
> If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
> to do this.
> I believe this is related to MNG-4565.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5685) Profile with multiple conditions gets activated incorrectly
[
https://jira.codehaus.org/browse/MNG-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352563#comment-352563
]
Martin Todorov commented on MNG-5685:
-
Hi,
I think not (but do correct me, if I'm wrong): passing in -DskipTests (as far
as I am aware) is the same as -DskipTests=true.
Martin
> Profile with multiple conditions gets activated incorrectly
> ---
>
> Key: MNG-5685
> URL: https://jira.codehaus.org/browse/MNG-5685
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Martin Todorov
>
> Consider the following simple profile:
> {code}
> ...
>
> some-profile
>
>
> !skipTests
>
> false
>
> ...
>
> ...
> {code}
> I would expect that this profile will not be active by default. Furthermore,
> it will not be active if the tests are skipped.
> However, if you execute:
> {code}
> mvn help:active-profiles
> {code}
> you will see:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building foo-bar: baz 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
> org.foo.bar:baz ---
> [INFO]
> Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - some-profile (source: org.foo.bar:baz:1.0-SNAPSHOT)
> {code}
> If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
> to do this.
> I believe this is related to MNG-4565.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5685) Profile with multiple conditions gets activated incorrectly
[
https://jira.codehaus.org/browse/MNG-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MNG-5685:
Affects Version/s: 3.2.2
3.2.3
> Profile with multiple conditions gets activated incorrectly
> ---
>
> Key: MNG-5685
> URL: https://jira.codehaus.org/browse/MNG-5685
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.2.2, 3.2.3
>Reporter: Martin Todorov
>
> Consider the following simple profile:
> {code}
> ...
>
> some-profile
>
>
> !skipTests
>
> false
>
> ...
>
> ...
> {code}
> I would expect that this profile will not be active by default. Furthermore,
> it will not be active if the tests are skipped.
> However, if you execute:
> {code}
> mvn help:active-profiles
> {code}
> you will see:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building foo-bar: baz 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
> org.foo.bar:baz ---
> [INFO]
> Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - some-profile (source: org.foo.bar:baz:1.0-SNAPSHOT)
> {code}
> If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
> to do this.
> I believe this is related to MNG-4565.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5685) Profile with multiple conditions gets activated incorrectly
[
https://jira.codehaus.org/browse/MNG-5685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MNG-5685:
Description:
Consider the following simple profile:
{code}
...
some-profile
!skipTests
false
...
...
{code}
I would expect that this profile will not be active by default. Furthermore, it
will not be active if the tests are skipped.
However, if you execute:
{code}
mvn help:active-profiles
{code}
you will see:
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building foo-bar: baz 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
org.foo.bar:baz ---
[INFO]
Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
The following profiles are active:
- some-profile (source: org.foo.bar:baz:1.0-SNAPSHOT)
{code}
If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
to do this.
I believe this is related to MNG-4565.
was:
Consider the following simple profile:
{code}
...
some-profile
!skipTests
false
...
...
{code}
I would expect that this profile will not be active by default. Furthermore, it
will not be active if the tests are skipped.
However, if you execute:
{code}
mvn help:active-profiles
{code}
you will see:
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building foo-bar: baz 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
org.foo.bar:baz ---
[INFO]
Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
The following profiles are active:
- reserve-ports (source: org.foo.bar:baz:1.0-SNAPSHOT)
{code}
If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
to do this.
I believe this is related to MNG-4565.
> Profile with multiple conditions gets activated incorrectly
> ---
>
> Key: MNG-5685
> URL: https://jira.codehaus.org/browse/MNG-5685
> Project: Maven
> Issue Type: Bug
>Reporter: Martin Todorov
>
> Consider the following simple profile:
> {code}
> ...
>
> some-profile
>
>
> !skipTests
>
> false
>
> ...
>
> ...
> {code}
> I would expect that this profile will not be active by default. Furthermore,
> it will not be active if the tests are skipped.
> However, if you execute:
> {code}
> mvn help:active-profiles
> {code}
> you will see:
> {code}
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building foo-bar: baz 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
> org.foo.bar:baz ---
> [INFO]
> Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - some-profile (source: org.foo.bar:baz:1.0-SNAPSHOT)
> {code}
> If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
> to do this.
> I believe this is related to MNG-4565.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5685) Profile with multiple conditions gets activated incorrectly
Martin Todorov created MNG-5685:
---
Summary: Profile with multiple conditions gets activated
incorrectly
Key: MNG-5685
URL: https://jira.codehaus.org/browse/MNG-5685
Project: Maven
Issue Type: Bug
Reporter: Martin Todorov
Consider the following simple profile:
{code}
...
some-profile
!skipTests
false
...
...
{code}
I would expect that this profile will not be active by default. Furthermore, it
will not be active if the tests are skipped.
However, if you execute:
{code}
mvn help:active-profiles
{code}
you will see:
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building foo-bar: baz 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-help-plugin:2.2:active-profiles (default-cli) @
org.foo.bar:baz ---
[INFO]
Active Profiles for Project 'org.foo.bar:baz:jar:1.0-SNAPSHOT':
The following profiles are active:
- reserve-ports (source: org.foo.bar:baz:1.0-SNAPSHOT)
{code}
If you pass in -DskipTests, the profile gets disabled, but you shouldn't have
to do this.
I believe this is related to MNG-4565.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-91) Add a Spring based example
[ https://jira.codehaus.org/browse/MINDEXER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov closed MINDEXER-91. -- Resolution: Fixed > Add a Spring based example > -- > > Key: MINDEXER-91 > URL: https://jira.codehaus.org/browse/MINDEXER-91 > Project: Maven Indexer > Issue Type: Test >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > As discussed with Tamas, this will require extracting the currently existing > example module into a separate one and adding a new one under > maven-indexer-examples, producing the following modules: > - indexer-examples-basic > - indexer-examples-spring -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-91) Add a Spring based example
[ https://jira.codehaus.org/browse/MINDEXER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352168#comment-352168 ] Martin Todorov commented on MINDEXER-91: @cstamas, @hboutemy. I have this implemented on my fork [here|https://github.com/carlspring/maven-indexer/compare/MINDEXER-91]. Could either of you please have a look and let me know, if it's good enough for a pull request? Thanks, Martin > Add a Spring based example > -- > > Key: MINDEXER-91 > URL: https://jira.codehaus.org/browse/MINDEXER-91 > Project: Maven Indexer > Issue Type: Test >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > As discussed with Tamas, this will require extracting the currently existing > example module into a separate one and adding a new one under > maven-indexer-examples, producing the following modules: > - indexer-examples-basic > - indexer-examples-spring -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one
[ https://jira.codehaus.org/browse/MINDEXER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-83: --- Fix Version/s: 6.0 > 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://jira.codehaus.org/browse/MINDEXER-83 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov > 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.1.6#6162)
[jira] (MINDEXER-41) Allow to index several artifacts with no classifier
[
https://jira.codehaus.org/browse/MINDEXER-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINDEXER-41:
---
Assignee: Tamás Cservenák
> Allow to index several artifacts with no classifier
> ---
>
> Key: MINDEXER-41
> URL: https://jira.codehaus.org/browse/MINDEXER-41
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Julien HENRY
>Assignee: Tamás Cservenák
> Fix For: 6.0
>
>
> See details in this thread:
> http://maven.40175.n5.nabble.com/Search-with-several-artifacts-same-GAV-different-type-extension-td4902408.html
> The key used by indexer is GAVC (GAV + classifier where classifier can be
> null).
> With current design the indexer will only index one artifact with no
> classifier (= main artifact) + optionally additional secondary artifacts with
> classifier.
> This is an issue for custom packaging types that publish several artifacts
> with different extensions but no classifier.
> For example:
> {code}
> groupId
>/artifactId
> /version
> /artifactId-version.pom
> /artifactId-version.jar
> /artifactId-version.tld
> /artifactId-version.config
> {code}
> It would be good to include the extension in the index key => GAVCE. This way
> a search will return jar, tld and config artifacts.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-79) Make project Java7+
[ https://jira.codehaus.org/browse/MINDEXER-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-79: --- Assignee: Tamás Cservenák > Make project Java7+ > --- > > Key: MINDEXER-79 > URL: https://jira.codehaus.org/browse/MINDEXER-79 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 6.0 > > > Due to Lucene requirements. > http://lucene.apache.org/core/4_8_1/SYSTEM_REQUIREMENTS.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-85) POM model reading fails too often
[ https://jira.codehaus.org/browse/MINDEXER-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-85: --- Assignee: Tamás Cservenák > POM model reading fails too often > - > > Key: MINDEXER-85 > URL: https://jira.codehaus.org/browse/MINDEXER-85 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 6.0 > > > Seems it's due to "bare bone" Model reading by using directly Xpp3Dom builder > instead of Maven's model reader, as some XML entities that are usually > present in developer names and such causes POM to not be read. > qdox 1.6.0 from test resource is such an example POM. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-84) IllegalArgumentException: docID must be >= 0 and < maxDoc=6954 (got docID=6954)
[
https://jira.codehaus.org/browse/MINDEXER-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINDEXER-84:
---
Assignee: Tamás Cservenák
> IllegalArgumentException: docID must be >= 0 and < maxDoc=6954 (got
> docID=6954)
> ---
>
> Key: MINDEXER-84
> URL: https://jira.codehaus.org/browse/MINDEXER-84
> Project: Maven Indexer
> Issue Type: Bug
>Reporter: Tamás Cservenák
>Assignee: Tamás Cservenák
> Fix For: 6.0
>
>
> Issue reported as
> https://issues.sonatype.org/browse/NEXUS-5619
> {noformat}
> java.lang.IllegalArgumentException: docID must be >= 0 and < maxDoc=6954 (got
> docID=6954)
> at org.apache.lucene.index.IndexReader.document(IndexReader.java:1136)
> at
> org.apache.maven.index.updater.IndexDataWriter.writeDocuments(IndexDataWriter.java:173)
> at
> org.apache.maven.index.updater.IndexDataWriter.write(IndexDataWriter.java:93)
> at
> org.apache.maven.index.packer.DefaultIndexPacker.writeIndexData(DefaultIndexPacker.java:436)
> at
> org.apache.maven.index.packer.DefaultIndexPacker.packIndex(DefaultIndexPacker.java:137)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.publishRepositoryIndex(DefaultIndexerManager.java:1479)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.access$1000(DefaultIndexerManager.java:186)
> at
> org.sonatype.nexus.index.DefaultIndexerManager$10.run(DefaultIndexerManager.java:1438)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.shared(DefaultIndexerManager.java:2389)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.publishRepositoryIndex(DefaultIndexerManager.java:1432)
> at
> org.sonatype.nexus.index.DefaultIndexerManager.publishAllIndex(DefaultIndexerManager.java:1369)
> at
> org.sonatype.nexus.tasks.PublishIndexesTask.doRun(PublishIndexesTask.java:59)
> at
> org.sonatype.nexus.scheduling.AbstractNexusTask.call(AbstractNexusTask.java:166)
> at
> org.sonatype.scheduling.DefaultScheduledTask.call(DefaultScheduledTask.java:459)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-86) Remove "legacy" transport format
[ https://jira.codehaus.org/browse/MINDEXER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-86: --- Assignee: Tamás Cservenák > Remove "legacy" transport format > > > Key: MINDEXER-86 > URL: https://jira.codehaus.org/browse/MINDEXER-86 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák > Fix For: 6.0 > > > Index format "legacy", that is basically zipped up Lucene index should not be > supported anymore. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
[
https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov closed MINDEXER-89.
--
Resolution: Fixed
> Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to
> avoid "Address already in use"
> --
>
> Key: MINDEXER-89
> URL: https://jira.codehaus.org/browse/MINDEXER-89
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing
> on a system which is already using port 8080. It's quite common for this port
> to already be open on a developer's machine (or server), if they're running
> Tomcat or Jenkins.
> {code}
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> {code}
> Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
[
https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=352009#comment-352009
]
Martin Todorov commented on MINDEXER-89:
Closed [pull/6|https://github.com/apache/maven-indexer/pull/6] and created
[pull/7|https://github.com/apache/maven-indexer/pull/7] instead, fixing it in a
different way suggested by Tamas.
> Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to
> avoid "Address already in use"
> --
>
> Key: MINDEXER-89
> URL: https://jira.codehaus.org/browse/MINDEXER-89
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing
> on a system which is already using port 8080. It's quite common for this port
> to already be open on a developer's machine (or server), if they're running
> Tomcat or Jenkins.
> {code}
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> {code}
> Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-92) Make the BasicUsageExampleTest download an index from the local machine, instead of Maven Central
Martin Todorov created MINDEXER-92: -- Summary: Make the BasicUsageExampleTest download an index from the local machine, instead of Maven Central Key: MINDEXER-92 URL: https://jira.codehaus.org/browse/MINDEXER-92 Project: Maven Indexer Issue Type: Test Reporter: Martin Todorov Currently, the BasicUsageExampleTest tries to connect to Maven Central in order to download an index to use as test data. This should be replaced with a call to localhost, where an embedded Jetty should be listening via the jetty-maven-plugin. The index files should be available for download from there, instead of having to wait for a hundred megs to arrive over the net. A simple index with some valid test data could easily be generated. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
[
https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351975#comment-351975
]
Martin Todorov commented on MINDEXER-89:
Created [pull/6|https://github.com/apache/maven-indexer/pull/6].
@cstamas / @hboutemy: Could you please review this change and merge it? Thanks!
> Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to
> avoid "Address already in use"
> --
>
> Key: MINDEXER-89
> URL: https://jira.codehaus.org/browse/MINDEXER-89
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing
> on a system which is already using port 8080. It's quite common for this port
> to already be open on a developer's machine (or server), if they're running
> Tomcat or Jenkins.
> {code}
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> {code}
> Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
[
https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov reassigned MINDEXER-89:
--
Assignee: Martin Todorov
> Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to
> avoid "Address already in use"
> --
>
> Key: MINDEXER-89
> URL: https://jira.codehaus.org/browse/MINDEXER-89
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
>Assignee: Martin Todorov
> Fix For: 6.0
>
>
> The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing
> on a system which is already using port 8080. It's quite common for this port
> to already be open on a developer's machine (or server), if they're running
> Tomcat or Jenkins.
> {code}
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> {code}
> Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-41) Allow to index several artifacts with no classifier
[
https://jira.codehaus.org/browse/MINDEXER-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351917#comment-351917
]
Martin Todorov commented on MINDEXER-41:
@cstamas, so can this issue now be closed, or is other work still required? I
saw you've committed it as the "sixpack" merge.
> Allow to index several artifacts with no classifier
> ---
>
> Key: MINDEXER-41
> URL: https://jira.codehaus.org/browse/MINDEXER-41
> Project: Maven Indexer
> Issue Type: Improvement
>Reporter: Julien HENRY
> Fix For: 6.0
>
>
> See details in this thread:
> http://maven.40175.n5.nabble.com/Search-with-several-artifacts-same-GAV-different-type-extension-td4902408.html
> The key used by indexer is GAVC (GAV + classifier where classifier can be
> null).
> With current design the indexer will only index one artifact with no
> classifier (= main artifact) + optionally additional secondary artifacts with
> classifier.
> This is an issue for custom packaging types that publish several artifacts
> with different extensions but no classifier.
> For example:
> {code}
> groupId
>/artifactId
> /version
> /artifactId-version.pom
> /artifactId-version.jar
> /artifactId-version.tld
> /artifactId-version.config
> {code}
> It would be good to include the extension in the index key => GAVCE. This way
> a search will return jar, tld and config artifacts.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-91) Add a Spring based example
[ https://jira.codehaus.org/browse/MINDEXER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-91: --- Description: As discussed with Tamas, this will require extracting the currently existing example module into a separate one and adding a new one under maven-indexer-examples, producing the following modules: - indexer-examples-basic - indexer-examples-spring was: As discussed with Tamas, this will require extracting the currently existing example module into a separate one and adding a new one under maven-indexer-examples, producing the following modules: - maven-indexer-examples-basic - maven-indexer-examples-spring > Add a Spring based example > -- > > Key: MINDEXER-91 > URL: https://jira.codehaus.org/browse/MINDEXER-91 > Project: Maven Indexer > Issue Type: Test >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > As discussed with Tamas, this will require extracting the currently existing > example module into a separate one and adding a new one under > maven-indexer-examples, producing the following modules: > - indexer-examples-basic > - indexer-examples-spring -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-91) Add a Spring based example
[ https://jira.codehaus.org/browse/MINDEXER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov reassigned MINDEXER-91: -- Assignee: Martin Todorov > Add a Spring based example > -- > > Key: MINDEXER-91 > URL: https://jira.codehaus.org/browse/MINDEXER-91 > Project: Maven Indexer > Issue Type: Test >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > As discussed with Tamas, this will require extracting the currently existing > example module into a separate one and adding a new one under > maven-indexer-examples, producing the following modules: > - maven-indexer-examples-basic > - maven-indexer-examples-spring -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-91) Add a Spring based example
[ https://jira.codehaus.org/browse/MINDEXER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-91: --- Fix Version/s: 6.0 > Add a Spring based example > -- > > Key: MINDEXER-91 > URL: https://jira.codehaus.org/browse/MINDEXER-91 > Project: Maven Indexer > Issue Type: Test >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > As discussed with Tamas, this will require extracting the currently existing > example module into a separate one and adding a new one under > maven-indexer-examples, producing the following modules: > - maven-indexer-examples-basic > - maven-indexer-examples-spring -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-91) Add a Spring based example
Martin Todorov created MINDEXER-91: -- Summary: Add a Spring based example Key: MINDEXER-91 URL: https://jira.codehaus.org/browse/MINDEXER-91 Project: Maven Indexer Issue Type: Test Reporter: Martin Todorov As discussed with Tamas, this will require extracting the currently existing example module into a separate one and adding a new one under maven-indexer-examples, producing the following modules: - maven-indexer-examples-basic - maven-indexer-examples-spring -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-82) Create a module with examples
[ https://jira.codehaus.org/browse/MINDEXER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov closed MINDEXER-82. -- Resolution: Fixed Tamas, As this has been merged into the master, I'm now closing it. > Create a module with examples > - > > Key: MINDEXER-82 > URL: https://jira.codehaus.org/browse/MINDEXER-82 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > Tamas has already put some examples on a [Github > repo|https://github.com/cstamas/maven-indexer-examples]. I think it would > make perfect sense to polish this up a bit and put it as a separate module > (perhaps indexer-samples) so that other people could better understand how > things work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-39) study how to have maven-indexer non plexus/sisu dependant
[ https://jira.codehaus.org/browse/MINDEXER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-39: --- Issue Type: Sub-task (was: Improvement) Parent: MINDEXER-80 > study how to have maven-indexer non plexus/sisu dependant > - > > Key: MINDEXER-39 > URL: https://jira.codehaus.org/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.1.6#6162)
[jira] (MINDEXER-81) Make ArtifactInfo extensible
[ https://jira.codehaus.org/browse/MINDEXER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351601#comment-351601 ] Martin Todorov edited comment on MINDEXER-81 at 8/19/14 5:52 AM: - @Tamas: Could you please elaborate a bit further? was (Author: carlspring): @cstamas: Could you please elaborate a bit further? > Make ArtifactInfo extensible > > > Key: MINDEXER-81 > URL: https://jira.codehaus.org/browse/MINDEXER-81 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > Fix For: 6.0 > > > Make ArtifactInfo extensible, a followup of MINDEXER-32 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-81) Make ArtifactInfo extensible
[ https://jira.codehaus.org/browse/MINDEXER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351601#comment-351601 ] Martin Todorov commented on MINDEXER-81: @cstamas: Could you please elaborate a bit further? > Make ArtifactInfo extensible > > > Key: MINDEXER-81 > URL: https://jira.codehaus.org/browse/MINDEXER-81 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > Fix For: 6.0 > > > Make ArtifactInfo extensible, a followup of MINDEXER-32 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-24) Publish indexer site
[ https://jira.codehaus.org/browse/MINDEXER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-24: --- Fix Version/s: 6.0 > Publish indexer site > > > Key: MINDEXER-24 > URL: https://jira.codehaus.org/browse/MINDEXER-24 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > Fix For: 6.0 > > > Publish indexer site > http://maven.apache.org/maven-indexer -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-39) study how to have maven-indexer non plexus/sisu dependant
[ https://jira.codehaus.org/browse/MINDEXER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-39: --- Fix Version/s: 6.0 > study how to have maven-indexer non plexus/sisu dependant > - > > Key: MINDEXER-39 > URL: https://jira.codehaus.org/browse/MINDEXER-39 > Project: Maven Indexer > Issue Type: Improvement >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.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
[
https://jira.codehaus.org/browse/MINDEXER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINDEXER-89:
---
Fix Version/s: 6.0
> Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to
> avoid "Address already in use"
> --
>
> Key: MINDEXER-89
> URL: https://jira.codehaus.org/browse/MINDEXER-89
> Project: Maven Indexer
> Issue Type: Task
>Reporter: Martin Todorov
> Fix For: 6.0
>
>
> The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing
> on a system which is already using port 8080. It's quite common for this port
> to already be open on a developer's machine (or server), if they're running
> Tomcat or Jenkins.
> {code}
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
> {code}
> Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-82) Create a module with examples
[ https://jira.codehaus.org/browse/MINDEXER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov updated MINDEXER-82: --- Fix Version/s: 6.0 > Create a module with examples > - > > Key: MINDEXER-82 > URL: https://jira.codehaus.org/browse/MINDEXER-82 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov >Assignee: Martin Todorov > Fix For: 6.0 > > > Tamas has already put some examples on a [Github > repo|https://github.com/cstamas/maven-indexer-examples]. I think it would > make perfect sense to polish this up a bit and put it as a separate module > (perhaps indexer-samples) so that other people could better understand how > things work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-75) Squash indexer-artifact and indexer-core
[ https://jira.codehaus.org/browse/MINDEXER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov reassigned MINDEXER-75: -- Assignee: Martin Todorov > Squash indexer-artifact and indexer-core > > > Key: MINDEXER-75 > URL: https://jira.codehaus.org/browse/MINDEXER-75 > Project: Maven Indexer > Issue Type: Task >Reporter: Tamás Cservenák >Assignee: Martin Todorov >Priority: Minor > Fix For: 6.0 > > > This separation is a legacy, while this component was part of Sonatype Nexus. > There is no reason to have the 10 classes separated now. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-82) Create a module with examples
[ https://jira.codehaus.org/browse/MINDEXER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov reassigned MINDEXER-82: -- Assignee: Martin Todorov > Create a module with examples > - > > Key: MINDEXER-82 > URL: https://jira.codehaus.org/browse/MINDEXER-82 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov >Assignee: Martin Todorov > > Tamas has already put some examples on a [Github > repo|https://github.com/cstamas/maven-indexer-examples]. I think it would > make perfect sense to polish this up a bit and put it as a separate module > (perhaps indexer-samples) so that other people could better understand how > things work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-80) Drop Plexus as DI, use JSR330
[ https://jira.codehaus.org/browse/MINDEXER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov reassigned MINDEXER-80: -- Assignee: Martin Todorov > Drop Plexus as DI, use JSR330 > - > > Key: MINDEXER-80 > URL: https://jira.codehaus.org/browse/MINDEXER-80 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >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.1.6#6162)
[jira] (MINDEXER-32) Encapsulate ArtifactInfo fields
[ https://jira.codehaus.org/browse/MINDEXER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Todorov reassigned MINDEXER-32: -- Assignee: Martin Todorov > Encapsulate ArtifactInfo fields > --- > > Key: MINDEXER-32 > URL: https://jira.codehaus.org/browse/MINDEXER-32 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák >Assignee: Martin Todorov > Fix For: 6.0 > > > Make ArtifactInfo extensible. Currently this class "bleeds" from multiple > wounds: no setters and fixed fields. > This makes introduction of new fields (by core or by some extension > introducing new IndexCreator) nearly impossible, and is laborious. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-89) Use a more uncommon port for Jetty in the DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
Martin Todorov created MINDEXER-89:
--
Summary: Use a more uncommon port for Jetty in the
DefaultIndexUpdaterEmbeddingIT to avoid "Address already in use"
Key: MINDEXER-89
URL: https://jira.codehaus.org/browse/MINDEXER-89
Project: Maven Indexer
Issue Type: Task
Reporter: Martin Todorov
The DefaultIndexUpdaterEmbeddingIT integration test will fail, if executing on
a system which is already using port 8080. It's quite common for this port to
already be open on a developer's machine (or server), if they're running Tomcat
or Jenkins.
{code}
DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
DefaultIndexUpdaterEmbeddingIT.setUp:77 » Bind Address already in use
{code}
Perhaps the build-helper-maven-plugin could be used here to reserve a port.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-88) Clean up the plugin versions and possibly upgrade the plugins to their latest versions
Martin Todorov created MINDEXER-88:
--
Summary: Clean up the plugin versions and possibly upgrade the
plugins to their latest versions
Key: MINDEXER-88
URL: https://jira.codehaus.org/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.1.6#6162)
[jira] (MINDEXER-87) Remove legacy marked code
[ https://jira.codehaus.org/browse/MINDEXER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349066#comment-349066 ] Martin Todorov commented on MINDEXER-87: Could you please provide some more details about this? Perhaps a better explanation...? > Remove legacy marked code > - > > Key: MINDEXER-87 > URL: https://jira.codehaus.org/browse/MINDEXER-87 > Project: Maven Indexer > Issue Type: Bug >Reporter: Tamás Cservenák > Fix For: 6.0 > > > 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.1.6#6162)
[jira] (MINDEXER-39) study how to have maven-indexer non plexus/sisu dependant
[ https://jira.codehaus.org/browse/MINDEXER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349065#comment-349065 ] Martin Todorov commented on MINDEXER-39: I believe this could be closed with the merging of MINDEXER-80. > study how to have maven-indexer non plexus/sisu dependant > - > > Key: MINDEXER-39 > URL: https://jira.codehaus.org/browse/MINDEXER-39 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Olivier Lamy > > 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.1.6#6162)
[jira] (MINDEXER-80) Drop Plexus as DI, use JSR330
[ https://jira.codehaus.org/browse/MINDEXER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349054#comment-349054 ] Martin Todorov commented on MINDEXER-80: Please, accept [pull/4|https://github.com/apache/maven-indexer/pull/4], as discussed. I've applied the changes from your branch and the code is in a compiling state with passing tests. The only things that need to be done: - Polish the dependencies in the pom files. - Use guava instead of plexus-utils. > Drop Plexus as DI, use JSR330 > - > > Key: MINDEXER-80 > URL: https://jira.codehaus.org/browse/MINDEXER-80 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > 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.1.6#6162)
[jira] (MINDEXER-80) Drop Plexus as DI, use JSR330
[ https://jira.codehaus.org/browse/MINDEXER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349050#comment-349050 ] Martin Todorov commented on MINDEXER-80: Article on [how to replace Plexus with JSR-330|https://wiki.eclipse.org/Sisu/PlexusMigration]. > Drop Plexus as DI, use JSR330 > - > > Key: MINDEXER-80 > URL: https://jira.codehaus.org/browse/MINDEXER-80 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > 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.1.6#6162)
[jira] (MINVOKER-167) Make it possible to run tests written in Java (as opposed to the already existing support for Groovy and BSH)
Martin Todorov created MINVOKER-167: --- Summary: Make it possible to run tests written in Java (as opposed to the already existing support for Groovy and BSH) Key: MINVOKER-167 URL: https://jira.codehaus.org/browse/MINVOKER-167 Project: Maven Invoker Plugin Issue Type: Improvement Reporter: Martin Todorov Some people are unwilling to learn Groovy/BSH for the sake of testing a plugin. It would be so much more convenient being able to knock up your tests in plain Java and not have to wonder what Groovy's unhappy with this time. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://jira.codehaus.org/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348969#comment-348969
]
Martin Todorov commented on MINDEXER-49:
@Rene: The fact that you *can* do something, doesn't automatically mean that
it's right. Adding support for something like this will allow you to do more
things that you shouldn't really be doing, in my opinion...
You didn't provided a real-life example as part of your justification.
Also, as far as I am aware, the upcoming versions of Maven 3.2.x will introduce
new checks on the GAV's and POM's correctness. So, I don't quite think this
"feature" (even if implemented) will be: condoned very much, or be too
long-lived.
> M2GavCalculator does not parse GAV correctly for classifiers with dots
> --
>
> Key: MINDEXER-49
> URL: https://jira.codehaus.org/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.1.6#6162)
[jira] (MINDEXER-82) Create a module with examples
[ https://jira.codehaus.org/browse/MINDEXER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348966#comment-348966 ] Martin Todorov commented on MINDEXER-82: Tamas, Please, accept [pull/3|https://github.com/apache/maven-indexer/pull/3] as discussed. Regards, Martin > Create a module with examples > - > > Key: MINDEXER-82 > URL: https://jira.codehaus.org/browse/MINDEXER-82 > Project: Maven Indexer > Issue Type: Task >Reporter: Martin Todorov > > Tamas has already put some examples on a [Github > repo|https://github.com/cstamas/maven-indexer-examples]. I think it would > make perfect sense to polish this up a bit and put it as a separate module > (perhaps indexer-samples) so that other people could better understand how > things work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-24) Publish indexer site
[ https://jira.codehaus.org/browse/MINDEXER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348958#comment-348958 ] Martin Todorov commented on MINDEXER-24: Last night I filed [MINDEXER-82|https://jira.codehaus.org/browse/MINDEXER-82] which i think is related to this task. > Publish indexer site > > > Key: MINDEXER-24 > URL: https://jira.codehaus.org/browse/MINDEXER-24 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > > Publish indexer site > http://maven.apache.org/maven-indexer -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-24) Publish indexer site
[ https://jira.codehaus.org/browse/MINDEXER-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348955#comment-348955 ] Martin Todorov commented on MINDEXER-24: Is there anything else that needs to be done here? Do we need a separate task for creating a more detailed documentation in the generated site? > Publish indexer site > > > Key: MINDEXER-24 > URL: https://jira.codehaus.org/browse/MINDEXER-24 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > > Publish indexer site > http://maven.apache.org/maven-indexer -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-83) Refactor the Indexer.addArtifactsToIndex(...) method (possibly introduce new ones) so that it is possible to add artifact files one by one
Martin Todorov created MINDEXER-83: -- Summary: 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://jira.codehaus.org/browse/MINDEXER-83 Project: Maven Indexer Issue Type: Task Reporter: Martin Todorov 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.1.6#6162)
[jira] (MINDEXER-82) Create a module with examples
Martin Todorov created MINDEXER-82: -- Summary: Create a module with examples Key: MINDEXER-82 URL: https://jira.codehaus.org/browse/MINDEXER-82 Project: Maven Indexer Issue Type: Task Reporter: Martin Todorov Tamas has already put some examples on a [Github repo|https://github.com/cstamas/maven-indexer-examples]. I think it would make perfect sense to polish this up a bit and put it as a separate module (perhaps indexer-samples) so that other people could better understand how things work. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://jira.codehaus.org/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348942#comment-348942
]
Martin Todorov commented on MINDEXER-49:
I don't think it's a very good idea to have dots in your classifier at all.
What would constitute a reasonable use case? Could you provide a real-life
example?
The dot is used across a lot of places as an indication of where the GAV
details end. You cannot currently guess easily where the GAV ends otherwise.
Perhaps somebody didn't consider mentioning this in the Maven docs. I think
this should not be implemented/supported, or encouraged as a practice.
> M2GavCalculator does not parse GAV correctly for classifiers with dots
> --
>
> Key: MINDEXER-49
> URL: https://jira.codehaus.org/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.1.6#6162)
[jira] (MINDEXER-77) Upgrade to Lucene 4.1
[ https://jira.codehaus.org/browse/MINDEXER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348941#comment-348941 ] Martin Todorov commented on MINDEXER-77: Hi, Is there any outstanding work that needs to be done on this? We've started work on 6.0-SNAPSHOT and are considering merging and polishing some issues/fixes. Kind regards, Martin > Upgrade to Lucene 4.1 > - > > Key: MINDEXER-77 > URL: https://jira.codehaus.org/browse/MINDEXER-77 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Emmanuel Hugonnet > > Lucene has made a great effort in being quicker and smaller in the 4.x > versions. > Moving to this new version would make maven indexer better -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-75) Squash indexer-artifact and indexer-core
[ https://jira.codehaus.org/browse/MINDEXER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348910#comment-348910 ] Martin Todorov commented on MINDEXER-75: Hi, Please check https://github.com/apache/maven-indexer/pull/1. Kind regards, Martin > Squash indexer-artifact and indexer-core > > > Key: MINDEXER-75 > URL: https://jira.codehaus.org/browse/MINDEXER-75 > Project: Maven Indexer > Issue Type: Task >Reporter: Tamás Cservenák >Priority: Minor > > This separation is a legacy, while this component was part of Sonatype Nexus. > There is no reason to have the 10 classes separated now. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-32) Make ArtifactInfo extensible
[ https://jira.codehaus.org/browse/MINDEXER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348486#comment-348486 ] Martin Todorov commented on MINDEXER-32: For which fields would it make sense to introduce getters and setters? > Make ArtifactInfo extensible > > > Key: MINDEXER-32 > URL: https://jira.codehaus.org/browse/MINDEXER-32 > Project: Maven Indexer > Issue Type: Improvement >Reporter: Tamás Cservenák > > Make ArtifactInfo extensible. Currently this class "bleeds" from multiple > wounds: no setters and fixed fields. > This makes introduction of new fields (by core or by some extension > introducing new IndexCreator) nearly impossible, and is laborious. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-75) Squash indexer-artifact and indexer-core
[ https://jira.codehaus.org/browse/MINDEXER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=348485#comment-348485 ] Martin Todorov commented on MINDEXER-75: What would be the name of the renamed module -- indexer-artifact, or indexer-core? > Squash indexer-artifact and indexer-core > > > Key: MINDEXER-75 > URL: https://jira.codehaus.org/browse/MINDEXER-75 > Project: Maven Indexer > Issue Type: Task >Reporter: Tamás Cservenák >Priority: Minor > > This separation is a legacy, while this component was part of Sonatype Nexus. > There is no reason to have the 10 classes separated now. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINSTALL-97) Plugin installs wrong artifact
[
https://jira.codehaus.org/browse/MINSTALL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=333147#comment-333147
]
Martin Todorov commented on MINSTALL-97:
Yeah, I know about classifiers. I was expecting the install plugin would pick
it up though. I'm quite sure I've done this without classifiers in an older
project which was using Maven 2.2.1.
Anyway... I'll do it with a classifier then instead. Thanks!
> Plugin installs wrong artifact
> --
>
> Key: MINSTALL-97
> URL: https://jira.codehaus.org/browse/MINSTALL-97
> Project: Maven Install Plugin
> Issue Type: Bug
> Environment: Apache Maven 3.1.0
> (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28 03:15:32+0100)
> Maven home: /java/apache/maven-3.1.0
> Java version: 1.7.0_25, vendor: Oracle Corporation
> Java home: /java/jdk1.7.0_25/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux", version: "2.6.39.4", arch: "amd64", family: "unix"
>Reporter: Martin Todorov
>Assignee: Robert Scholte
>
> I have a project with packaging type "war". I have attached the "jar" plugin
> to the package phase just so that it also creates a jar file (containing some
> of the classes + resources). Both archives are produced properly.
> Then i see:
> {code}
> [INFO] Installing
> /java/opensource/carlspring/strongbox/strongbox-webapp/target/strongbox-webapp-1.0-SNAPSHOT.jar
> to
> /root/.m2/repository/org/carlspring/strongbox/strongbox-webapp/1.0-SNAPSHOT/strongbox-webapp-1.0-SNAPSHOT.war
> {code}
> This is my simplified pom.xml
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> strongbox-webapp
> 1.0-SNAPSHOT
> war
> Strongbox: Webapp
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>
> org.apache.maven.plugins
> maven-source-plugin
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> package
>
> jar
>
>
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5
>
>
>
>
> {code}
> This is installing the wrong artifact. I've tried it with 2.4 and 2.5.
> Please advise!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-97) Plugin installs wrong artifact
[
https://jira.codehaus.org/browse/MINSTALL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINSTALL-97:
---
Summary: Plugin installs wrong artifact (was: Plugin install wrong
artifact)
> Plugin installs wrong artifact
> --
>
> Key: MINSTALL-97
> URL: https://jira.codehaus.org/browse/MINSTALL-97
> Project: Maven Install Plugin
> Issue Type: Bug
> Environment: Apache Maven 3.1.0
> (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28 03:15:32+0100)
> Maven home: /java/apache/maven-3.1.0
> Java version: 1.7.0_25, vendor: Oracle Corporation
> Java home: /java/jdk1.7.0_25/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux", version: "2.6.39.4", arch: "amd64", family: "unix"
>Reporter: Martin Todorov
>Assignee: Robert Scholte
>
> I have a project with packaging type "war". I have attached the "jar" plugin
> to the package phase just so that it also creates a jar file (containing some
> of the classes + resources). Both archives are produced properly.
> Then i see:
> {code}
> [INFO] Installing
> /java/opensource/carlspring/strongbox/strongbox-webapp/target/strongbox-webapp-1.0-SNAPSHOT.jar
> to
> /root/.m2/repository/org/carlspring/strongbox/strongbox-webapp/1.0-SNAPSHOT/strongbox-webapp-1.0-SNAPSHOT.war
> {code}
> This is my simplified pom.xml
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> strongbox-webapp
> 1.0-SNAPSHOT
> war
> Strongbox: Webapp
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>
> org.apache.maven.plugins
> maven-source-plugin
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> package
>
> jar
>
>
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5
>
>
>
>
> {code}
> This is installing the wrong artifact. I've tried it with 2.4 and 2.5.
> Please advise!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-97) Plugin install wrong artifact
[
https://jira.codehaus.org/browse/MINSTALL-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Todorov updated MINSTALL-97:
---
Description:
I have a project with packaging type "war". I have attached the "jar" plugin to
the package phase just so that it also creates a jar file (containing some of
the classes + resources). Both archives are produced properly.
Then i see:
{code}
[INFO] Installing
/java/opensource/carlspring/strongbox/strongbox-webapp/target/strongbox-webapp-1.0-SNAPSHOT.jar
to
/root/.m2/repository/org/carlspring/strongbox/strongbox-webapp/1.0-SNAPSHOT/strongbox-webapp-1.0-SNAPSHOT.war
{code}
This is my simplified pom.xml
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
strongbox-webapp
1.0-SNAPSHOT
war
Strongbox: Webapp
org.apache.maven.plugins
maven-compiler-plugin
org.apache.maven.plugins
maven-source-plugin
org.apache.maven.plugins
maven-jar-plugin
package
jar
org.apache.maven.plugins
maven-install-plugin
2.5
{code}
This is installing the wrong artifact. I've tried it with 2.4 and 2.5.
Please advise!
was:
I have a project with packaging type "war". I have attached the "jar" plugin to
the package phase just so that it also creates a jar file (containing some of
the classes + resources). Both archives are produced properly.
Then i see:
{code}
[INFO] Installing
/java/opensource/carlspring/strongbox/strongbox-webapp/target/strongbox-webapp-1.0-SNAPSHOT.jar
to
/root/.m2/repository/org/carlspring/strongbox/strongbox-webapp/1.0-SNAPSHOT/strongbox-webapp-1.0-SNAPSHOT.war
{code}
This is installing the wrong artifact. I've tried it with 2.4 and 2.5.
Please advise!
> Plugin install wrong artifact
> -
>
> Key: MINSTALL-97
> URL: https://jira.codehaus.org/browse/MINSTALL-97
> Project: Maven Install Plugin
> Issue Type: Bug
> Environment: Apache Maven 3.1.0
> (893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28 03:15:32+0100)
> Maven home: /java/apache/maven-3.1.0
> Java version: 1.7.0_25, vendor: Oracle Corporation
> Java home: /java/jdk1.7.0_25/jre
> Default locale: en_US, platform encoding: ISO-8859-1
> OS name: "linux", version: "2.6.39.4", arch: "amd64", family: "unix"
>Reporter: Martin Todorov
>
> I have a project with packaging type "war". I have attached the "jar" plugin
> to the package phase just so that it also creates a jar file (containing some
> of the classes + resources). Both archives are produced properly.
> Then i see:
> {code}
> [INFO] Installing
> /java/opensource/carlspring/strongbox/strongbox-webapp/target/strongbox-webapp-1.0-SNAPSHOT.jar
> to
> /root/.m2/repository/org/carlspring/strongbox/strongbox-webapp/1.0-SNAPSHOT/strongbox-webapp-1.0-SNAPSHOT.war
> {code}
> This is my simplified pom.xml
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> strongbox-webapp
> 1.0-SNAPSHOT
> war
> Strongbox: Webapp
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
>
> org.apache.maven.plugins
> maven-source-plugin
>
>
> org.apache.maven.plugins
> maven-jar-plugin
>
>
> package
>
> jar
>
>
>
>
>
> org.apache.maven.plugins
> maven-install-plugin
> 2.5
>
>
>
>
> {code}
> This is installing the wrong artifact. I've tried it with 2.4 and 2.5.
> Please advise!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-97) Plugin install wrong artifact
Martin Todorov created MINSTALL-97:
--
Summary: Plugin install wrong artifact
Key: MINSTALL-97
URL: https://jira.codehaus.org/browse/MINSTALL-97
Project: Maven Install Plugin
Issue Type: Bug
Environment: Apache Maven 3.1.0
(893ca28a1da9d5f51ac03827af98bb730128f9f2; 2013-06-28 03:15:32+0100)
Maven home: /java/apache/maven-3.1.0
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /java/jdk1.7.0_25/jre
Default locale: en_US, platform encoding: ISO-8859-1
OS name: "linux", version: "2.6.39.4", arch: "amd64", family: "unix"
Reporter: Martin Todorov
I have a project with packaging type "war". I have attached the "jar" plugin to
the package phase just so that it also creates a jar file (containing some of
the classes + resources). Both archives are produced properly.
Then i see:
{code}
[INFO] Installing
/java/opensource/carlspring/strongbox/strongbox-webapp/target/strongbox-webapp-1.0-SNAPSHOT.jar
to
/root/.m2/repository/org/carlspring/strongbox/strongbox-webapp/1.0-SNAPSHOT/strongbox-webapp-1.0-SNAPSHOT.war
{code}
This is installing the wrong artifact. I've tried it with 2.4 and 2.5.
Please advise!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-118) Enable deployment of attached release artifacts if POM is identical
[ https://jira.codehaus.org/browse/MDEPLOY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328066#comment-328066 ] Martin Todorov commented on MDEPLOY-118: Checking if an artifact exists can be done using the WagonDownload.exists() method. More details can be found [here|http://jarvana.com/jarvana/view/org/codehaus/mojo/wagon-maven-plugin/1.0-beta-3/wagon-maven-plugin-1.0-beta-3-sources.jar!/org/codehaus/mojo/wagon/shared/DefaultWagonDownload.java?format=ok]. > Enable deployment of attached release artifacts if POM is identical > --- > > Key: MDEPLOY-118 > URL: https://jira.codehaus.org/browse/MDEPLOY-118 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.4 > Environment: Windows XP SP3 >Reporter: Bruno F > Labels: contributers-welcome > > In the context of the build of a native application, one might have > zip-artifacts containing several DLL or so files like: > boost:boost_regex:1.34.1:zip > In order to distinguish between platforms, it seems to be recommended to use > the classifier: > boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 > or: > boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 > If a Maven repository manager is configured to prevent from re-deploying > release artifacts (and I believe it should be), it is not possible to deploy > attached artifacts when the POM is the same because the POM is deployed > twice. The deploy plugin could check that the POM is already deployed and is > the same than the local one (modulo platform-dependent line-break concerns, > and that's important!), then choose not to deploy it but only the attached > artifact. > In the example above, it could enable to deploy the > boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 artifact from a Windows > machine(coming along with a boost:boost_regex:1.34.1:pom artifact), then to > deploy the boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 artifact from > a Linux machine (coming along with the same boost:boost_regex:1.34.1:pom > artifact, that will not be deployed since it is identical to the first one > deployed). > Maybe this could be generalized to any kind of artifact? If the artifact to > deploy is the same, the plugin should not fail and simply skip the deployment > of that artifact? > I post that bug here on a suggestion of Brett Porter (see the MRM-1357 bug) > since it is quite unclear to me whether it is a MRM or deploy plugin concern. > That bug might also be related to: > - MDEPLOY-117 > - MDEPLOY-114 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-420) The dependency:get goal does not download the associate pom, or provide an option to do that
Martin Todorov created MDEP-420: --- Summary: The dependency:get goal does not download the associate pom, or provide an option to do that Key: MDEP-420 URL: https://jira.codehaus.org/browse/MDEP-420 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: get Affects Versions: 2.8 Reporter: Martin Todorov The dependency:get goal does not download the associate .pom, or provide an option to do that. Instead one needs to do a second invocation in order to resolve the pom. It would be great if you could add this feature. Much appreciated! :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-156) Make it possible to have per project local repositories
[ https://jira.codehaus.org/browse/MINVOKER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326800#comment-326800 ] Martin Todorov commented on MINVOKER-156: - This is interesting! Could you please explain a bit about it? I am working on https://github.com/carlspring/repository-unit-framework. This is basically a plugin which lights up a Jetty server with a "repository" restlet and you can mock artifacts in it and try to resolve or deploy them. How does the project you mentioned relate to this? (I had a look a it, but the pages are rather vague and contain little information). > Make it possible to have per project local repositories > --- > > Key: MINVOKER-156 > URL: https://jira.codehaus.org/browse/MINVOKER-156 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Affects Versions: 1.8 >Reporter: Martin Todorov > > Currently, there is one local-repo which is used by all of the tests. In > certain cases one may want to have or (for the same matter) not have a > dependency in the local repository for a given test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-152) Support pomless projects
[
https://jira.codehaus.org/browse/MINVOKER-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326008#comment-326008
]
Martin Todorov edited comment on MINVOKER-152 at 5/31/13 11:40 AM:
---
This is actually working.
However, one must explicitly define a directory pattern matching the names of
the directories containing pomless tests.
The example below illustrates how to have both pom-based and pomless invocation
tests by overriding the pomIncludes (which in my opinion should be handled
internally by default):
{code}
org.apache.maven.plugins
maven-invoker-plugin
1.8
true
clean
verify
${project.build.directory}/local-repo
${project.build.directory}/it
integration-tests-with-poms
install
run
package
**/pom.xml
**/*-pomless-*
{code}
I believe the scanner that locates all the directories containing pom.xml-s
should be further extended to check whether the directory contains an
invoker.properties, which is where you would specify the goals to invoke your
plugin. For example:
{code}
invoker.goals=groupId:plugin-name:${project.version}:goal -Dfoo=bar
{code}
was (Author: carlspring):
This is actually working. However, one must explicitly define a directory
pattern matching the names of the directories containing pomless tests. The
example below illustrates how to have both pom-based and pomless invocation
tests by using two separate executions:
{code}
org.apache.maven.plugins
maven-invoker-plugin
1.8
true
clean
verify
${project.build.directory}/local-repo
${project.build.directory}/it
integration-tests-with-poms
install
run
package
**/*-pomless-*
integration-tests-without-poms
install
run
package
**/*-pomless-*
{code}
I believe the scanner that locates all the directories containing pom.xml-s
should be further extended to check whether the directory contains an
invoker.properties, which is where you would specify the goals to invoke your
plugin. For example:
{code}
invoker.goals=groupId:plugin-name:${project.version}:goal -Dfoo=bar
{code}
> Support pomless projects
>
>
> Key: MINVOKER-152
> URL: https://jira.codehaus.org/browse/MINVOKER-152
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.8
>Reporter: Robert Scholte
>
> I must be possible to test goals without a {{pom.xml}}, as in real life,
> because it can have a different behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-156) Make it possible to have per project local repositories
Martin Todorov created MINVOKER-156: --- Summary: Make it possible to have per project local repositories Key: MINVOKER-156 URL: https://jira.codehaus.org/browse/MINVOKER-156 Project: Maven 2.x Invoker Plugin Issue Type: New Feature Affects Versions: 1.8 Reporter: Martin Todorov Currently, there is one local-repo which is used by all of the tests. In certain cases one may want to have or (for the same matter) not have a dependency in the local repository for a given test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-152) Support pomless projects
[
https://jira.codehaus.org/browse/MINVOKER-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326008#comment-326008
]
Martin Todorov edited comment on MINVOKER-152 at 5/31/13 9:58 AM:
--
This is actually working. However, one must explicitly define a directory
pattern matching the names of the directories containing pomless tests. The
example below illustrates how to have both pom-based and pomless invocation
tests by using two separate executions:
{code}
org.apache.maven.plugins
maven-invoker-plugin
1.8
true
clean
verify
${project.build.directory}/local-repo
${project.build.directory}/it
integration-tests-with-poms
install
run
package
**/*-pomless-*
integration-tests-without-poms
install
run
package
**/*-pomless-*
{code}
I believe the scanner that locates all the directories containing pom.xml-s
should be further extended to check whether the directory contains an
invoker.properties, which is where you would specify the goals to invoke your
plugin. For example:
{code}
invoker.goals=groupId:plugin-name:${project.version}:goal -Dfoo=bar
{code}
was (Author: carlspring):
This is actually working. However, one must explicitly define a directory
pattern matching the names of the directories containing pomless tests. The
example below illustrates how to have both pom-based and pomless invocation
tests by using two separate executions:
{code}
org.apache.maven.plugins
maven-invoker-plugin
1.8
true
clean
verify
${project.build.directory}/local-repo
${project.build.directory}/it
integration-tests-with-poms
install
run
package
**/*-pomless-*
integration-tests-without-poms
install
run
package
**/*-pomless-*
{code}
> Support pomless projects
>
>
> Key: MINVOKER-152
> URL: https://jira.codehaus.org/browse/MINVOKER-152
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.8
>Reporter: Robert Scholte
>
> I must be possible to test goals without a {{pom.xml}}, as in real life,
> because it can have a different behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-152) Support pomless projects
[
https://jira.codehaus.org/browse/MINVOKER-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=326008#comment-326008
]
Martin Todorov commented on MINVOKER-152:
-
This is actually working. However, one must explicitly define a directory
pattern matching the names of the directories containing pomless tests. The
example below illustrates how to have both pom-based and pomless invocation
tests by using two separate executions:
{code}
org.apache.maven.plugins
maven-invoker-plugin
1.8
true
clean
verify
${project.build.directory}/local-repo
${project.build.directory}/it
integration-tests-with-poms
install
run
package
**/*-pomless-*
integration-tests-without-poms
install
run
package
**/*-pomless-*
{code}
> Support pomless projects
>
>
> Key: MINVOKER-152
> URL: https://jira.codehaus.org/browse/MINVOKER-152
> Project: Maven 2.x Invoker Plugin
> Issue Type: New Feature
>Affects Versions: 1.8
>Reporter: Robert Scholte
>
> I must be possible to test goals without a {{pom.xml}}, as in real life,
> because it can have a different behavior.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-159) deploy:deploy-file should use default values from pom.xml
[ https://jira.codehaus.org/browse/MDEPLOY-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=322572#comment-322572 ] Martin Todorov commented on MDEPLOY-159: The deploy:deploy-file goal is mainly meant for use from the console with pomless projects. For example, if you have a non-mavenized Java library which you would like to have deployed to your repository. I think this would be a change of behaviour. There could, however be a property which could be passed in that tells Maven to use a pom.xml (if such is present). However, in the majority of the cases, this will most-likely not be so. > deploy:deploy-file should use default values from pom.xml > - > > Key: MDEPLOY-159 > URL: https://jira.codehaus.org/browse/MDEPLOY-159 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Improvement > Components: deploy:deploy-file >Affects Versions: 2.7 >Reporter: Robert Zanzerkia >Priority: Minor > > Currently deploy-file requires all of below arguments. > -Durl > -DrepositoryId > -DartifactId > -Dversion > -Dpackaging=zip > -Dfile=./target/uCMDB-PatternDev-0.0.1-SNAPSHOT-packages.zip > Other than the file argument it should default to values defined in project > pom.xml IF not defined on the command line. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-118) Enable deployment of attached release artifacts if POM is identical
[
https://jira.codehaus.org/browse/MDEPLOY-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321965#comment-321965
]
Martin Todorov commented on MDEPLOY-118:
In Maven 3.1-SNAPSHOT, the location of the affected code is in
[DefaultWagonManager|https://svn.apache.org/repos/asf/maven/maven-3/trunk/maven-compat/src/main/java/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java],
more specifically in the block below:
{code}
for ( ArtifactMetadata metadata : artifact.getMetadataList() )
{
if ( metadata instanceof ProjectArtifactMetadata )
{
org.sonatype.aether.artifact.Artifact pomArtifact = new
SubArtifact( mainArtifact, "", "pom" );
pomArtifact = pomArtifact.setFile( ( (ProjectArtifactMetadata)
metadata ).getFile() );
request.addArtifact( pomArtifact );
}
else if ( metadata instanceof SnapshotArtifactRepositoryMetadata
|| metadata instanceof ArtifactRepositoryMetadata )
{
// eaten, handled by repo system
}
else
{
request.addMetadata( new MetadataBridge( metadata ) );
}
}
{code}
I believe the first if condition should check if the .pom file already exists
on the remote server and not add it to deploy request. If I were to fix this,
could somebody please advise on how to check this and whether using the Wagon's
resourceExists(...) method is the correct way. (If so, an example of how to use
it would be highly appreciated).
> Enable deployment of attached release artifacts if POM is identical
> ---
>
> Key: MDEPLOY-118
> URL: https://jira.codehaus.org/browse/MDEPLOY-118
> Project: Maven 2.x and 3.x Deploy Plugin
> Issue Type: Improvement
>Affects Versions: 2.4
> Environment: Windows XP SP3
>Reporter: Bruno F
> Labels: contributers-welcome
>
> In the context of the build of a native application, one might have
> zip-artifacts containing several DLL or so files like:
> boost:boost_regex:1.34.1:zip
> In order to distinguish between platforms, it seems to be recommended to use
> the classifier:
> boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8
> or:
> boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3
> If a Maven repository manager is configured to prevent from re-deploying
> release artifacts (and I believe it should be), it is not possible to deploy
> attached artifacts when the POM is the same because the POM is deployed
> twice. The deploy plugin could check that the POM is already deployed and is
> the same than the local one (modulo platform-dependent line-break concerns,
> and that's important!), then choose not to deploy it but only the attached
> artifact.
> In the example above, it could enable to deploy the
> boost:boost_regex:1.34.1:zip:bin-x86-windows-vc8 artifact from a Windows
> machine(coming along with a boost:boost_regex:1.34.1:pom artifact), then to
> deploy the boost:boost_regex:1.34.1:zip:bin-x86-linux2.6-gcc3.3 artifact from
> a Linux machine (coming along with the same boost:boost_regex:1.34.1:pom
> artifact, that will not be deployed since it is identical to the first one
> deployed).
> Maybe this could be generalized to any kind of artifact? If the artifact to
> deploy is the same, the plugin should not fail and simply skip the deployment
> of that artifact?
> I post that bug here on a suggestion of Brett Porter (see the MRM-1357 bug)
> since it is quite unclear to me whether it is a MRM or deploy plugin concern.
> That bug might also be related to:
> - MDEPLOY-117
> - MDEPLOY-114
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321866#comment-321866 ] Martin Todorov commented on MDEPLOY-157: Right, that sounds reasonable. Thanks for implementing this feature! > Add deployAtEnd option for multimodule projects > --- > > Key: MDEPLOY-157 > URL: https://jira.codehaus.org/browse/MDEPLOY-157 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.7 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 2.8 > > > With this option it will be possible to only deploy artifacts if all have > been succesfully installed. > See MRELEASE-664 for further details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=321817#comment-321817 ] Martin Todorov commented on MDEPLOY-157: I think it would actually make more sense to have this on by default. > Add deployAtEnd option for multimodule projects > --- > > Key: MDEPLOY-157 > URL: https://jira.codehaus.org/browse/MDEPLOY-157 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.7 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 2.8 > > > With this option it will be possible to only deploy artifacts if all have > been succesfully installed. > See MRELEASE-664 for further details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
