[jira] (MINDEXER-63) NullPointerException at org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
Milos Kleint created MINDEXER-63:
Summary: NullPointerException at
org.apache.maven.index.context.DefaultIndexingContext.acquireIndexSearcher
Key: MINDEXER-63
URL: https://jira.codehaus.org/browse/MINDEXER-63
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 5.0.0
Environment: netbeans 7.3 dev builds.
Reporter: Milos Kleint
Priority: Critical
see issue http://netbeans.org/bugzilla/show_bug.cgi?id=219645
for some reason (unknown to me yet) the index files cannot be deleted. The
codebase then gets into bad state.
possibly wrong code in DefaultIndexingContext:
public synchronized void replace( Directory directory )
    throws IOException
  {
    final Date ts = IndexUtils.getTimestamp( directory );
    closeReaders();
    deleteIndexFiles( false );
    IndexUtils.copyDirectory( directory, indexDirectory );
    openAndWarmup();
    // reclaim the index as mine
    storeDescriptor();
    updateTimestamp( true, ts );
    optimize();
  }
when deleteIndexFiles(0 fails, openAndWarmup() is not called. also
closeReaders() ignores indexWriter..
--
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] (DOXIA-472) No page title is set when using markdown
[ https://jira.codehaus.org/browse/DOXIA-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311476#comment-311476 ] Benjamin Piwowarski commented on DOXIA-472: --- Hi, this is already possible by using Your title as the first line of your MarkedDown page > No page title is set when using markdown > > > Key: DOXIA-472 > URL: https://jira.codehaus.org/browse/DOXIA-472 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Markdown >Affects Versions: 1.3 >Reporter: Klaus Reimer >Priority: Minor > > No page title is created for pages which are defined with the markup language > "markdown". A page in a project named "Test" opened with Chrome for example > has the browser title "Test - - Chrome" and the browser tab is labeled with > "Test - ". > I recommend using the first headline in the markdown file as a page title. -- 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] (DOXIA-472) No page title is set when using markdown
[ https://jira.codehaus.org/browse/DOXIA-472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311476#comment-311476 ] Benjamin Piwowarski edited comment on DOXIA-472 at 10/15/12 3:13 AM: - This is already possible by using Your title as the first line of your MarkedDown page was (Author: bpiwowar): Hi, this is already possible by using Your title as the first line of your MarkedDown page > No page title is set when using markdown > > > Key: DOXIA-472 > URL: https://jira.codehaus.org/browse/DOXIA-472 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Markdown >Affects Versions: 1.3 >Reporter: Klaus Reimer >Priority: Minor > > No page title is created for pages which are defined with the markup language > "markdown". A page in a project named "Test" opened with Chrome for example > has the browser title "Test - - Chrome" and the browser tab is labeled with > "Test - ". > I recommend using the first headline in the markdown file as a page title. -- 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] (MEAR-159) encoding when filtering resources
Alex Kaigorodov created MEAR-159: Summary: encoding when filtering resources Key: MEAR-159 URL: https://jira.codehaus.org/browse/MEAR-159 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Reporter: Alex Kaigorodov Attachments: maven-ear-plugin-test-project-resources-encoding.zip Resources of our ear project contain non-ascii characters. This xml-files in windows-1251. We use filtering resources when building ear. Building in the dev environment (Windows, file.encoding = Cp1251) goes well. The build at the CI-server (Linux, file.encoding = UTF-8) non-ascii characters in xml-files are replaced with a sequence of bytes 'efbfbd'. It would be convenient to be able to specify the encoding for the ear resources, similar to how we can do it in the maven-resources-plugin. Sample project attached. -- 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] (MRELEASE-536) CommonBasedir Calculation fails on windows
[ https://jira.codehaus.org/browse/MRELEASE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311495#comment-311495 ] Jose Rodolfo Freitas commented on MRELEASE-536: --- Hey Guys, I'm on 2.3.2 version of the release plugin and I have this exact error. I suspect that the exception is thrown by the same cause. Is this a zombie bug? > CommonBasedir Calculation fails on windows > -- > > Key: MRELEASE-536 > URL: https://jira.codehaus.org/browse/MRELEASE-536 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0 >Reporter: Matthias Vach >Assignee: Brett Porter > Fix For: 2.1 > > Attachments: patchfile.patch > > > The method getCommonBasedir in class > org.apache.maven.shared.release.util.ReleaseUtil runs into the Exception:\\ > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > ... while comparing pathes with small and capital lettes for Windows drives. > e.g.: C:\WoRkInG\root\project1 has no common base dir with > c:\working\root\project2\\ but it should have c:\working\root as common base > directory. > A patch and a test for that bug is attached. > I do have the problem with version 2.0 but I fixed it in trunk for now > Regards Matthias -- 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] (MDEP-369) fails :get using remoteRepositories and maven3
[ https://jira.codehaus.org/browse/MDEP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kudrevatykh updated MDEP-369: --- Attachment: out2.txt out.txt command line is org.apache.maven.plugins:maven-dependency-plugin:2.5:get -DremoteRepositories=chttp://akudrevatykh:7081/nexus/content/groups/dbclear-all -Dartifact=org.supercsv:supercsv:1.5.2 > fails :get using remoteRepositories and maven3 > -- > > Key: MDEP-369 > URL: https://jira.codehaus.org/browse/MDEP-369 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: get >Affects Versions: 2.4, 2.5 > Environment: maven3.0.4 > windows7 > jdk1.7.0_01 >Reporter: Alexander Kudrevatykh > Attachments: out2.txt, out.txt > > > When I type mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:get > -DremoteRepositories=url ... plugin fails to download artifact from > remote repository. > When using repoId and repoUrl properties or maven 2.2.1 all works fine. -- 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] (MDEP-369) fails :get using remoteRepositories and maven3
[ https://jira.codehaus.org/browse/MDEP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311501#comment-311501 ] Alexander Kudrevatykh edited comment on MDEP-369 at 10/15/12 8:47 AM: -- command line is mvn -X org.apache.maven.plugins:maven-dependency-plugin:2.5:get -DremoteRepositories=chttp://akudrevatykh:7081/nexus/content/groups/dbclear-all -Dartifact=org.supercsv:supercsv:1.5.2 was (Author: kudrevatykh): command line is org.apache.maven.plugins:maven-dependency-plugin:2.5:get -DremoteRepositories=chttp://akudrevatykh:7081/nexus/content/groups/dbclear-all -Dartifact=org.supercsv:supercsv:1.5.2 > fails :get using remoteRepositories and maven3 > -- > > Key: MDEP-369 > URL: https://jira.codehaus.org/browse/MDEP-369 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: get >Affects Versions: 2.4, 2.5 > Environment: maven3.0.4 > windows7 > jdk1.7.0_01 >Reporter: Alexander Kudrevatykh > Attachments: out2.txt, out.txt > > > When I type mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:get > -DremoteRepositories=url ... plugin fails to download artifact from > remote repository. > When using repoId and repoUrl properties or maven 2.2.1 all works fine. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christofer Dutz updated MNG-5358: - Attachment: Test.zip Test project that can be used to produce the problems. > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
Christofer Dutz created MNG-5358: Summary: Install Plugin installs poms that contain variables in artifact version and parent version Key: MNG-5358 URL: https://jira.codehaus.org/browse/MNG-5358 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories, Deployment Affects Versions: 3.0.3 Reporter: Christofer Dutz Attachments: Test.zip I am currently trying to create a build process that is optimized for being able to have individual modules of one project deployed with different versions. Therefore I created a build that uses properties for providing the version numbers for artifacts, dependencies and parent relations. The build is working nicely, unfortunately the install plugin installs the artifacts into the correct directories, but it doesn't replace the properties. This way the repo contains artifacts it can certainly not resolve ich a user checks out only part of the project. I created a small test-project. If you simply "mvn install" it you will see the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christofer Dutz updated MNG-5358: - Attachment: TestProject-1.2-SNAPSHOT.pom Installed in D:\Maven\maven3-repo\de\volkswagen\test\TestProject\1.2-SNAPSHOT\TestProject-1.2-SNAPSHOT.pom (Path is absolutely correct) > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: module1-1.2-SNAPSHOT.pom, TestProject-1.2-SNAPSHOT.pom, > Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christofer Dutz updated MNG-5358: - Attachment: module1-1.2-SNAPSHOT.pom Installed in: D:\Maven\maven3-repo\de\volkswagen\test\module1\1.2-SNAPSHOT\module1-1.2-SNAPSHOT.pom (Path is absolutely correct) > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: module1-1.2-SNAPSHOT.pom, TestProject-1.2-SNAPSHOT.pom, > Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christofer Dutz updated MNG-5358: - Attachment: module2-1.2-SNAPSHOT.pom Installes in: D:\Maven\maven3-repo\de\volkswagen\test\module2\1.2-SNAPSHOT\module2-1.2-SNAPSHOT.pom (Path is absolutely correct) > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom, > TestProject-1.2-SNAPSHOT.pom, Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MDEP-369) fails :get using remoteRepositories and maven3
[ https://jira.codehaus.org/browse/MDEP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311507#comment-311507 ] Alexander Kudrevatykh commented on MDEP-369: problem actually was in mingw-escaping of arguments in maven 2 we have code [code]QUOTED_ARGS="" while [ "$1" != "" ] ; do QUOTED_ARGS="$QUOTED_ARGS \"$1\"" shift done[/code] but in maven 3 it code deleted, and arguments go to java unescaped > fails :get using remoteRepositories and maven3 > -- > > Key: MDEP-369 > URL: https://jira.codehaus.org/browse/MDEP-369 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: get >Affects Versions: 2.4, 2.5 > Environment: maven3.0.4 > windows7 > jdk1.7.0_01 >Reporter: Alexander Kudrevatykh > Attachments: out2.txt, out.txt > > > When I type mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:get > -DremoteRepositories=url ... plugin fails to download artifact from > remote repository. > When using repoId and repoUrl properties or maven 2.2.1 all works fine. -- 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] (MDEP-369) fails :get using remoteRepositories and maven3
[
https://jira.codehaus.org/browse/MDEP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311507#comment-311507
]
Alexander Kudrevatykh edited comment on MDEP-369 at 10/15/12 9:20 AM:
--
problem actually was in mingw-escaping of arguments
in maven 2 we have code
{code}QUOTED_ARGS=""
while [ "$1" != "" ] ; do
QUOTED_ARGS="$QUOTED_ARGS \"$1\""
shift
done{code}
but in maven 3 it code deleted, and arguments go to java unescaped
was (Author: kudrevatykh):
problem actually was in mingw-escaping of arguments
in maven 2 we have code
[code]QUOTED_ARGS=""
while [ "$1" != "" ] ; do
QUOTED_ARGS="$QUOTED_ARGS \"$1\""
shift
done[/code]
but in maven 3 it code deleted, and arguments go to java unescaped
> fails :get using remoteRepositories and maven3
> --
>
> Key: MDEP-369
> URL: https://jira.codehaus.org/browse/MDEP-369
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: get
>Affects Versions: 2.4, 2.5
> Environment: maven3.0.4
> windows7
> jdk1.7.0_01
>Reporter: Alexander Kudrevatykh
> Attachments: out2.txt, out.txt
>
>
> When I type mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:get
> -DremoteRepositories=url ... plugin fails to download artifact from
> remote repository.
> When using repoId and repoUrl properties or maven 2.2.1 all works fine.
--
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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Connolly closed MNG-5358. - Resolution: Not A Bug Property substitution is not supported at the following XPath locations /project/parent/groupId /project/parent/artifactId /project/parent/version /project/groupId /project/artifactId /project/version /project/packaging Doe in part to Maven Core currently requiring that the unresolved POM be deployed to the remote repository (or else inheritance fails) and when used as a dependency the properties supplied at original build time will not be available to the depending project. One attempt at solving this issue was to resolve the properties in the pom before installing/deploying but that broke a bunch of projects that relied on overriding properties to control the version specified in among other things. This one of the reasons why Maven 2.1.0 and 2.2.0 are not recommended for use. > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom, > TestProject-1.2-SNAPSHOT.pom, Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311510#comment-311510 ] Christofer Dutz commented on MNG-5358: -- In general it seems that property substitution in the version of a parent definition is only supported if the version property of that parent artifact is provided by the exactly identical property. I agree that in general property substitution could cause problems, but I guess if only in the parent version it was allowed, it shouldn't break much. Do you have any objections? > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom, > TestProject-1.2-SNAPSHOT.pom, Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[ https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311511#comment-311511 ] Christofer Dutz commented on MNG-5358: -- You state that resolving the parent pom would break inheritance, but not resolving it certainly breaks it the way it currently works. > Install Plugin installs poms that contain variables in artifact version and > parent version > -- > > Key: MNG-5358 > URL: https://jira.codehaus.org/browse/MNG-5358 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories, Deployment >Affects Versions: 3.0.3 >Reporter: Christofer Dutz > Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom, > TestProject-1.2-SNAPSHOT.pom, Test.zip > > > I am currently trying to create a build process that is optimized for being > able to have individual modules of one project deployed with different > versions. Therefore I created a build that uses properties for providing the > version numbers for artifacts, dependencies and parent relations. The build > is working nicely, unfortunately the install plugin installs the artifacts > into the correct directories, but it doesn't replace the properties. This way > the repo contains artifacts it can certainly not resolve ich a user checks > out only part of the project. > I created a small test-project. If you simply "mvn install" it you will see > the problematic results. -- 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] (MNG-5358) Install Plugin installs poms that contain variables in artifact version and parent version
[
https://jira.codehaus.org/browse/MNG-5358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311513#comment-311513
]
Stephen Connolly commented on MNG-5358:
---
let me rephrase.
The "quick" solution was to resolve *all* properties in the pom. That breaks
stuff.
Take for example the case where a parent pom defines a dependencyManagement,
e.g.
{code}
g
a
1
1.0
foo
manchu
${foo.version}
foo
bar
${foo.version}
{code}
If there is then a child module *that wants to use a newer version of the foo
dependencies* it can currently do like so:
{code}
g
a
1
b
1.1
foo
manchu
foo
bar
{code}
Now I am not commenting on whether the above is good practice, but there are
enough projects out there that we cannot cause the above to break, so we end up
with the "quick" solution of deploying a fully resolved pom being unworkable as
it would break backwards compatibility with existing projects.
> Install Plugin installs poms that contain variables in artifact version and
> parent version
> --
>
> Key: MNG-5358
> URL: https://jira.codehaus.org/browse/MNG-5358
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Deployment
>Affects Versions: 3.0.3
>Reporter: Christofer Dutz
> Attachments: module1-1.2-SNAPSHOT.pom, module2-1.2-SNAPSHOT.pom,
> TestProject-1.2-SNAPSHOT.pom, Test.zip
>
>
> I am currently trying to create a build process that is optimized for being
> able to have individual modules of one project deployed with different
> versions. Therefore I created a build that uses properties for providing the
> version numbers for artifacts, dependencies and parent relations. The build
> is working nicely, unfortunately the install plugin installs the artifacts
> into the correct directories, but it doesn't replace the properties. This way
> the repo contains artifacts it can certainly not resolve ich a user checks
> out only part of the project.
> I created a small test-project. If you simply "mvn install" it you will see
> the problematic results.
--
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] (MSCMPUB-2) publish-scm can fail with many files on windows.
[
https://jira.codehaus.org/browse/MSCMPUB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311517#comment-311517
]
Mark Hobson edited comment on MSCMPUB-2 at 10/15/12 11:28 AM:
--
A couple of related points:
# The temporary file is misnamed - the suffix should be ".bat" rather than
"bat" in GitAddCommand:126. This resolves the occasional 'unrecognised
command' from Windows for some reason.
# The temporary file doesn't need to further call 'cmd.exe' - it can just
contain the 'git add ...' command
# These recent changes cause the Maven SCM unit tests to fail under Windows
Looks like we still need to batch the commands in <8192 byte chunks though.
was (Author: mihobson):
A couple of related points:
1) The temporary file is misnamed - the suffix should be ".bat" rather than
"bat" in GitAddCommand:126. This resolves the occasional 'unrecognised
command' from Windows for some reason.
2) The temporary file doesn't need to further call 'cmd.exe' - it can just
contain the 'git add ...' command.
Looks like we still need to batch the commands in <8192 byte chunks though.
> publish-scm can fail with many files on windows.
>
>
> Key: MSCMPUB-2
> URL: https://jira.codehaus.org/browse/MSCMPUB-2
> Project: maven-scm-publish-plugin
> Issue Type: Bug
> Environment: Cygwin, Windows
>Reporter: Mark Hobson
>Assignee: Olivier Lamy
>
> Running publish-scm with a large site can cause the command process to fail
> due to the command line being too long. For example:
> {noformat}
> [INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X
> ---
> ...
> [INFO] Executing: cmd.exe /X /C "git add -- "
> {noformat}
> Results in:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
> (scm-publish) on project X: Failed to add new files to SCM: Exception while
> executing SCM command. Error while executing command. Error while executing
> process. Cannot run program "cmd.exe" (in directory X): CreateProcess
> error=206, The filename or extension is too long -> [Help 1]
> {noformat}
--
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] (MSCMPUB-2) publish-scm can fail with many files on windows.
[
https://jira.codehaus.org/browse/MSCMPUB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311517#comment-311517
]
Mark Hobson commented on MSCMPUB-2:
---
A couple of related points:
1) The temporary file is misnamed - the suffix should be ".bat" rather than
"bat" in GitAddCommand:126. This resolves the occasional 'unrecognised
command' from Windows for some reason.
2) The temporary file doesn't need to further call 'cmd.exe' - it can just
contain the 'git add ...' command.
Looks like we still need to batch the commands in <8192 byte chunks though.
> publish-scm can fail with many files on windows.
>
>
> Key: MSCMPUB-2
> URL: https://jira.codehaus.org/browse/MSCMPUB-2
> Project: maven-scm-publish-plugin
> Issue Type: Bug
> Environment: Cygwin, Windows
>Reporter: Mark Hobson
>Assignee: Olivier Lamy
>
> Running publish-scm with a large site can cause the command process to fail
> due to the command line being too long. For example:
> {noformat}
> [INFO] --- maven-scm-publish-plugin:1.0-beta-1:publish-scm (scm-publish) @ X
> ---
> ...
> [INFO] Executing: cmd.exe /X /C "git add -- "
> {noformat}
> Results in:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-scm-publish-plugin:1.0-beta-1:publish-scm
> (scm-publish) on project X: Failed to add new files to SCM: Exception while
> executing SCM command. Error while executing command. Error while executing
> process. Cannot run program "cmd.exe" (in directory X): CreateProcess
> error=206, The filename or extension is too long -> [Help 1]
> {noformat}
--
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] (MDEP-369) fails :get using remoteRepositories and maven3
[ https://jira.codehaus.org/browse/MDEP-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEP-369. --- Resolution: Not A Bug Assignee: Robert Scholte > fails :get using remoteRepositories and maven3 > -- > > Key: MDEP-369 > URL: https://jira.codehaus.org/browse/MDEP-369 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: get >Affects Versions: 2.4, 2.5 > Environment: maven3.0.4 > windows7 > jdk1.7.0_01 >Reporter: Alexander Kudrevatykh >Assignee: Robert Scholte > Attachments: out2.txt, out.txt > > > When I type mvn org.apache.maven.plugins:maven-dependency-plugin:2.5:get > -DremoteRepositories=url ... plugin fails to download artifact from > remote repository. > When using repoId and repoUrl properties or maven 2.2.1 all works fine. -- 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] (MSHADE-128) Too many warnings "We have duplicates"
[ https://jira.codehaus.org/browse/MSHADE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=311538#comment-311538 ] David Phillips commented on MSHADE-128: --- This isn't a duplicate of MSHADE-126, which is bug that generates false warnings. Rather, this issue is about improving the messages for legitimate warnings. Please re-open and apply the patch. This is a huge improvement! > Too many warnings "We have duplicates" > -- > > Key: MSHADE-128 > URL: https://jira.codehaus.org/browse/MSHADE-128 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.7.1 >Reporter: Raffaele >Assignee: Benson Margulies > Attachments: pom.xml, warning-we-have-duplicates.patch > > > When creating an uberjar, sometimes the same class is present in two or more > dependencies' JARs. For each class, maven-shade-plugin issues a WARNING We > have a duplicate in. > This is annoying and can muddle newcomers up (like myself), because it's not > clear how to fix. > I don't know if a programmatic solution to these warnings could exist: maybe > it will always require human interaction. However, it's better to point users > in the right direction and not spit out thousands of useless warnings. > Attached is a pom which triggers thousands of warnings and a patch with a > prettier (and hopefully more useful) output like > [WARNING] bcprov-jdk14-138.jar, bcprov-jdk14-1.38.jar define 1292 > overlappping classes: > [WARNING] - org.bouncycastle.asn1.ocsp.ResponderID > [WARNING] - org.bouncycastle.crypto.params.DSAPublicKeyParameters > [WARNING] - org.bouncycastle.crypto.engines.DESEngine > [WARNING] - org.bouncycastle.jce.provider.JCEElGamalPrivateKey > [WARNING] - org.bouncycastle.jce.provider.JCEStreamCipher$Skipjack_CFB8 > [WARNING] - org.bouncycastle.jce.provider.JCESecretKeyFactory > [WARNING] - org.bouncycastle.i18n.filter.UntrustedInput > [WARNING] - org.bouncycastle.asn1.x9.X962NamedCurves$5 > [WARNING] - org.bouncycastle.jce.X509KeyUsage > [WARNING] maven-shade-plugin has detected that some .class files > [WARNING] are present in two or more JARs. When this happens, only > [WARNING] one single version of the class is copied in the uberjar. > [WARNING] Usually this is not harmful and you can skeep these > [WARNING] warnings, otherwise try to manually exclude artifacts > [WARNING] based on mvn dependency:tree -Ddetail=true and the above > [WARNING] output > [WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin -- 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] (MSHADE-128) Too many warnings "We have duplicates"
[ https://jira.codehaus.org/browse/MSHADE-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies reopened MSHADE-128: - > Too many warnings "We have duplicates" > -- > > Key: MSHADE-128 > URL: https://jira.codehaus.org/browse/MSHADE-128 > Project: Maven 2.x Shade Plugin > Issue Type: Improvement >Affects Versions: 1.7.1 >Reporter: Raffaele >Assignee: Benson Margulies > Attachments: pom.xml, warning-we-have-duplicates.patch > > > When creating an uberjar, sometimes the same class is present in two or more > dependencies' JARs. For each class, maven-shade-plugin issues a WARNING We > have a duplicate in. > This is annoying and can muddle newcomers up (like myself), because it's not > clear how to fix. > I don't know if a programmatic solution to these warnings could exist: maybe > it will always require human interaction. However, it's better to point users > in the right direction and not spit out thousands of useless warnings. > Attached is a pom which triggers thousands of warnings and a patch with a > prettier (and hopefully more useful) output like > [WARNING] bcprov-jdk14-138.jar, bcprov-jdk14-1.38.jar define 1292 > overlappping classes: > [WARNING] - org.bouncycastle.asn1.ocsp.ResponderID > [WARNING] - org.bouncycastle.crypto.params.DSAPublicKeyParameters > [WARNING] - org.bouncycastle.crypto.engines.DESEngine > [WARNING] - org.bouncycastle.jce.provider.JCEElGamalPrivateKey > [WARNING] - org.bouncycastle.jce.provider.JCEStreamCipher$Skipjack_CFB8 > [WARNING] - org.bouncycastle.jce.provider.JCESecretKeyFactory > [WARNING] - org.bouncycastle.i18n.filter.UntrustedInput > [WARNING] - org.bouncycastle.asn1.x9.X962NamedCurves$5 > [WARNING] - org.bouncycastle.jce.X509KeyUsage > [WARNING] maven-shade-plugin has detected that some .class files > [WARNING] are present in two or more JARs. When this happens, only > [WARNING] one single version of the class is copied in the uberjar. > [WARNING] Usually this is not harmful and you can skeep these > [WARNING] warnings, otherwise try to manually exclude artifacts > [WARNING] based on mvn dependency:tree -Ddetail=true and the above > [WARNING] output > [WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin -- 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
