[jira] (MASSEMBLY-584) Assembly Plugin is looking for SNAPSHOT artifacts in release repositories
[
https://jira.codehaus.org/browse/MASSEMBLY-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361935#comment-361935
]
Alfonso Nishikawa commented on MASSEMBLY-584:
-
I just want to comment this happens to me too, but in a weird way:
* Maven 3.0.4 + assembly 2.4 => ok
* Maven 3.1.1 + assembly 2.4 => error
Based on comments above, in my case the solution was change two repositories
(snapshot + release) pointing to the same url. The artifactory I use have a
virtual repository with near the same content, so changing one of them
(snapshot or release) fixed the problem for Maven 3.1.1 + assembly 2.4.
> Assembly Plugin is looking for SNAPSHOT artifacts in release repositories
> -
>
> Key: MASSEMBLY-584
> URL: https://jira.codehaus.org/browse/MASSEMBLY-584
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Windows 7, java 1.6.0_29, Maven 3.0.3
>Reporter: Donatas Ciuksys
>Priority: Blocker
>
> Assembly plugin fails to retrieve snapshot with unique version from
> repository, and as a result the generated zip file contains
> signatures-xades-1.2-SNAPSHOT.jar instead of
> signatures-xades-1.2-2021.181823-3.jar.
> Descriptor:
> {code}
>
> bin
>
> zip
>
> false
>
>
> lib/
> false
>
>
> /
> true
>
> ${project.groupId}:${project.artifactId}
>
>
>
>
> {code}
> Maven debug output (-X) contains:
> {quote}
> [DEBUG] Resolving project dependencies transitively.
> [DEBUG] lt.mitsoft.vmi:eds3-batch:war:1.0-SNAPSHOT (selected for null)
> [DEBUG] lt.mitsoft.vmi:eds3-mdoc:jar:1.0-SNAPSHOT:compile (selected for
> compile)
> [DEBUG] lt.mitsoft.adoc:adoc-core:jar:1.1:compile (selected for compile)
> ...
> [DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.1:compile
> (selected for compile)
> ...
> [DEBUG] Verifying availability of
> C:\Users\Donatas\.m2\repository\lt\mitsoft\pki\signatures\signatures-xades\1.2-SNAPSHOT\signatures-xades-1.2-2021.181823-3.pom
> from [central (https://int.mitsoft.lt:3681/artifactory/repo, releases),
> google (http://mbari-maven-repository.googlecode.com/svn/repository/,
> releases), org.tmatesoft.svnkit-releases
> (http://maven.tmatesoft.com/content/repositories/releases/, releases)]
> [WARNING] Missing POM for
> lt.mitsoft.pki.signatures:signatures-xades:jar:1.2-SNAPSHOT: Error resolving
> project artifact: Could not find artifact
> lt.mitsoft.pki.signatures:signatures-xades:pom:1.2-2021.181823-3 for
> project lt.mitsoft.pki.signatures:signatures-xades:pom:1.2-SNAPSHOT
> [DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.1:compile (removed
> - nearer found: 1.2-SNAPSHOT)
> [DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.2-SNAPSHOT:compile
> (selected for compile)
> ...
> {quote}
> The problem is that artifact signatures-xades-1.2-2021.181823-3.pom (that
> is, signatures-xades-1.2-SNAPSHOT) is being looked-up in *release*
> repositories (as shown above):
> {code}
> [central (https://int.mitsoft.lt:3681/artifactory/repo, releases),
> google (http://mbari-maven-repository.googlecode.com/svn/repository/,
> releases),
> org.tmatesoft.svnkit-releases
> (http://maven.tmatesoft.com/content/repositories/releases/, releases)]
> {code}
> The culprit might be the dependency override:
> {code}
> [DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.1:compile (removed
> - nearer found: 1.2-SNAPSHOT)
> [DEBUG] lt.mitsoft.pki.signatures:signatures-xades:jar:1.2-SNAPSHOT:compile
> (selected for compile)
> {code}
> The first candidate was signatures-xades:jar:1.1 (release), but the chosen
> artifact is signatures-xades:jar:1.2-SNAPSHOT. I guess the repository type
> was chosen based on the first candidate, and this is wrong.
> *Even bigger problem is that since POM retrieval failed, all dependencies
> specified in signatures-xades-1.2-2021.181823-3.pom were not being taken
> into account (and are absent in generated zip file).*
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-469) analyze-report java.io.FileNotFoundException:
[
https://jira.codehaus.org/browse/MDEP-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361936#comment-361936
]
Stephan Schroevers commented on MDEP-469:
-
Just upgraded to version 2.10, and I can no longer reproduce the issue. So I
suspect this ticket can be closed as _Fixed_.
> analyze-report java.io.FileNotFoundException:
> -
>
> Key: MDEP-469
> URL: https://jira.codehaus.org/browse/MDEP-469
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: jieryn
>
> Apache Maven 3.2.3, multi-module project,
> maven-dependency-plugin:analyze-report:2.9 throws FileNotFoundException
> during site phase (same exact project and configuration but with 2.8 is
> successful):
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> dao: Error generating maven-dependency-plugin:2.9:analyze-report: Cannot
> analyze dependencies:
> /var/lib/jenkins/jobs/site_com.acme.proj/workspace/domain/target/classes (Is
> a directory) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
> project dao: Error generating maven-dependency-plugin:2.9:analyze-report:
> Cannot analyze dependencies
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 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:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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: org.apache.maven.plugin.MojoExecutionException: Error generating
> maven-dependency-plugin:2.9:analyze-report: Cannot analyze dependencies
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:146)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> generating maven-dependency-plugin:2.9:analyze-report: Cannot analyze
> dependencies
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:239)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:182)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141)
> ... 21 more
> Caused by: org.apache.maven.reporting.MavenReportException: Cannot analyze
> dependencies
> at
> org.apache.maven.plugin.dependency.analyze.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:145)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:196)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:224)
> ... 25 more
> Caused by:
> org.apache.maven.shared.dependency.analyzer.ProjectDepend
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361964#comment-361964
]
Michael Osipov commented on MPIR-251:
-
Version 2.8 has been released recently, can you retry?
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Labels: close-pending
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1139) TestNG parameters cannot be overridden when suite is used
[ https://jira.codehaus.org/browse/SUREFIRE-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Kozak updated SUREFIRE-1139: -- Summary: TestNG parameters cannot be overridden when suite is used (was: TestNG cannot be overridden when suite is uses) > TestNG parameters cannot be overridden when suite is used > - > > Key: SUREFIRE-1139 > URL: https://jira.codehaus.org/browse/SUREFIRE-1139 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 2.18 >Reporter: Piotr Kozak >Priority: Minor > > I try to override TestNG parameteres used in suite file testng.xml with > failsafe configuration . Analogous functionality > when testng.xml is triggered from Intellij Idea via TestNG runner works. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1139) TestNG cannot be overridden when suite is uses
Piotr Kozak created SUREFIRE-1139: - Summary: TestNG cannot be overridden when suite is uses Key: SUREFIRE-1139 URL: https://jira.codehaus.org/browse/SUREFIRE-1139 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 2.18 Reporter: Piotr Kozak Priority: Minor I try to override TestNG parameteres used in suite file testng.xml with failsafe configuration . Analogous functionality when testng.xml is triggered from Intellij Idea via TestNG runner works. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-469) analyze-report java.io.FileNotFoundException:
[
https://jira.codehaus.org/browse/MDEP-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MDEP-469.
Resolution: Fixed
Fix Version/s: 2.10
Assignee: Karl-Heinz Marbaise
Cool thanks for the feedback.
So i will close the issue.
If you discover something different than don't hesitate to reopen ticket.
> analyze-report java.io.FileNotFoundException:
> -
>
> Key: MDEP-469
> URL: https://jira.codehaus.org/browse/MDEP-469
> Project: Maven Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: jieryn
>Assignee: Karl-Heinz Marbaise
> Fix For: 2.10
>
>
> Apache Maven 3.2.3, multi-module project,
> maven-dependency-plugin:analyze-report:2.9 throws FileNotFoundException
> during site phase (same exact project and configuration but with 2.8 is
> successful):
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project
> dao: Error generating maven-dependency-plugin:2.9:analyze-report: Cannot
> analyze dependencies:
> /var/lib/jenkins/jobs/site_com.acme.proj/workspace/domain/target/classes (Is
> a directory) -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
> project dao: Error generating maven-dependency-plugin:2.9:analyze-report:
> Cannot analyze dependencies
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
> 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:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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: org.apache.maven.plugin.MojoExecutionException: Error generating
> maven-dependency-plugin:2.9:analyze-report: Cannot analyze dependencies
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:146)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> ... 19 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> generating maven-dependency-plugin:2.9:analyze-report: Cannot analyze
> dependencies
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:239)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:311)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:129)
> at
> org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.java:182)
> at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141)
> ... 21 more
> Caused by: org.apache.maven.reporting.MavenReportException: Cannot analyze
> dependencies
> at
> org.apache.maven.plugin.dependency.analyze.AnalyzeReportMojo.executeReport(AnalyzeReportMojo.java:145)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:196)
> at
> org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocument(ReportDoc
[jira] (SUREFIRE-1139) TestNG parameters cannot be overridden when suite is used
[ https://jira.codehaus.org/browse/SUREFIRE-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361969#comment-361969 ] Andreas Gudian commented on SUREFIRE-1139: -- Hi Piotr, please provide a small self-contained sample project to demonstrate the issue. Thanks! > TestNG parameters cannot be overridden when suite is used > - > > Key: SUREFIRE-1139 > URL: https://jira.codehaus.org/browse/SUREFIRE-1139 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 2.18 >Reporter: Piotr Kozak >Priority: Minor > > I try to override TestNG parameteres used in suite file testng.xml with > failsafe configuration . Analogous functionality > when testng.xml is triggered from Intellij Idea via TestNG runner works. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361973#comment-361973
]
Dan Armbrust commented on MPIR-251:
---
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
skin.
[INFO] Generating "About" report---
maven-project-info-reports-plugin:2.8:index
[INFO] Generating "Project License" report ---
maven-project-info-reports-plugin:2.8:license
[INFO] Generating "Dependencies" report ---
maven-project-info-reports-plugin:2.8:dependencies
[ERROR] Artifact: org.apache.felix:org.osgi.core:jar:1.4.0 has no file.
[ERROR] Artifact: org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0
has no file.
[ERROR] Artifact: org.apache.httpcomponents:httpclient:jar:4.1.3 has no file.
[ERROR] Artifact: org.apache.httpcomponents:httpcore:jar:4.1.4 has no file.
[ERROR] Artifact: org.apache.lucene:lucene-analyzers-common:jar:4.3.1 has no
file.
[ERROR] Artifact: org.apache.lucene:lucene-core:jar:4.3.1 has no file.
[ERROR] Artifact: org.apache.lucene:lucene-queries:jar:4.3.1 has no file.
[ERROR] Artifact: org.apache.lucene:lucene-queryparser:jar:4.3.1 has no file.
[ERROR] Artifact: org.apache.lucene:lucene-sandbox:jar:4.3.1 has no file.
[ERROR] Artifact: org.apache.mahout:mahout-collections:jar:1.0 has no file.
[ERROR] Artifact: org.apache.mahout:mahout-math:jar:0.7 has no file.
It only happens for some of my sub-projects - so I suspect it only happens when
the dependency chain includes some jar file that is broken in a way that sets
off this chain of (harmless?) errors.
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Labels: close-pending
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2305) only first active proxy considered/used
[
https://jira.codehaus.org/browse/MNG-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353558#comment-353558
]
Gordon Pettey edited comment on MNG-2305 at 1/28/15 2:11 PM:
-
Either there has been regression out this was closed erroneously. This behavior
is still exhibited in maven 3.2.3 - 3.2.5.
When a single http proxy is configured in settings, access
to HTTPS URLs (e.g.
https://commons.apache.org/proper/commons-collections/javadocs/api-release/)
fails. If the proxy in settings.xml is set false, and I specify
-Dhttp.proxy{Host,Post,User,Password} on the mvn command line, everything works
fine. mvn -X claims to be passing only -J-Dhttp.proxy options to javadoc.exe
via command line, but https.proxy properties are clearly being set somehow when
they shouldn't be.
was (Author: petteyg):
Either there has been regression out this was closed erroneously. This behavior
is still exhibited in maven 3.2.3.
> only first active proxy considered/used
> ---
>
> Key: MNG-2305
> URL: https://jira.codehaus.org/browse/MNG-2305
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.4, 2.1.0-M1
> Environment: WIN2K JDK 1.5.0_06
> proxy:81 for both http and https
>Reporter: Franz Fehringer
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
> Attachments: settings.xml
>
>
> With the attached settings.xml
> all https connects fail (doing mvn -U).
> If i reverse the order (https first http second) all http connects fail.
> Questions:
> Does https tunneling over http proxies work at all with Maven2 (sending HTTP
> CONNECT to the proxy is needed)?
> Why is the Java system configuration (in Application
> Data\Sun\Java\Deployment\deployment.properties) not used to detect proxies?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2305) only first active proxy considered/used
[
https://jira.codehaus.org/browse/MNG-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=353558#comment-353558
]
Gordon Pettey edited comment on MNG-2305 at 1/28/15 2:14 PM:
-
Either there has been regression or this was closed erroneously. This behavior
is still exhibited in maven 3.2.3 - 3.2.5.
When a single http proxy is configured in settings, access
to HTTPS URLs (e.g.
https://commons.apache.org/proper/commons-collections/javadocs/api-release/)
fails. If the proxy in settings.xml is set false, and I specify
-Dhttp.proxy{Host,Post,User,Password} on the mvn command line, everything works
fine. mvn -X claims to be passing only -J-Dhttp.proxy options to javadoc.exe
via command line, but https.proxy properties are clearly being set somehow when
they shouldn't be.
was (Author: petteyg):
Either there has been regression out this was closed erroneously. This behavior
is still exhibited in maven 3.2.3 - 3.2.5.
When a single http proxy is configured in settings, access
to HTTPS URLs (e.g.
https://commons.apache.org/proper/commons-collections/javadocs/api-release/)
fails. If the proxy in settings.xml is set false, and I specify
-Dhttp.proxy{Host,Post,User,Password} on the mvn command line, everything works
fine. mvn -X claims to be passing only -J-Dhttp.proxy options to javadoc.exe
via command line, but https.proxy properties are clearly being set somehow when
they shouldn't be.
> only first active proxy considered/used
> ---
>
> Key: MNG-2305
> URL: https://jira.codehaus.org/browse/MNG-2305
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.4, 2.1.0-M1
> Environment: WIN2K JDK 1.5.0_06
> proxy:81 for both http and https
>Reporter: Franz Fehringer
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
> Attachments: settings.xml
>
>
> With the attached settings.xml
> all https connects fail (doing mvn -U).
> If i reverse the order (https first http second) all http connects fail.
> Questions:
> Does https tunneling over http proxies work at all with Maven2 (sending HTTP
> CONNECT to the proxy is needed)?
> Why is the Java system configuration (in Application
> Data\Sun\Java\Deployment\deployment.properties) not used to detect proxies?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-2305) only first active proxy considered/used
[
https://jira.codehaus.org/browse/MNG-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Pettey updated MNG-2305:
---
Comment: was deleted
(was: Either there has been regression or this was closed erroneously. This
behavior is still exhibited in maven 3.2.3 - 3.2.5.
When a single http proxy is configured in settings, access
to HTTPS URLs (e.g.
https://commons.apache.org/proper/commons-collections/javadocs/api-release/)
fails. If the proxy in settings.xml is set false, and I specify
-Dhttp.proxy{Host,Post,User,Password} on the mvn command line, everything works
fine. mvn -X claims to be passing only -J-Dhttp.proxy options to javadoc.exe
via command line, but https.proxy properties are clearly being set somehow when
they shouldn't be.)
> only first active proxy considered/used
> ---
>
> Key: MNG-2305
> URL: https://jira.codehaus.org/browse/MNG-2305
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.4, 2.1.0-M1
> Environment: WIN2K JDK 1.5.0_06
> proxy:81 for both http and https
>Reporter: Franz Fehringer
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
> Attachments: settings.xml
>
>
> With the attached settings.xml
> all https connects fail (doing mvn -U).
> If i reverse the order (https first http second) all http connects fail.
> Questions:
> Does https tunneling over http proxies work at all with Maven2 (sending HTTP
> CONNECT to the proxy is needed)?
> Why is the Java system configuration (in Application
> Data\Sun\Java\Deployment\deployment.properties) not used to detect proxies?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361978#comment-361978
]
Dawid Weiss commented on MASSEMBLY-742:
---
I will provide a patch that provides a quick fix for the logged message
(doesn't solve the problem, but removes the annoyance).
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361977#comment-361977
]
Dawid Weiss edited comment on MASSEMBLY-742 at 1/28/15 3:15 PM:
That was my fix too, but it won't work (and you should revert
33f92e0693c659a278ee9eab15e).
Now you close the iterator (which closes the underlying ZipFile) but publish
this iterator entries (which hold references to that ZipFile). This results in
attempts to reference a closed resource.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.4-SNAPSHOT:single
(private-zip) on project child
2: Failed to create assembly: Error creating assembly archive private: Problem
creating zip: Execution exception (and the archive
is probably corrupt but I could not delete it): Stream Closed -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.
4-SNAPSHOT:single (private-zip) on project child2: Failed to create assembly:
Error creating assembly archive private: Problem cre
ating zip: Execution exception (and the archive is probably corrupt but I could
not delete it)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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:601)
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: org.apache.maven.plugin.MojoExecutionException: Failed to create
assembly: Error creating assembly archive private: Pro
blem creating zip: Execution exception (and the archive is probably corrupt but
I could not delete it)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:541)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException:
Error creating assembly archive private: Problem cre
ating zip: Execution exception (and the archive is probably corrupt but I could
not delete it)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:185)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
... 21 more
Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating
zip: Execution exception (and the archive is probably
corrupt but I could not delete it)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:994)
at
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:436)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
... 22 more
Caused by: java.io.IOException: Execution exception
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.close(AbstractZipArchiver.java:790)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:981)
... 24 more
Caused by: java.io.IOException: Stream Closed
at java.io
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361977#comment-361977
]
Dawid Weiss commented on MASSEMBLY-742:
---
That was my fix too, but it won't work (and you should revert ).
Now you close the iterator (which closes the underlying ZipFile) but publish
this iterator entries (which hold references to that ZipFile). This results in
attempts to reference a closed resource.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.4-SNAPSHOT:single
(private-zip) on project child
2: Failed to create assembly: Error creating assembly archive private: Problem
creating zip: Execution exception (and the archive
is probably corrupt but I could not delete it): Stream Closed -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.5.
4-SNAPSHOT:single (private-zip) on project child2: Failed to create assembly:
Error creating assembly archive private: Problem cre
ating zip: Execution exception (and the archive is probably corrupt but I could
not delete it)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216)
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:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
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:601)
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: org.apache.maven.plugin.MojoExecutionException: Failed to create
assembly: Error creating assembly archive private: Pro
blem creating zip: Execution exception (and the archive is probably corrupt but
I could not delete it)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:541)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.apache.maven.plugin.assembly.archive.ArchiveCreationException:
Error creating assembly archive private: Problem cre
ating zip: Execution exception (and the archive is probably corrupt but I could
not delete it)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:185)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:484)
... 21 more
Caused by: org.codehaus.plexus.archiver.ArchiverException: Problem creating
zip: Execution exception (and the archive is probably
corrupt but I could not delete it)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:994)
at
org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:436)
at
org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
... 22 more
Caused by: java.io.IOException: Execution exception
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.close(AbstractZipArchiver.java:790)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:981)
... 24 more
Caused by: java.io.IOException: Stream Closed
at java.io.RandomAccessFile.seek(Native Method)
at
org.codehaus.plexus.archive
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss updated MASSEMBLY-742:
--
Attachment: MASSEMBLY-742.patch
This puts some lipstick on this pig by removing the problematic warning and
making no side-effects to the existing code (I reverted 33f92e0693c65).
With this patch everything is fine and dandy (on the surface). I would create a
new issue to actually try to rethink the architecture because I too don't see
how it can be cleanly solved. My impression is that instead of making iterators
closeable the entries themselves should be somehow "disposable". Once this is
in place (and respected) a zip iterator entry would keep a reference counter
to its origin ZipFile, closing it when the ref. counter reaches zero.
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip, MASSEMBLY-742.patch
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MASSEMBLY-742) Unclosed ZipFile warnings when ZIP archives are included
[
https://jira.codehaus.org/browse/MASSEMBLY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361980#comment-361980
]
Dawid Weiss commented on MASSEMBLY-742:
---
Oh, since I know the code of finalize in ZipFile I didn't include
super.finalize(), but for absolute clarity the override should read:
{code}
try {
super.close();
} finally {
super.finalize();
}
{code}
> Unclosed ZipFile warnings when ZIP archives are included
>
>
> Key: MASSEMBLY-742
> URL: https://jira.codehaus.org/browse/MASSEMBLY-742
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.5.2
>Reporter: Dawid Weiss
>Assignee: Kristian Rosenvold
>Priority: Minor
> Fix For: 2.5.3, 2.5.4
>
> Attachments: example.zip, MASSEMBLY-742.patch
>
>
> I get the following warnings at the end of Maven build:
> {code}
> Cleaning up unclosed ZipFile for archive C:\...foo-0.2.0-SNAPSHOT.zip
> {code}
> These warnings originate from assembly plugin, but in fact they're caused by
> the fact that plexus resource abstraction opens up a ZipFile from
> commons-compress, but never closes it. Commons-compress then force-closes all
> such objects in finalize, emitting a warning.
> I created a synthetic capture of the allocation stack in maven assembly, it's
> here:
> {code}
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:211)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:193)
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:154)
> org.codehaus.plexus.archiver.zip.PlexusIoZipFileResourceCollection.getEntries(PlexusIoZipFileResourceCollection.java:29)
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:69)
> org.codehaus.plexus.components.io.resources.proxy.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:111)
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:493)
> org.codehaus.plexus.archiver.dir.DirectoryArchiver.execute(DirectoryArchiver.java:71)
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:940)
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:541)
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:180)
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:486)
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> java.lang.reflect.Method.invoke(Method.java:483)
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> Hope this helps, somehow.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361982#comment-361982
]
Benson Margulies commented on MCOMPILER-120:
The problem here is
{code}
true
{code}
If this is present, the warnings disappear with -Werror.
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-120) Javac compiler plugin doesn't support -Werror
[
https://jira.codehaus.org/browse/MCOMPILER-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361982#comment-361982
]
Benson Margulies edited comment on MCOMPILER-120 at 1/28/15 4:08 PM:
-
The problem here is
{code}
true
{code}
If this is present, the warnings disappear with -Werror.
was (Author: bmargulies):
The problem here is
{code}
true
{code}
If this is present, the warnings disappear with -Werror.
> Javac compiler plugin doesn't support -Werror
> -
>
> Key: MCOMPILER-120
> URL: https://jira.codehaus.org/browse/MCOMPILER-120
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Christopher Webster
>Assignee: Kristian Rosenvold
> Fix For: 2.4
>
> Attachments: JavacCompiler.java, JavacCompiler.patch,
> trial-maven.zip, werror.zip
>
>
> If I write a pom file like the following:
> {code:xml}...
>
> org.apache.maven.plugins
> maven-compiler-plugin
> 2.1
>
> javac
> 1.6
> 1.6
>
>
>
>
>
> true
>
> {code}
> and if there are only warnings, then the build will not fail as intended by
> the compiler Argument. The reason is that in compileInProcess the exit code
> from javac is only considered if there are no messages. In the case of
> treating warnings as errors, there will be messages but no errors so the
> intention of the build failure is lost.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361983#comment-361983
]
Herve Boutemy commented on MPIR-251:
can you try to run with debug trace and attach log file, please?
perhaps there will be some information on what's causing the mysterious failure
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Labels: close-pending
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361988#comment-361988
]
Scott Carey commented on MNG-5686:
--
excellent. Any idea how far out 3.2.6 is ? :)
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
>Assignee: Mirko Friedenhagen
> Fix For: 3.2.6
>
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5686) mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
[
https://jira.codehaus.org/browse/MNG-5686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361992#comment-361992
]
Jason van Zyl commented on MNG-5686:
Two weeks or less.
> mvn cannot execute /usr/libexec/java_home/bin/java on OS X.
> ---
>
> Key: MNG-5686
> URL: https://jira.codehaus.org/browse/MNG-5686
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.2.3
> Environment: Mac OS X 10.9.4
>Reporter: Takayoshi Fujiki
>Assignee: Mirko Friedenhagen
> Fix For: 3.2.6
>
> Attachments: 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.patch,
> 0001-Fix-whitespace-bashisms-in-mvn-shell-scripts.v2.patch,
> 0002-MNG-5686-detect-JAVA_HOME-on-newer-OSX-again.patch, maven-bin-mvn.patch
>
>
> From 3.2.3, mvn cannot start and outputs the following error.
> {code}
> $ ./apache-maven-3.2.3/bin/mvn -version
> Error: JAVA_HOME is not defined correctly.
> We cannot execute /usr/libexec/java_home/bin/java
> {code}
> 3.2.2 doesn't have this problem.
> {code}
> $ ./apache-maven-3.2.2/bin/mvn -version
> Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e;
> 2014-06-17T22:51:42+09:00)
> Maven home: /Users/xxx/tmp/apache-maven-3.2.2
> Java version: 1.8.0_11, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_11.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac"
> {code}
> When I modified {{bin/mvn}} like the following, this problem was gone.
> {code}
> --- bin/mvn.orig 2014-09-10 03:33:52.0 +0900
> +++ bin/mvn 2014-09-10 03:34:18.0 +0900
> @@ -83,7 +83,7 @@
> #
> # Apple JDKs
> #
> - export JAVA_HOME=/usr/libexec/java_home
> + export JAVA_HOME="`/usr/libexec/java_home`"
> fi
> ;;
> esac
> {code}
> Maybe MNG-5658 is related to this problem. {{/usr/libexec/java_home}} is a
> command([java_home(1)|https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man1/java_home.1.html]),
> and {{$(command)}} is a style of [Command
> Substitution|http://www.tldp.org/LDP/abs/html/commandsub.html] (Another(old)
> style is {{`command`}}).
> So removing "$()" breaks the JAVA_HOME detection on OS X.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-223) No need to setup M2_HOME environment at http://maven.apache.org/download.cgi
[ https://jira.codehaus.org/browse/MNGSITE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361993#comment-361993 ] Dan Tran commented on MNGSITE-223: -- detailed discussions are at http://maven.40175.n5.nabble.com/Remove-M2-HOME-setup-from-download-page-instructions-td5824846.html > No need to setup M2_HOME environment at http://maven.apache.org/download.cgi > > > Key: MNGSITE-223 > URL: https://jira.codehaus.org/browse/MNGSITE-223 > Project: Maven Project Web Site > Issue Type: Task >Reporter: Dan Tran > > Starting with Maven 2.1 M2_HOME is self-discover at bin/mvn script. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=361994#comment-361994
]
Dan Armbrust commented on MPIR-251:
---
Hmm, log file is huge... but I don't see anything of interest.
It goes straight into the errors with no extra info - I've cut a few pieces of
surrounding log:
[INFO] <<< jdepend-maven-plugin:2.0:generate < compile @ app <<<
[DEBUG] building maven31 dependency graph for
gov.va.isaac.isaac-pa.modules:app:pom:Sprint_18-SNAPSHOT with
Maven31DependencyGraphBuilder
[DEBUG] Using mirror maestro
(https://va.maestrodev.com/archiva/repository/all/) for central
(https://repo.maven.apache.org/maven2).
...
[DEBUG] Dependency collection stats: {ConflictMarker.analyzeTime=0,
ConflictMarker.markTime=0, ConflictMarker.nodeCount=670,
ConflictIdSorter.graphTime=1, ConflictIdSorter.topsortTime=0,
ConflictIdSorter.conflictIdCount=203, ConflictIdSorter.conflictIdCycleCount=0,
ConflictResolver.totalTime=4, ConflictResolver.conflictItemCount=500,
DefaultDependencyCollector.collectTime=24,
DefaultDependencyCollector.transformTime=5}
[DEBUG] gov.va.isaac.isaac-pa.modules:app:pom:Sprint_18-SNAPSHOT
[DEBUG]gov.va.isaac.isaac-pa.modules:config:jar:Sprint_18-SNAPSHOT:compile
[DEBUG]gov.va.isaac.modules:isaac-app:jar:Sprint_18-SNAPSHOT:compile
[DEBUG] gov.va.isaac.modules:otf-util:jar:Sprint_18-SNAPSHOT:compile
[DEBUG]
gov.va.isaac.modules:isaac-constants:jar:Sprint_18-SNAPSHOT:compile
[DEBUG] ch.qos.logback:logback-classic:jar:1.1.2:compile
[DEBUG] ch.qos.logback:logback-core:jar:1.1.2:compile
[DEBUG] org.slf4j:jul-to-slf4j:jar:1.7.7:compile
[DEBUG] org.slf4j:log4j-over-slf4j:jar:1.7.7:compile
[DEBUG] net.lingala.zip4j:zip4j:jar:1.3.2:compile
[DEBUG] org.glassfish.hk2:hk2:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2:hk2-utils:jar:2.3.0:compile
[DEBUG] javax.inject:javax.inject:jar:1:compile
[DEBUG] org.glassfish.hk2:hk2-api:jar:2.3.0:compile
[DEBUG]
org.glassfish.hk2.external:aopalliance-repackaged:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2:config-types:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2:core:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2:hk2-config:jar:2.3.0:compile
[DEBUG] org.jvnet:tiger-types:jar:1.4:compile
[DEBUG] org.glassfish.hk2.external:bean-validator:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2:hk2-locator:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2.external:javax.inject:jar:2.3.0:compile
[DEBUG] org.javassist:javassist:jar:3.18.1-GA:compile
[DEBUG] org.glassfish.hk2:hk2-runlevel:jar:2.3.0:compile
[DEBUG] org.glassfish.hk2:class-model:jar:2.3.0:compile
[DEBUG]
org.glassfish.hk2.external:asm-all-repackaged:jar:2.3.0:compile
[DEBUG] org.slf4j:slf4j-api:jar:1.7.7:compile
[DEBUG]gov.va.isaac.modules:import-export:jar:Sprint_18-SNAPSHOT:compile
[DEBUG] gov.va.isaac.modules:gui-util:jar:Sprint_18-SNAPSHOT:compile
[DEBUG] org.apache.commons:commons-lang3:jar:3.3:compile
[DEBUG] gov.va.isaac.modules:data-model:jar:Sprint_18-SNAPSHOT:compile
[DEBUG] org.ihtsdo.otf:tcc-datastore:jar:1.1-va-1.11-SNAPSHOT:compile
[DEBUG] com.sleepycat:je:jar:5.0.97:compile
[DEBUG] org.apache.mahout:mahout-collections:jar:1.0:compile
[DEBUG] org.apache.mahout:mahout-math:jar:0.7:compile
[DEBUG] org.apache.commons:commons-math:jar:2.2:compile
[DEBUG] org.uncommons.maths:uncommons-maths:jar:1.2.2:compile
[DEBUG]jfree:jcommon:jar:1.0.12:compile
[DEBUG] com.google.guava:guava:jar:r09:compile
[DEBUG] commons-lang:commons-lang:jar:2.6:compile
[DEBUG] org.ihtsdo.otf:tcc-model-impl:jar:1.1-va-1.11-SNAPSHOT:compile
[DEBUG] org.ihtsdo.otf:tcc-lookup:jar:1.1-va-1.11-SNAPSHOT:compile
[DEBUG]
org.netbeans.api:org-openide-util-lookup:jar:RELEASE73:compile
[DEBUG] org.apache.lucene:lucene-core:jar:4.3.1:compile
[DEBUG] org.eclipse.uml2.uml:resources:jar:4.1.0-v20130902-0826:compile
[DEBUG] org.eclipse.uml2:uml:jar:4.1.2-v20140202-2055:compile
[DEBUG] org.eclipse.uml2:common:jar:1.8.2-v20140202-2055:compile
[DEBUG] org.eclipse.uml2:types:jar:1.1.0-v20140202-2055:compile
[DEBUG]
org.eclipse.uml2.uml.profile:l2:jar:1.1.0-v20140202-2055:compile
[DEBUG]
org.eclipse.uml2.uml.profile:l3:jar:1.1.0-v20140202-2055:compile
[DEBUG] org.eclipse.core:runtime:jar:3.10.0-v20140318-2214:compile
[DEBUG] org.eclipse:osgi:jar:3.10.0-v20140606-1445:compile
[DEBUG] org.eclipse.core:jobs:jar:3.6.0-v20140424-0053:compile
[DEBUG]
org.eclipse.equinox:preferences:jar:3.5.200-v20140224-1527:compile
[DEBUG]
org.eclipse.core:contenttype:jar:3.4.200-
