[jira] Reopened: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ http://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seidel reopened MJAVADOC-171: And added it again in 2.5 Here are the number of xmlbeans occurences by version: 2.2: 5 2.3: 20 2.4: 0 2.5: 26 2.6.1: 26 2.6: 26 2.7: 26 AFAICS, only 2.2 behaved correctly. > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: http://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Priority: Critical > Fix For: 2.4 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-229) war:inplace overwrite files of current project by those coming from overlay war
[
http://jira.codehaus.org/browse/MWAR-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229602#action_229602
]
Julien HENRY commented on MWAR-229:
---
@Dennis : look at the IT. There is NO plugin configuration (relying on default
behaviour).
In my real project, here is what I have in my corporate parent pom:
{code}
...
org.apache.maven.plugins
maven-war-plugin
2.1-beta-1
...
{code}
@Stephane : I tried to understand the code of the plugin and it seems most of
the code is common between goal inplace and goal exploded. With exploded goal,
the target folder where the webapp will be assembled (target/artifactId-XX) is
initially empty but with inplace goal, the target folder (src/main/webapp)
already contains the files of the current artifact. So I think the overlay
algorithm should be different in the two cases.
> war:inplace overwrite files of current project by those coming from overlay
> war
> ---
>
> Key: MWAR-229
> URL: http://jira.codehaus.org/browse/MWAR-229
> Project: Maven 2.x WAR Plugin
> Issue Type: Bug
>Affects Versions: 2.1-beta-1
>Reporter: Julien HENRY
> Attachments: MWAR-229-it.patch
>
>
> I have a web application that depends on another WAR (overlay). According to
> m-war-p documentation [1], when a file is present in both the application and
> the dependent war, the current application is the priority. My understanding
> is that when there are two files with same path
> in both current application and dependent war, this is the file in current
> application that should ultimately be taken to produce the final war.
> Example:
> current application contains the file src/main/webapp/WEB-INF/web.xml
> dependent war contain a nearly empty file dependentWar.war!WEB-INF/web.xml
> When I run mvn war:inplace I can read in the log:
> [INFO] --- maven-war-plugin:2.1-beta-1:inplace (default-cli) @ myWebApp ---
> ...
> [INFO] Processing war project
> [INFO] Processing overlay[ id com.mycompany:dependentWar]
> ...
> [INFO] File[WEB-INF/web.xml] belonged to overlay[currentBuild] so it will be
> overwritten.
> As a result the src/main/webapp/WEB-INF/web.xml file was overwritten in the
> current application by the file coming from the dependent WAR.
> If I run mvn war:exploded the result is correct and the file in
> target/myCurrentWebApp-XX-SNAPSHOT/WEB-INF/web.xml is the one coming from the
> current web app.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-171) Modules in multi-module projects are "built" too often
[ http://jira.codehaus.org/browse/MJAVADOC-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229604#action_229604 ] Dan Tran commented on MJAVADOC-171: --- for my case, i only need to build javadoc for one project, under multiple modules build, it triggers all sibbling project to build javadoc > Modules in multi-module projects are "built" too often > -- > > Key: MJAVADOC-171 > URL: http://jira.codehaus.org/browse/MJAVADOC-171 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.8, Linux >Reporter: Stefan Seidel >Priority: Critical > Fix For: 2.4 > > Attachments: 2.2.log, 2.3.log, mjavadoc171.patch, mvnexec.zip > > > In a multi-module project, all modules are "built" twice for each module. > This leads to huge performance problems when many modules are in a project. > In the attached sample project, the xmlbeans plugin is executed 27 times for > a project with one parent module and two submodules. 18 of these executions > can be attributed to the javadoc plugin. With version 2.2, only 3 invocations > (once for each project) are caused by the javadoc plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-200) Problem with login to jira over https and proxy
[
http://jira.codehaus.org/browse/MCHANGES-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229608#action_229608
]
Krashan Brahmanjara commented on MCHANGES-200:
--
Above problem occurs if ssl and authentication login page are enabled together.
Resolution
Problem is in class AbstractJiraDownloader. Page
http://confluence.atlassian.com/display/JIRA/Receiving+Search+Results+as+an+RSS+Feed
suggest to add param os_authType=basic to login url and this is what we need.
So the patch is :
private boolean doJiraAuthentication(HttpClient client, final String jiraUrl) {
// log into JIRA if we have to
String loginUrl = null;
StringBuffer loginLink = new StringBuffer(jiraUrl);
-loginLink.append("/login.jsp?os_destination=/secure/");
+loginLink.append("/login.jsp?os_authType=basic&os_destination=/secure/");
loginLink.append("&os_username=").append(jiraUser);
String password = null;
if (jiraPassword != null) {
password = StringUtils.repeat("*", jiraPassword.length());
}
getLog().debug("Login URL: " + loginLink + "&os_password=" + password);
loginLink.append("&os_password=").append(jiraPassword);
loginUrl = loginLink.toString();
+client.getState().setCredentials(
+new HttpAuthRealm(null,null),
+new UsernamePasswordCredentials( jiraUser, jiraPassword ) );
()...
> Problem with login to jira over https and proxy
> ---
>
> Key: MCHANGES-200
> URL: http://jira.codehaus.org/browse/MCHANGES-200
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Environment: Jdk 1.6_18
> Jira Enterprise Edition, Version: 3.13.3-#344)
>Reporter: Krashan Brahmanjara
>
> I cannot get changes log from JIRA but url used by maven is correct.
> I mean url
> https://jira.prv.pl/secure/IssueNavigator.jspa?view=rss&pid=INSCS&resolution=1&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none
> get correct xml in browsers like FF or IE however untrusted certificate info
> are displayed..
> BTW
> Login phase is very long.
> Deatils
> [DEBUG] Using proxy: 10.4.1.1 at port 3118
> [DEBUG] JIRA lives at: https://jira.prv.pl
> [DEBUG] Login URL:
> https://jira.prv.pl/login.jsp?os_destination=/secure/&os_username=TR$%^&os_password=*
> [DEBUG] Successfully logged in into JIRA.
> [DEBUG] download jira issues from url
> https://jira.prv.pl/secure/IssueNavigator.jspa?view=rss&pid=INSCS&resolution=1&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none
> [INFO] Downloading from JIRA at:
> https://jira.prv.pl/secure/IssueNavigator.jspa?view=rss&pid=INSCS&resolution=1&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none
> [WARNING] Downloading from JIRA failed. Received: [503]
> Pom configuration
>
> jira
> https://jira.prv.pl/browse?id=INSCS
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.3
>
>
>
>
>
>
>
> true
>
> resolution=1&sorter/field=issuetype&sorter/order=ASC
> Closed
> x
> TR
> true
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-200) Problem with login to jira over https and proxy
[ http://jira.codehaus.org/browse/MCHANGES-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Krashan Brahmanjara updated MCHANGES-200: - Attachment: AbstractJiraDownloader.java Patched file based on version from curront trunk. There are also "warning getrespons" patch with method getResponseBodyAsString > Problem with login to jira over https and proxy > --- > > Key: MCHANGES-200 > URL: http://jira.codehaus.org/browse/MCHANGES-200 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Environment: Jdk 1.6_18 > Jira Enterprise Edition, Version: 3.13.3-#344) >Reporter: Krashan Brahmanjara > Attachments: AbstractJiraDownloader.java > > > I cannot get changes log from JIRA but url used by maven is correct. > I mean url > https://jira.prv.pl/secure/IssueNavigator.jspa?view=rss&pid=INSCS&resolution=1&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none > get correct xml in browsers like FF or IE however untrusted certificate info > are displayed.. > BTW > Login phase is very long. > Deatils > [DEBUG] Using proxy: 10.4.1.1 at port 3118 > [DEBUG] JIRA lives at: https://jira.prv.pl > [DEBUG] Login URL: > https://jira.prv.pl/login.jsp?os_destination=/secure/&os_username=TR$%^&os_password=* > [DEBUG] Successfully logged in into JIRA. > [DEBUG] download jira issues from url > https://jira.prv.pl/secure/IssueNavigator.jspa?view=rss&pid=INSCS&resolution=1&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none > [INFO] Downloading from JIRA at: > https://jira.prv.pl/secure/IssueNavigator.jspa?view=rss&pid=INSCS&resolution=1&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none > [WARNING] Downloading from JIRA failed. Received: [503] > Pom configuration > > jira > https://jira.prv.pl/browse?id=INSCS > > > org.apache.maven.plugins > maven-changes-plugin > 2.3 > > > > > > > > true > > resolution=1&sorter/field=issuetype&sorter/order=ASC > Closed > x > TR > true > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGES-204) Invalid jire task are selected to report
Invalid jire task are selected to report Key: MCHANGES-204 URL: http://jira.codehaus.org/browse/MCHANGES-204 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: jira-report Affects Versions: 2.3 Reporter: Krashan Brahmanjara If Jira contains tasks for version not specified or version with '-SNAPSHOT' suffix that are no reported items. Current code cut -SNAPSHOT from current version so nothing is selected. Patch for JiraReportGenerator line 409 - //if ( issue.getFixVersion() != null && issue.getFixVersion().equals( releaseVersion ) ) +if ( issue.getFixVersion() == null || issue.getFixVersion().equals( releaseVersion ) || issue.getFixVersion().equals( currentVersion )) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-204) Invalid jire task are selected to report
[
http://jira.codehaus.org/browse/MCHANGES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229615#action_229615
]
Krashan Brahmanjara commented on MCHANGES-204:
--
Better patch - sometimes version is set but fix version not
String fixVersion = issue.getFixVersion();
if (fixVersion==null)
fixVersion = issue.getVersion();
if ( fixVersion == null || fixVersion.equals( releaseVersion ) ||
fixVersion.equals( currentVersion )) {
> Invalid jire task are selected to report
>
>
> Key: MCHANGES-204
> URL: http://jira.codehaus.org/browse/MCHANGES-204
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: jira-report
>Affects Versions: 2.3
>Reporter: Krashan Brahmanjara
>
> If Jira contains tasks for version not specified or version with '-SNAPSHOT'
> suffix that are no reported items.
> Current code cut -SNAPSHOT from current version so nothing is selected.
> Patch for JiraReportGenerator
> line 409
> - //if ( issue.getFixVersion() != null && issue.getFixVersion().equals(
> releaseVersion ) )
> +if ( issue.getFixVersion() == null || issue.getFixVersion().equals(
> releaseVersion ) || issue.getFixVersion().equals( currentVersion ))
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-204) Invalid JIRA issues are selected to report
[
http://jira.codehaus.org/browse/MCHANGES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-204:
-
Description:
If Jira contains tasks for version not specified or version with '-SNAPSHOT'
suffix that are no reported items.
Current code cut -SNAPSHOT from current version so nothing is selected.
Patch for JiraReportGenerator
line 409
{noformat}
- //if ( issue.getFixVersion() != null && issue.getFixVersion().equals(
releaseVersion ) )
+if ( issue.getFixVersion() == null || issue.getFixVersion().equals(
releaseVersion ) || issue.getFixVersion().equals( currentVersion ))
{noformat}
was:
If Jira contains tasks for version not specified or version with '-SNAPSHOT'
suffix that are no reported items.
Current code cut -SNAPSHOT from current version so nothing is selected.
Patch for JiraReportGenerator
line 409
- //if ( issue.getFixVersion() != null && issue.getFixVersion().equals(
releaseVersion ) )
+if ( issue.getFixVersion() == null || issue.getFixVersion().equals(
releaseVersion ) || issue.getFixVersion().equals( currentVersion ))
Summary: Invalid JIRA issues are selected to report (was: Invalid jire
task are selected to report)
> Invalid JIRA issues are selected to report
> --
>
> Key: MCHANGES-204
> URL: http://jira.codehaus.org/browse/MCHANGES-204
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: jira-report
>Affects Versions: 2.3
>Reporter: Krashan Brahmanjara
>
> If Jira contains tasks for version not specified or version with '-SNAPSHOT'
> suffix that are no reported items.
> Current code cut -SNAPSHOT from current version so nothing is selected.
> Patch for JiraReportGenerator
> line 409
> {noformat}
> - //if ( issue.getFixVersion() != null && issue.getFixVersion().equals(
> releaseVersion ) )
> +if ( issue.getFixVersion() == null || issue.getFixVersion().equals(
> releaseVersion ) || issue.getFixVersion().equals( currentVersion ))
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-204) Invalid JIRA issues are selected to report
[
http://jira.codehaus.org/browse/MCHANGES-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229620#action_229620
]
Dennis Lundberg commented on MCHANGES-204:
--
It sound to me like you are using JIRA in a very unusual way.
The "fix for" version in JIRA should *not* contain a "-SNAPSHOT" suffix. It
should be set to a version to be released, and you don't release SNAPSHOTs.
The plugin will only fetch issues that has a "fix for" version set. There is no
meaning in fetching issues without a fix for version, because the plugin have
no idea which release they belong to.
> Invalid JIRA issues are selected to report
> --
>
> Key: MCHANGES-204
> URL: http://jira.codehaus.org/browse/MCHANGES-204
> Project: Maven 2.x Changes Plugin
> Issue Type: Improvement
> Components: jira-report
>Affects Versions: 2.3
>Reporter: Krashan Brahmanjara
>
> If Jira contains tasks for version not specified or version with '-SNAPSHOT'
> suffix that are no reported items.
> Current code cut -SNAPSHOT from current version so nothing is selected.
> Patch for JiraReportGenerator
> line 409
> {noformat}
> - //if ( issue.getFixVersion() != null && issue.getFixVersion().equals(
> releaseVersion ) )
> +if ( issue.getFixVersion() == null || issue.getFixVersion().equals(
> releaseVersion ) || issue.getFixVersion().equals( currentVersion ))
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-668) Xalan 2.7.0 jar doesn't match the Apache.org download
[ http://jira.codehaus.org/browse/MEV-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229631#action_229631 ] Andreas Grunewald commented on MEV-668: --- Thanks Joerg. I am gonna try to find out what is going on. > Xalan 2.7.0 jar doesn't match the Apache.org download > - > > Key: MEV-668 > URL: http://jira.codehaus.org/browse/MEV-668 > Project: Maven Evangelism > Issue Type: Bug > Components: Problem with Jar >Reporter: Andreas Grunewald > > The xalan.jar that is in the maven repository does not match with the > official binary xalan.jar from apache.org contained in the zip retrieved from > http://apache.skazkaforyou.com/xml/xalan-j/binaries/xalan-j_2_7_0-bin.zip > versus the jar retrieved from > http://mirrors.ibiblio.org/pub/mirrors/maven2/xalan/xalan/2.7.0/xalan-2.7.0.jar > Location - Size - SHA1 > apache.org - 3,078,601 bytes - 10f170da8dfbcdcc4098131ba773710f0ba7aef1 > ibiblio.org - 2,730,442 bytes - a33c0097f1c70b20fa7ded220ea317eb3500515e > The apache.org one contains the org.apache.bcel.* packages those are missing > in the ibiblio.org version. > The ibiblio.org version contains org.apache.xml.serializer packages those are > missing in the apache.org one > Since I assume the project homepage of Xalan is the definitive source for the > correct build I assume that the ibiblio.org version is not the correct Xalan > Version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEV-668) Xalan 2.7.0 jar doesn't match the Apache.org download
[ http://jira.codehaus.org/browse/MEV-668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229636#action_229636 ] Andreas Grunewald commented on MEV-668: --- Just posted to the Xalan-Dev Mailing List http://marc.info/?l=xalan-dev&m=127989059227812&w=2 > Xalan 2.7.0 jar doesn't match the Apache.org download > - > > Key: MEV-668 > URL: http://jira.codehaus.org/browse/MEV-668 > Project: Maven Evangelism > Issue Type: Bug > Components: Problem with Jar >Reporter: Andreas Grunewald > > The xalan.jar that is in the maven repository does not match with the > official binary xalan.jar from apache.org contained in the zip retrieved from > http://apache.skazkaforyou.com/xml/xalan-j/binaries/xalan-j_2_7_0-bin.zip > versus the jar retrieved from > http://mirrors.ibiblio.org/pub/mirrors/maven2/xalan/xalan/2.7.0/xalan-2.7.0.jar > Location - Size - SHA1 > apache.org - 3,078,601 bytes - 10f170da8dfbcdcc4098131ba773710f0ba7aef1 > ibiblio.org - 2,730,442 bytes - a33c0097f1c70b20fa7ded220ea317eb3500515e > The apache.org one contains the org.apache.bcel.* packages those are missing > in the ibiblio.org version. > The ibiblio.org version contains org.apache.xml.serializer packages those are > missing in the apache.org one > Since I assume the project homepage of Xalan is the definitive source for the > correct build I assume that the ibiblio.org version is not the correct Xalan > Version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4738) DefaultArtifactResolver forks non-daemon threads
[ http://jira.codehaus.org/browse/MNG-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hanzelmann updated MNG-4738: - Attachment: MNG-4738-hanzelm.diff I attached a patch using a custom ThreadFactory in DefaultArtifactResolver. The test case uses ArtifactResolverTest as a template (the testcases go through the executor all the time) and checks for the existence of the DefaultArtifactResolver-ThreadGroup and daemon-status of the associated threads. > DefaultArtifactResolver forks non-daemon threads > > > Key: MNG-4738 > URL: http://jira.codehaus.org/browse/MNG-4738 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-beta-1 > Environment: Ubuntu Lucid, JDK 6u21 >Reporter: Jesse Glick >Priority: Minor > Attachments: MNG-4738-hanzelm.diff, MNG-4738.diff > > > I am working on embedding Maven 3 (beta 1). I ran into a problem with Maven > execution hanging at the end. > When we run a "process" in-VM, we try to emulate a forked Java as much as is > reasonable. A new thread group is created, whatever work needs to be done is > done from a new thread in that group, and then we wait for the "process" to > end by checking that all non-daemon threads in the group have exited. > In the case of Maven execution, typically DefaultArtifactResolver is called > at some point. By default, this creates a ThreadPoolExecutor with 5 > non-daemon threads in it (which are created inside the thread group of the > caller). Although all tasks are certainly completed by the end of the Maven > run, these 5 threads remain alive, and so the thread group cannot be > considered dead. > It seems to me that DefaultArtifactResolver is at fault here. It should not > be spawning non-daemon threads. Although it shuts down the executor upon > being finalized, there is no guarantee of this happening in a timely manner. > Since the tasks being run in the threads are only active within the dynamic > scope of calls to resolve, it should be safe to mark the executor threads as > daemon. I would be happy to supply a patch incl. test case if you agree with > the premise. > The workaround is to set maven.artifact.threads=1 before starting Maven > execution, so that no threads need be spawned at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4738) DefaultArtifactResolver forks non-daemon threads
[ http://jira.codehaus.org/browse/MNG-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hanzelmann updated MNG-4738: - Attachment: MNG-4738-hanzelm2.diff Sorry, wrong patch version - won't work with "mvn test", ThreadGroup may not be daemonized. Next attachement. ;) > DefaultArtifactResolver forks non-daemon threads > > > Key: MNG-4738 > URL: http://jira.codehaus.org/browse/MNG-4738 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-beta-1 > Environment: Ubuntu Lucid, JDK 6u21 >Reporter: Jesse Glick >Priority: Minor > Attachments: MNG-4738-hanzelm.diff, MNG-4738-hanzelm2.diff, > MNG-4738.diff > > > I am working on embedding Maven 3 (beta 1). I ran into a problem with Maven > execution hanging at the end. > When we run a "process" in-VM, we try to emulate a forked Java as much as is > reasonable. A new thread group is created, whatever work needs to be done is > done from a new thread in that group, and then we wait for the "process" to > end by checking that all non-daemon threads in the group have exited. > In the case of Maven execution, typically DefaultArtifactResolver is called > at some point. By default, this creates a ThreadPoolExecutor with 5 > non-daemon threads in it (which are created inside the thread group of the > caller). Although all tasks are certainly completed by the end of the Maven > run, these 5 threads remain alive, and so the thread group cannot be > considered dead. > It seems to me that DefaultArtifactResolver is at fault here. It should not > be spawning non-daemon threads. Although it shuts down the executor upon > being finalized, there is no guarantee of this happening in a timely manner. > Since the tasks being run in the threads are only active within the dynamic > scope of calls to resolve, it should be safe to mark the executor threads as > daemon. I would be happy to supply a patch incl. test case if you agree with > the premise. > The workaround is to set maven.artifact.threads=1 before starting Maven > execution, so that no threads need be spawned at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-145) Outputting dependency resolution/tree in a well known _machine readable_ output format
[
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Syedin updated MDEP-145:
--
Attachment: MDEP-145-velocity.patch
I've added basic support for velocity templates to dependency:resolve /
dependency:list mojos - see MDEP-145-velocity.patch attached.
This approach provides greater level of flexibility, allowing user to define
arbitrary output format by himself in runtime.
for example, to get output in pom-like format one needs to create following
template:
--
#foreach( $artifact in $resolvedDependencies )
$artifact.getGroupId()
$artifact.getArtifactId()
$artifact.getVersion()
#end
--
and then run resolve mojo:
--
mvn maven:resolve -DinputTemplate=path/to/template -DoutputFile=path/to/output
--
where path/to/template is either relative path on filesystem or path to
resource in classpath. Unfortunately, Unfortunately, Velocity doesn't play well
with absolute paths :(
The same approach could be expanded to:
- dependency:analyze*
- dependency:sources
- dependency:tree
> Outputting dependency resolution/tree in a well known _machine readable_
> output format
> --
>
> Key: MDEP-145
> URL: http://jira.codehaus.org/browse/MDEP-145
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: resolve, tree
>Affects Versions: 2.0
>Reporter: Samuel Le Berrigaud
>Assignee: Brian Fox
> Fix For: 2.2
>
> Attachments: MDEP-145-velocity.patch, MDEP-145.zip, treegraph.patch
>
>
> Currently (at least on trunk) one can output the dependencies in a file.
> However the file output doesn't follow any specific format, except from being
> the exact same output than on the console.
> I would be nice to have an easily parse-able, format so that tools could
> leverage the dependency resolution/tree. I am thinking for example of
> continuous integration tools that could report on added/removed/updated
> dependencies on modules.
> The format could be xml, json or something else. I've been playing with the
> current output to make it so that:
> * the first line describes the current module for which dependency resolution
> is done, formatted as such: {{:::}}
> * every following line is a dependency (indented by 2 or more spaces),
> formatted as such: {{}}
> This already is easy to parse.
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4738) DefaultArtifactResolver forks non-daemon threads
[ http://jira.codehaus.org/browse/MNG-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Hanzelmann updated MNG-4738: - Attachment: MNG-4738-hanzelm2-reformat.diff > DefaultArtifactResolver forks non-daemon threads > > > Key: MNG-4738 > URL: http://jira.codehaus.org/browse/MNG-4738 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-beta-1 > Environment: Ubuntu Lucid, JDK 6u21 >Reporter: Jesse Glick >Priority: Minor > Attachments: MNG-4738-hanzelm.diff, MNG-4738-hanzelm2-reformat.diff, > MNG-4738-hanzelm2.diff, MNG-4738.diff > > > I am working on embedding Maven 3 (beta 1). I ran into a problem with Maven > execution hanging at the end. > When we run a "process" in-VM, we try to emulate a forked Java as much as is > reasonable. A new thread group is created, whatever work needs to be done is > done from a new thread in that group, and then we wait for the "process" to > end by checking that all non-daemon threads in the group have exited. > In the case of Maven execution, typically DefaultArtifactResolver is called > at some point. By default, this creates a ThreadPoolExecutor with 5 > non-daemon threads in it (which are created inside the thread group of the > caller). Although all tasks are certainly completed by the end of the Maven > run, these 5 threads remain alive, and so the thread group cannot be > considered dead. > It seems to me that DefaultArtifactResolver is at fault here. It should not > be spawning non-daemon threads. Although it shuts down the executor upon > being finalized, there is no guarantee of this happening in a timely manner. > Since the tasks being run in the threads are only active within the dynamic > scope of calls to resolve, it should be safe to mark the executor threads as > daemon. I would be happy to supply a patch incl. test case if you agree with > the premise. > The workaround is to set maven.artifact.threads=1 before starting Maven > execution, so that no threads need be spawned at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4738) DefaultArtifactResolver forks non-daemon threads
[ http://jira.codehaus.org/browse/MNG-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229662#action_229662 ] Jesse Glick commented on MNG-4738: -- I can confirm that with this patch applied to a dev build, but not without, Maven execution leaves behind no non-daemon threads as expected. > DefaultArtifactResolver forks non-daemon threads > > > Key: MNG-4738 > URL: http://jira.codehaus.org/browse/MNG-4738 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-beta-1 > Environment: Ubuntu Lucid, JDK 6u21 >Reporter: Jesse Glick >Priority: Minor > Attachments: MNG-4738-hanzelm.diff, MNG-4738-hanzelm2-reformat.diff, > MNG-4738-hanzelm2.diff, MNG-4738.diff > > > I am working on embedding Maven 3 (beta 1). I ran into a problem with Maven > execution hanging at the end. > When we run a "process" in-VM, we try to emulate a forked Java as much as is > reasonable. A new thread group is created, whatever work needs to be done is > done from a new thread in that group, and then we wait for the "process" to > end by checking that all non-daemon threads in the group have exited. > In the case of Maven execution, typically DefaultArtifactResolver is called > at some point. By default, this creates a ThreadPoolExecutor with 5 > non-daemon threads in it (which are created inside the thread group of the > caller). Although all tasks are certainly completed by the end of the Maven > run, these 5 threads remain alive, and so the thread group cannot be > considered dead. > It seems to me that DefaultArtifactResolver is at fault here. It should not > be spawning non-daemon threads. Although it shuts down the executor upon > being finalized, there is no guarantee of this happening in a timely manner. > Since the tasks being run in the threads are only active within the dynamic > scope of calls to resolve, it should be safe to mark the executor threads as > daemon. I would be happy to supply a patch incl. test case if you agree with > the premise. > The workaround is to set maven.artifact.threads=1 before starting Maven > execution, so that no threads need be spawned at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4738) DefaultArtifactResolver forks non-daemon threads
[ http://jira.codehaus.org/browse/MNG-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229663#action_229663 ] Jesse Glick commented on MNG-4738: -- That is with *m2.diff; did not test *m2-reformat.diff. > DefaultArtifactResolver forks non-daemon threads > > > Key: MNG-4738 > URL: http://jira.codehaus.org/browse/MNG-4738 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-beta-1 > Environment: Ubuntu Lucid, JDK 6u21 >Reporter: Jesse Glick >Priority: Minor > Attachments: MNG-4738-hanzelm.diff, MNG-4738-hanzelm2-reformat.diff, > MNG-4738-hanzelm2.diff, MNG-4738.diff > > > I am working on embedding Maven 3 (beta 1). I ran into a problem with Maven > execution hanging at the end. > When we run a "process" in-VM, we try to emulate a forked Java as much as is > reasonable. A new thread group is created, whatever work needs to be done is > done from a new thread in that group, and then we wait for the "process" to > end by checking that all non-daemon threads in the group have exited. > In the case of Maven execution, typically DefaultArtifactResolver is called > at some point. By default, this creates a ThreadPoolExecutor with 5 > non-daemon threads in it (which are created inside the thread group of the > caller). Although all tasks are certainly completed by the end of the Maven > run, these 5 threads remain alive, and so the thread group cannot be > considered dead. > It seems to me that DefaultArtifactResolver is at fault here. It should not > be spawning non-daemon threads. Although it shuts down the executor upon > being finalized, there is no guarantee of this happening in a timely manner. > Since the tasks being run in the threads are only active within the dynamic > scope of calls to resolve, it should be safe to mark the executor threads as > daemon. I would be happy to supply a patch incl. test case if you agree with > the premise. > The workaround is to set maven.artifact.threads=1 before starting Maven > execution, so that no threads need be spawned at all. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-636) MECLIPSE-156 wasn't resolved
[ http://jira.codehaus.org/browse/MECLIPSE-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229671#action_229671 ] Diego Gomes commented on MECLIPSE-636: -- Hello, do we have any news about this issue? it's like a really important issue for people who use encoding. > MECLIPSE-156 wasn't resolved > > > Key: MECLIPSE-636 > URL: http://jira.codehaus.org/browse/MECLIPSE-636 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Workspace settings >Affects Versions: 2.7 >Reporter: Ramiro Pereira de Magalhães >Assignee: fabrizio giustina > Attachments: MECLIPSE-636-withTests.patch, patch-MECLIPSE-636.patch > > > Task MECLIPSE-156 wasn't correctly implemented and the proposed feature > (namely, that the plugin should support setting file encoding) does not work. > I think that only one of the proposed patches there were implemented (on > IdeUtils.java) while the other (on EclipseUtils.java) one wasn't. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4633) Make weave mode work reliably
[ http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229680#action_229680 ] Kristian Rosenvold commented on MNG-4633: - Thanks for reporting this problem, Robert ! It seems like a permutation of a different problem which has just been fixed in svn trunk r967190. I'd be real happy if you'd be able to test this. > Make weave mode work reliably > - > > Key: MNG-4633 > URL: http://jira.codehaus.org/browse/MNG-4633 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.0-beta-1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 3.0-beta-2 > > > m3 trunk currently contains two different concurrent-build implementations; > parallel and weave. The main target for m3 is for production quality > "parallel" to be ready; there are numerous plugins that will need to adjust > to this functionality. > Alongside this activity weave mode will also be fine-tuned and evaluated; due > to the generally tighter concurrency in this model, weave mode is more likely > to reveal concurrency related issues in both maven, plugins, libraries and > the jdk. > This task is used to collect all commits related to making weave mode work > reliably. The final evaluation of weave mode will be taken at a later stage. > In the event that Weave mode is to be abandoned, the class > LifecycleWeaveBuilder contains instructions on how/what can be removed from > m3 core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-196) No ant tasks run after artifact:mvn
No ant tasks run after artifact:mvn --- Key: MANTTASKS-196 URL: http://jira.codehaus.org/browse/MANTTASKS-196 Project: Maven 2.x Ant Tasks Issue Type: Bug Affects Versions: 2.1.0 Environment: Windows XP, Maven 2.2.1, Java 1.5 Reporter: Douglass Parker After invocation of artifact:mvn, no subsequent ant tasks run, even if artifact:mvn executes sucessfully. A simple example: Install finished The echo task will not be executed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-468) Capability to ignore classpath container 'It would be nice too when using alternate JRE like J2MELIB for example withe pyx4me maven plugin.
Capability to ignore the container
classpath entry 'org.eclipse.jdt.launching.JRE_CONTAINER'
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 4e90ceb663894a42f12c0e28abbab431
[
http://jira.codehaus.org/browse/MECLIPSE-468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229684#action_229684
]
Martin Schonaker commented on MECLIPSE-468:
---
I'm having a similar issue with Android. With this configuration:
{code}
com.android.ide.eclipse.adt.ANDROID_FRAMEWORK
...
{code}
I'm having this warning during a mvn eclipse:eclipse
{code}
[WARNING] You did specify a list of classpath containers without the base
org.eclipse.jdt.launching.JRE_CONTAINER.
If you specify custom classpath containers you should also add
org.eclipse.jdt.launching.JRE_CONTAINER to the list
{code}
And the .classpath file contains:
{code}
{code}
despite the fact that I didn't include it. The JRE container causes a lot of
compiling pain. The output needs to contain only the Android CP container in
order to have the project being built properly.
Regards.
> Capability to ignore classpath container 'It would be nice too when using
> alternate JRE like J2MELIB for example withe pyx4me maven plugin.
Capability to ignore the container classpath entry
'org.eclipse.jdt.launching.JRE_CONTAINER'
> -
>
> Key: MECLIPSE-468
> URL: http://jira.codehaus.org/browse/MECLIPSE-468
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5.1, 2.6
> Environment: linux (ubuntu 8.04), Sun JDK 1.6, maven 2.0.8
>Reporter: Guillaume Wallet
>
> I try to add J2MELIB container library but the plugin force the add of
> org.eclipse.jdt.launching.JRE_CONTAINER that I do not want (I develop mobile
> application so I do not use JRE).
> It would be nice, when using alternate JRE like J2MELIB, to de activate the
> default add of 'org.eclipse.jdt.launching.JRE_CONTAINER'
> I think it not a hard work, I can produce a patch if needed, for inspiration,
> just tell me
> best regards
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-145) Outputting dependency resolution/tree in a well known _machine readable_ output format
[
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229685#action_229685
]
luke w patterson commented on MDEP-145:
---
pretty cool, Alexander
flexible approach
> Outputting dependency resolution/tree in a well known _machine readable_
> output format
> --
>
> Key: MDEP-145
> URL: http://jira.codehaus.org/browse/MDEP-145
> Project: Maven 2.x Dependency Plugin
> Issue Type: Improvement
> Components: resolve, tree
>Affects Versions: 2.0
>Reporter: Samuel Le Berrigaud
>Assignee: Brian Fox
> Fix For: 2.2
>
> Attachments: MDEP-145-velocity.patch, MDEP-145.zip, treegraph.patch
>
>
> Currently (at least on trunk) one can output the dependencies in a file.
> However the file output doesn't follow any specific format, except from being
> the exact same output than on the console.
> I would be nice to have an easily parse-able, format so that tools could
> leverage the dependency resolution/tree. I am thinking for example of
> continuous integration tools that could report on added/removed/updated
> dependencies on modules.
> The format could be xml, json or something else. I've been playing with the
> current output to make it so that:
> * the first line describes the current module for which dependency resolution
> is done, formatted as such: {{:::}}
> * every following line is a dependency (indented by 2 or more spaces),
> formatted as such: {{}}
> This already is easy to parse.
> What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4633) Make weave mode work reliably
[ http://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=229693#action_229693 ] Robert Munteanu commented on MNG-4633: -- I have performed a test, and it seems that module A now runs its default-compile phase, but the classes are still not visible to B. A goes all the way to default-jar, but then B's generate-sources - which is actually a maven-compiler-plugin goal - is invoked, the classes are not found. > Make weave mode work reliably > - > > Key: MNG-4633 > URL: http://jira.codehaus.org/browse/MNG-4633 > Project: Maven 2 & 3 > Issue Type: Improvement >Affects Versions: 3.0-beta-1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: 3.0-beta-2 > > > m3 trunk currently contains two different concurrent-build implementations; > parallel and weave. The main target for m3 is for production quality > "parallel" to be ready; there are numerous plugins that will need to adjust > to this functionality. > Alongside this activity weave mode will also be fine-tuned and evaluated; due > to the generally tighter concurrency in this model, weave mode is more likely > to reveal concurrency related issues in both maven, plugins, libraries and > the jdk. > This task is used to collect all commits related to making weave mode work > reliably. The final evaluation of weave mode will be taken at a later stage. > In the event that Weave mode is to be abandoned, the class > LifecycleWeaveBuilder contains instructions on how/what can be removed from > m3 core. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINVOKER-105) invoker.mavenOpts seemingly ignored
invoker.mavenOpts seemingly ignored
---
Key: MINVOKER-105
URL: http://jira.codehaus.org/browse/MINVOKER-105
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Affects Versions: 1.5
Reporter: Benson Margulies
I set up a 'trivial' invocation of the integration-test goal.
I have an invoker.properties.
It contains:
{code}
invoker.mavenOpts = -Xmx2g -XX:MaxPermSize=256m
{code}
Yet, -X says:
{noformat}
[INFO] Building: aegis_standalone/pom.xml
[DEBUG] build log initialized in:
/Users/benson/asf/cxf/test-samples/target/it/aegis_standalone/build.log
[DEBUG] Using MAVEN_OPTS: null
[DEBUG] Executing: /bin/sh -c cd
/Users/benson/asf/cxf/test-samples/target/it/aegis_standalone &&
/opt/apache-maven-2.2.1/bin/mvn -B -D
maven.repo.local=/Users/benson/.m2/repository package
{noformat}
in a similiar vein, I also have an invoker.SystemProperties, and yet the
contents thereof do not appear on the command line as -D options.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINVOKER-105) invoker.mavenOpts seemingly ignored
[
http://jira.codehaus.org/browse/MINVOKER-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies closed MINVOKER-105.
-
Resolution: Not A Bug
I misread the doc.
> invoker.mavenOpts seemingly ignored
> ---
>
> Key: MINVOKER-105
> URL: http://jira.codehaus.org/browse/MINVOKER-105
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Benson Margulies
>
> I set up a 'trivial' invocation of the integration-test goal.
> I have an invoker.properties.
> It contains:
> {code}
> invoker.mavenOpts = -Xmx2g -XX:MaxPermSize=256m
> {code}
> Yet, -X says:
> {noformat}
> [INFO] Building: aegis_standalone/pom.xml
> [DEBUG] build log initialized in:
> /Users/benson/asf/cxf/test-samples/target/it/aegis_standalone/build.log
> [DEBUG] Using MAVEN_OPTS: null
> [DEBUG] Executing: /bin/sh -c cd
> /Users/benson/asf/cxf/test-samples/target/it/aegis_standalone &&
> /opt/apache-maven-2.2.1/bin/mvn -B -D
> maven.repo.local=/Users/benson/.m2/repository package
> {noformat}
> in a similiar vein, I also have an invoker.SystemProperties, and yet the
> contents thereof do not appear on the command line as -D options.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTTASKS-197) Dependency with packaging=pom shows up in the classpath
Dependency with packaging=pom shows up in the classpath
---
Key: MANTTASKS-197
URL: http://jira.codehaus.org/browse/MANTTASKS-197
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Components: dependencies task
Affects Versions: 2.1.1
Environment: Mac OSX, Ant 1.8.1
Reporter: Knut Forkalsrud
My use case is that I have a set of common dependencies that I use across many
projects.
In order to save me some typing I created a pom whose sole purpose is to depend
on all
the common dependencies, so that each of my projects can depend on only this
one pom.
The problem is that the pom file gets included in the classpath, an the junit
task shows
an annoying error because it can't make sense of it as a directory or jar file.
A relatively simple testcase to show the issue is this pom.xml:
{code:xml}http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";
xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
4.0.0
foo
bar
1.0
asm
asm-parent
3.1
pom
{code}
An the following build.xml in the same directory:
{code:xml}
${toString:maven2.test.classpath}
{code}
When I run this I expect the output from to list the classpath
consisting of the jars dependencies from {{asm-parent}}. That pom happens to
have no jar dependencies, so I expect the output to be empty. Instead I get
the path of the pom file.
In a more realistic example I will use this as a classpath argument to
and get an error like:
{noformat}
Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
java.util.zip.ZipException: error in opening zip file
[junit] Unable to obtain resource from
/Users/knut/.m2/repository/asm/asm-parent/3.1/asm-parent-3.1.pom:
[junit] java.util.zip.ZipException: error in opening zip file
[junit] at java.util.zip.ZipFile.open(Native Method)
[junit] at java.util.zip.ZipFile.(ZipFile.java:114)
[junit] at java.util.jar.JarFile.(JarFile.java:135)
[junit] at java.util.jar.JarFile.(JarFile.java:99)
[junit] at
org.apache.tools.ant.AntClassLoader.getResourceURL(AntClassLoader.java:1002)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.findNextResource(AntClassLoader.java:145)
[junit] at
org.apache.tools.ant.AntClassLoader$ResourceEnumeration.(AntClassLoader.java:109)
[junit] at
org.apache.tools.ant.AntClassLoader.findResources(AntClassLoader.java:949)
[junit] at
org.apache.tools.ant.AntClassLoader.getNamedResources(AntClassLoader.java:918)
[junit] at
org.apache.tools.ant.loader.AntClassLoader5.getResources(AntClassLoader5.java:54)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.checkForkedPath(JUnitTask.java:1135)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeAsForked(JUnitTask.java:1011)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:811)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.executeOrQueue(JUnitTask.java:1808)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.java:760)
[junit] at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
[junit] at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
[junit] at org.apache.tools.ant.Task.perform(Task.java:348)
[junit] at org.apache.tools.ant.Target.execute(Target.java:390)
[junit] at org.apache.tools.ant.Target.performTasks(Target.java:411)
[junit] at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
[junit] at org.apache.tools.ant.Project.executeTarget(Project.java:1366)
[junit] at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
[junit] at
org.apache.tools.ant.Project.executeTargets(Project.java:1249)
[junit] at org.apache.tools.ant.Main.runBuild(Main.java:801)
[junit] at org.apache.tools.ant.Main.startAnt(Main.java:218)
[junit] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
[junit] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
{noformat}
When I read MANTTASKS-41 I can't help but think it revolves around the same
culprit, but I'm not expert enough to pinpoint the issue.
-
