[jira] Commented: (MNG-3724) ExecutionProject not getting updated compile/test-compile/script roots in RC10
[ http://jira.codehaus.org/browse/MNG-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145794#action_145794 ] John Casey commented on MNG-3724: - fixed in SVN, just needs an integration test. > ExecutionProject not getting updated compile/test-compile/script roots in RC10 > -- > > Key: MNG-3724 > URL: http://jira.codehaus.org/browse/MNG-3724 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey > -- 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: (MNG-3724) ExecutionProject not getting updated compile/test-compile/script roots in RC10
ExecutionProject not getting updated compile/test-compile/script roots in RC10 -- Key: MNG-3724 URL: http://jira.codehaus.org/browse/MNG-3724 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.10 Reporter: John Casey -- 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-3685) Dependency can't be resolved but has been found in the reactor.
[ http://jira.codehaus.org/browse/MNG-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145789#action_145789 ] Kaizer Sogiawala commented on MNG-3685: --- We have seen this happen with release artifacts too. > Dependency can't be resolved but has been found in the reactor. > --- > > Key: MNG-3685 > URL: http://jira.codehaus.org/browse/MNG-3685 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Jörg Hohwiller > Fix For: 2.0.11 > > > Since I upgraded maven to 2.0.9, I get messages like the following endlessly: > Downloading: > http://m-m-m.sourceforge.net/repository/net/sf/m-m-m/mmm-util-core/1.0.2-SNAPSHOT/mmm-util-core-1.0.2-SNAPSHOT.jar > [WARNING] The dependency: net.sf.m-m-m:mmm-util-core:jar:1.0.2-SNAPSHOT can't > be resolved but has been found in the reactor. > This dependency has been excluded from the plugin execution. You should rerun > this mojo after executing mvn install. > This also happens, if someone checks out the project and does "mvn > eclipse:eclipse". The process still works but takes extraordinary long to > proceed because it scales about n^2 with n beiing the number of modules in > your reactor. > You should also take into account that "mvn install" aborts if some tests > fail. > Sorry to say so, but this behaviour of maven is absolutely inacceptable. I > hope there is a chance to fix this in the next release(s). Thanks! -- 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: (MNG-3723) ${project.basedir} is not interpolated
[
http://jira.codehaus.org/browse/MNG-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3723.
---
Resolution: Fixed
> ${project.basedir} is not interpolated
> --
>
> Key: MNG-3723
> URL: http://jira.codehaus.org/browse/MNG-3723
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.10
> Environment: Maven 2.0.10-RC8, JDK 1.6.0._06, maven-eclipse-plugin 2.4
>Reporter: Paul Benedict
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.10
>
>
> Here is what I did. I do not know if all the steps are necessary to reproduce
> the bug, but the bug is reproducible:
> 1. Check out a multi-level project
> 2. Install the parent with -N
> 3. Go into one of the children projects and then run eclipse:eclipse
> 4. You will see a folder named ${project.basedir} when execution is finished.
> Works fine in 2.0.9 and fails with 2.0.10. This is definitely a regression.
--
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-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145787#action_145787 ] Dan Fabulich commented on MNG-2576: --- I don't think I understand your question, but maybe this will help: revision 687388 was made to branches/maven-2.1.x. I have not ported it to trunk. The fate of the maven-2.1.x branch is up in the air right now, but I imagine that we will do a release off of that branch, and that it will be called 2.1.0 or possibly 2.1.1. > Make Like Reactor Mode > -- > > Key: MNG-2576 > URL: http://jira.codehaus.org/browse/MNG-2576 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Kenney Westerhof >Assignee: Dan Fabulich > Fix For: 2.1.0 > > > Add a commandline option to enable maven to expand the reactor scope to find > projects that are dependencies > of the projects currently in the reactor, and add them. > Currently only the current project and child projects are included in the > reactor search. I'm proposing > to add a commandline switch that lets maven check parent directories to find > the root of the project tree, > and then do a normal reactor scan, only adding projects that would normally > not be added if they're needed > as dependencies of the projects that would normally be built. > Here's a sample project tree: > * root > ** p1 > *** c1 (depends on p2) > ** p2 (depends on c2) > ** p3 > *** c2 > And a sample algorithm: > - When building c1, the reactor would contain [c1]. > - Maven would check p1, then root, etc, using the tags (without the > versions!) > to see if the project is still in the current reactor. > - It would then create a second list of projects (reactor2) containing ALL > projects, using the newly discovered root: [root, p1, c2, p2]. > - remove all projects from reactor2 contained in reactor: reactor2 = [root, > p1, p2] > - resolve all direct dependencies for all projects in reactor in reactor2 and > add them to reactor, taking versions into account: reactor = [p2, c1] > - repeat previous step until all projects have their dependencies resolved > from reactor 2. first iteration would yield reactor = [c2, p2, c1], > next iteration would stop since c1 doesn't have any dependencies present in > reactor2. > This would ensure that when some local project's sources have changed, > they'll be incorporated > in the build, regardless of where you build. So you don't have to do a > reactor build each time you change more > than 1 project, and you don't have to remember which projects you changed and > build them in the correct order > yourself, manually. -- 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-2576) Make Like Reactor Mode
[ http://jira.codehaus.org/browse/MNG-2576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145786#action_145786 ] Paul Benedict commented on MNG-2576: To be inline with the issue management that marks issues for branch/head as 2.0.x and 2.1.x, is this something that is also being slated for 3.0? If so, please add the version. > Make Like Reactor Mode > -- > > Key: MNG-2576 > URL: http://jira.codehaus.org/browse/MNG-2576 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line, Reactor and workspace >Reporter: Kenney Westerhof >Assignee: Dan Fabulich > Fix For: 2.1.0 > > > Add a commandline option to enable maven to expand the reactor scope to find > projects that are dependencies > of the projects currently in the reactor, and add them. > Currently only the current project and child projects are included in the > reactor search. I'm proposing > to add a commandline switch that lets maven check parent directories to find > the root of the project tree, > and then do a normal reactor scan, only adding projects that would normally > not be added if they're needed > as dependencies of the projects that would normally be built. > Here's a sample project tree: > * root > ** p1 > *** c1 (depends on p2) > ** p2 (depends on c2) > ** p3 > *** c2 > And a sample algorithm: > - When building c1, the reactor would contain [c1]. > - Maven would check p1, then root, etc, using the tags (without the > versions!) > to see if the project is still in the current reactor. > - It would then create a second list of projects (reactor2) containing ALL > projects, using the newly discovered root: [root, p1, c2, p2]. > - remove all projects from reactor2 contained in reactor: reactor2 = [root, > p1, p2] > - resolve all direct dependencies for all projects in reactor in reactor2 and > add them to reactor, taking versions into account: reactor = [p2, c1] > - repeat previous step until all projects have their dependencies resolved > from reactor 2. first iteration would yield reactor = [c2, p2, c1], > next iteration would stop since c1 doesn't have any dependencies present in > reactor2. > This would ensure that when some local project's sources have changed, > they'll be incorporated > in the build, regardless of where you build. So you don't have to do a > reactor build each time you change more > than 1 project, and you don't have to remember which projects you changed and > build them in the correct order > yourself, manually. -- 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-124) maxEntries is used in the JIRA URL
[
http://jira.codehaus.org/browse/MCHANGES-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145784#action_145784
]
Vincent Siveton commented on MCHANGES-124:
--
Since the filter is done in
JiraReportGenerator#getIssuesForCurrentRelease(List), I guess it will be easy
to ask JIRA to return all issues (ie without tempMax param) and apply the
filter/maxentries in Java. It will work only if currentVersion was set, in
other cases just apply the maxEntries as usual.
cons: could be time consuming if a project has a lot of issues (for instance
try given url on http://bugs.sakaiproject.org/jira/ )
> maxEntries is used in the JIRA URL
> --
>
> Key: MCHANGES-124
> URL: http://jira.codehaus.org/browse/MCHANGES-124
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira-report
>Affects Versions: 2.0
>Reporter: Vincent Siveton
>
> By default, the maxEntries is set to 100 and the generated JIRA url uses it,
> i.e.:
> {noformat}
> http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11138&statusIds=6&sorter/field=issuekey&sorter/order=ASC&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none
> {noformat}
> The Javadoc plugin 2.5 has more than 100 issues but the issues list size
> return by JIRA is 100 without any 2.5 fixVersion!
> A workaround is to increase the maxEntries
--
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: (SCM-402) scm:checkin doesn't work on OS X 10.5 Leopard
[ http://jira.codehaus.org/browse/SCM-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-402. Resolution: Fixed fixed in rev 688200. Thanks ! > scm:checkin doesn't work on OS X 10.5 Leopard > - > > Key: SCM-402 > URL: http://jira.codehaus.org/browse/SCM-402 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0 >Reporter: Dan Fabulich >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.1 > > Attachments: SCM-402.patch > > > Run "mvn scm:checkin -Dmessage=test" on OS X 10.5 Leopard. You'll see: > [INFO] Executing: svn --non-interactive commit --file > /tmp/maven-scm-1856881168.commit > But --non-interactive is broken on OS X 10.5 Leopard. > http://subversion.tigris.org/issues/show_bug.cgi?id=3059 > Brett Porter has a hacky workaround for it here: > http://blogs.exist.com/bporter/2008/02/25/working-around-non-interactive-problems-in-leopards-subversion/ -- 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: (SCM-402) scm:checkin doesn't work on OS X 10.5 Leopard
[ http://jira.codehaus.org/browse/SCM-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-402: - Fix Version/s: 1.1 > scm:checkin doesn't work on OS X 10.5 Leopard > - > > Key: SCM-402 > URL: http://jira.codehaus.org/browse/SCM-402 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0 >Reporter: Dan Fabulich >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 1.1 > > Attachments: SCM-402.patch > > > Run "mvn scm:checkin -Dmessage=test" on OS X 10.5 Leopard. You'll see: > [INFO] Executing: svn --non-interactive commit --file > /tmp/maven-scm-1856881168.commit > But --non-interactive is broken on OS X 10.5 Leopard. > http://subversion.tigris.org/issues/show_bug.cgi?id=3059 > Brett Porter has a hacky workaround for it here: > http://blogs.exist.com/bporter/2008/02/25/working-around-non-interactive-problems-in-leopards-subversion/ -- 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: (MNG-3698) Improve performance regarding concrete/dynamic build transitions surrounding plugin executions and report instantiations
[ http://jira.codehaus.org/browse/MNG-3698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3698. --- Resolution: Fixed > Improve performance regarding concrete/dynamic build transitions surrounding > plugin executions and report instantiations > > > Key: MNG-3698 > URL: http://jira.codehaus.org/browse/MNG-3698 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0.10 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.0.10 > > > This is increasing time to build by anywhere from 20% up to a reported 300%, > depending on whether reports and aggregator mojos are bound into the > lifecycle phases that are executed. Best candidate for fixing this issue is > currently to move this transition into the LIfecycleExecutor (out of the > PluginManager and PluginParameterExpressionEvaluator) to make the transition > less sensitive to report instantiation and forked lifecycles. > There are a couple of other potential performance improvements in the > interpolator itself, such as giving a plausible buffer size to the > StringWriter embedded for model interpolation, and hanging onto the > plexus-interpolator RegexBasedInterpolator instance to prevent continual > re-instantiation of the underlying regex Pattern object. -- 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-3723) ${project.basedir} is not interpolated
[
http://jira.codehaus.org/browse/MNG-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145780#action_145780
]
John Casey commented on MNG-3723:
-
fixed, just needs an integration test.
> ${project.basedir} is not interpolated
> --
>
> Key: MNG-3723
> URL: http://jira.codehaus.org/browse/MNG-3723
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.10
> Environment: Maven 2.0.10-RC8, JDK 1.6.0._06, maven-eclipse-plugin 2.4
>Reporter: Paul Benedict
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.10
>
>
> Here is what I did. I do not know if all the steps are necessary to reproduce
> the bug, but the bug is reproducible:
> 1. Check out a multi-level project
> 2. Install the parent with -N
> 3. Go into one of the children projects and then run eclipse:eclipse
> 4. You will see a folder named ${project.basedir} when execution is finished.
> Works fine in 2.0.9 and fails with 2.0.10. This is definitely a regression.
--
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: (MECLIPSE-167) .component assumes all dependencies should be packaged in WAR
[ http://jira.codehaus.org/browse/MECLIPSE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shelley Baker updated MECLIPSE-167: --- Attachment: MECLIPSE-167.zip The attached project provides some minimal project content/configuration to demonstrate this issue. Execute "mvn install eclipse:eclipse" and examine the generated org.eclipse.wst.common.component files. Notice that the JAR dependencies are dependent-modules in both the EAR and WAR projects. In the Maven build of these projects (outside of the IDE), the WAR would /not/ include the JARs, but rather, would only reference these JARs from the EAR (via the Manifest class-path). The issue here is that the maven-eclipse-plugin should allow WTP configuration to exclude dependencies from the WEB-INF/lib, or infer this desired configuration based on the maven-war-plugin's configuration of a "skinny" war [1]. [1] http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html > .component assumes all dependencies should be packaged in WAR > - > > Key: MECLIPSE-167 > URL: http://jira.codehaus.org/browse/MECLIPSE-167 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Reporter: Shelley Baker >Priority: Critical > Attachments: MECLIPSE-167.zip > > > Our applications are packaged such that the JAR dependencies are packaged > within the EAR, not the WARs. The dependencies are listed in the WAR in > order to generate the MANIFEST.MF class-path entries, and to add compile > dependencies to the .classpath. These dependencies are excluded from the > packaged WAR, however, via the maven-war-plugin's warSourceExcludes > configuration: WEB-INF/lib/*.jar since > they reference the EAR. [Related: MWAR-9] > The Eclipse Plugin WTP configuration file generation currently assumes that > all WAR project dependencies should be packaged and deployed in the WAR. > Each dependency is listed as a "dependent-module" with a deploy-path of > "/WEB-INF/lib" in the .component file. > This causes the dependencies to be duplicated and packaged in the EAR and in > every WAR when the project is published to an app server. > The eclipse-plugin should expose additional WTP configuration or read the > war-plugin's configuration in order to exclude these dependencies from being > packaged and deployed within the WAR. -- 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: (MECLIPSE-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David J. M. Karlsen updated MECLIPSE-388:
-
Attachment: MECLIPSE-388.patch
Here's a patch which use a LinkedHashSet and adds test resources before the
normal resources
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
> Attachments: MECLIPSE-388.patch
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-124) maxEntries is used in the JIRA URL
[
http://jira.codehaus.org/browse/MCHANGES-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145769#action_145769
]
Dennis Lundberg commented on MCHANGES-124:
--
How would you like the plugin to change?
What should it do differently than it does today?
> maxEntries is used in the JIRA URL
> --
>
> Key: MCHANGES-124
> URL: http://jira.codehaus.org/browse/MCHANGES-124
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: jira-report
>Affects Versions: 2.0
>Reporter: Vincent Siveton
>
> By default, the maxEntries is set to 100 and the generated JIRA url uses it,
> i.e.:
> {noformat}
> http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11138&statusIds=6&sorter/field=issuekey&sorter/order=ASC&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none
> {noformat}
> The Javadoc plugin 2.5 has more than 100 issues but the issues list size
> return by JIRA is 100 without any 2.5 fixVersion!
> A workaround is to increase the maxEntries
--
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: (MAVENUPLOAD-2185) Update JUnit to 4.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MAVENUPLOAD-2185: --- Summary: Update JUnit to 4.5 (was: Update JUnit to 4.4) > Update JUnit to 4.5 > --- > > Key: MAVENUPLOAD-2185 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2185 > Project: Maven Upload Requests > Issue Type: Improvement >Reporter: Benjamin Reed > > JUnit 4.5 was released on 2008/08/08 -- is it possible to get it upgraded in > the maven repo? > The previous release appears to have a rather sordid history: > http://jira.codehaus.org/browse/MAVENUPLOAD-1651 > I don't want to open up a can of worms, just would like to update to the > latest if possible. ;) -- 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: (MECLIPSE-484) Not finding main(...) through workspace resolution
Not finding main(...) through workspace resolution -- Key: MECLIPSE-484 URL: http://jira.codehaus.org/browse/MECLIPSE-484 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Environment: Eclipse Platform 3.3.1.1, Maven Integration for Eclipse 0.9.5.20080717-1821 Reporter: Sander Verhagen Attachments: testgroup.zip As discussed in http://www.nabble.com/Not-finding-main(...)-through-workspace-resolution-to19103273.html On a certain project Eclipse is not finding the main(...) that is located in one of its dependencies when it needs to be resolved through workspace resolution. Steps to reproduce: Given a project1 with an executable main class and a project2 that depends on project1. See the attachment. - Load project1 in Eclipse - Load project2 in Eclipse - Make sure that project2 is set to workspace resolution - Right-click project2 in the Package Explorer - Choose "Run As" - Choose "Java Application" - Observe the following outcome: "Launch Error" "Selection does not contain a main type" Verification: - Set project2 to disabled workspace resolution - Right-click project2 in the Package Explorer - Choose "Run As" - Choose "Java Application" - Observe the following outcome: "This is my main" in the Console view -- 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] Reopened: (MNG-3723) ${project.basedir} is not interpolated
[
http://jira.codehaus.org/browse/MNG-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey reopened MNG-3723:
-
it's still appearing intermittently.
> ${project.basedir} is not interpolated
> --
>
> Key: MNG-3723
> URL: http://jira.codehaus.org/browse/MNG-3723
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.10
> Environment: Maven 2.0.10-RC8, JDK 1.6.0._06, maven-eclipse-plugin 2.4
>Reporter: Paul Benedict
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.10
>
>
> Here is what I did. I do not know if all the steps are necessary to reproduce
> the bug, but the bug is reproducible:
> 1. Check out a multi-level project
> 2. Install the parent with -N
> 3. Go into one of the children projects and then run eclipse:eclipse
> 4. You will see a folder named ${project.basedir} when execution is finished.
> Works fine in 2.0.9 and fails with 2.0.10. This is definitely a regression.
--
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: (MRELEASE-376) release:perform checkout of source does not preserve bin +x permission
release:perform checkout of source does not preserve bin +x permission -- Key: MRELEASE-376 URL: http://jira.codehaus.org/browse/MRELEASE-376 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: linux Reporter: Kathleen McCandless Attachments: dist.xml, pom.xml I have with the release plugin in that when it does the "checkout" during release:perform, execute permission is not perserved on my executables in my bin directory. I use the assembly plugin, and doing: assembly:assembly I get the proper permissions, also, when I execute the same CVS command that the release plugin tells me it is doing: cvs -z3 -f -d :ext:[EMAIL PROTECTED]:/app/VBL/CVS -q checkout -r vbl_1_6_13a -d checkout virtual-beam-line The permissions are also correct (+x). I am wondering if someone might be able to help me with a workaround so I don't have to keep timing the chmod in the middle of release:perform by hand. Is there a way to invoke a command inbetween the CVS checkout and when the tests get run? I'm not sure how to extend it. See attached pom.xml, and dist.xml where I put in my assembly settings. -- 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-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145763#action_145763
]
David J. M. Karlsen commented on MECLIPSE-388:
--
Requiring 2.0.9 doesn't seem like a big issue for me (especially not when you
compare that to having a random/invalid classpath).
Also, it's important to preserve the order of test-resources, f.ex:
src/test/resources
src/main/config
src/test/resources should be before src/main/config - this is not the case p.t.
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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: (SCM-402) scm:checkin doesn't work on OS X 10.5 Leopard
[ http://jira.codehaus.org/browse/SCM-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated SCM-402: -- Attachment: SCM-402.patch patch for making the use of --non-interactive configurable > scm:checkin doesn't work on OS X 10.5 Leopard > - > > Key: SCM-402 > URL: http://jira.codehaus.org/browse/SCM-402 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0 >Reporter: Dan Fabulich >Priority: Blocker > Attachments: SCM-402.patch > > > Run "mvn scm:checkin -Dmessage=test" on OS X 10.5 Leopard. You'll see: > [INFO] Executing: svn --non-interactive commit --file > /tmp/maven-scm-1856881168.commit > But --non-interactive is broken on OS X 10.5 Leopard. > http://subversion.tigris.org/issues/show_bug.cgi?id=3059 > Brett Porter has a hacky workaround for it here: > http://blogs.exist.com/bporter/2008/02/25/working-around-non-interactive-problems-in-leopards-subversion/ -- 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: (ARCHETYPE-57) Support empty directory creation
[ http://jira.codehaus.org/browse/ARCHETYPE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphaël Piéroni closed ARCHETYPE-57. Resolution: Fixed Fix Version/s: 2.0-alpha-4 Fixed since revision 688113 > Support empty directory creation > > > Key: ARCHETYPE-57 > URL: http://jira.codehaus.org/browse/ARCHETYPE-57 > Project: Maven Archetype > Issue Type: Improvement > Components: Creator >Affects Versions: 1.0-alpha-4 >Reporter: Mark Hobson > Fix For: 2.0-alpha-4 > > Attachments: ARCHETYPE-57-patch > > > archetype.xml currently provides no way of creating empty directories. -- 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: (MSHADE-30) duplicate entry error
[ http://jira.codehaus.org/browse/MSHADE-30?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145757#action_145757 ] Mark commented on MSHADE-30: Thanks for the patch Henrik! as this is still not fixed in 1.1 or 1.2-SNAPSHOT we downloaded your patch and applied to the 1.1 code base locally and it worked like a charm > duplicate entry error > - > > Key: MSHADE-30 > URL: http://jira.codehaus.org/browse/MSHADE-30 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.0.1 >Reporter: Michael Mattox > Attachments: mshade-30-patch.txt > > > I receive this error: > Embedded error: duplicate entry: org/apache/xmlbeans/FilterXmlObject.class > It started with a javax.xml.namespace class. So I started putting excludes, > and then I kept getting one new class after another. If I exclude everything > then I doubt my application is going to work. > I really don't understand this error. I have never seen this type of error > with the fatjar eclipse plugin. I understand it's complaining about having > the same class twice, but if it's not a problem for my eclipse project or the > maven build, why is it a problem for shade? > I feel the shade plugin should be able to handle this gracefully. -- 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: (MAVENUPLOAD-2185) Update JUnit to 4.4
Update JUnit to 4.4 --- Key: MAVENUPLOAD-2185 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2185 Project: Maven Upload Requests Issue Type: Improvement Reporter: Benjamin Reed JUnit 4.5 was released on 2008/08/08 -- is it possible to get it upgraded in the maven repo? The previous release appears to have a rather sordid history: http://jira.codehaus.org/browse/MAVENUPLOAD-1651 I don't want to open up a can of worms, just would like to update to the latest if possible. ;) -- 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] Issue Comment Edited: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145750#action_145750 ] hg2008 edited comment on MNG-624 at 8/22/08 10:11 AM: -- Hello: Could someone provide a pointer to the process where one can patch and get a release of maven install plugin and manve-project. I've a simple patch to the problem mentioned in this issue (MNG-624) and MNG-3057. Also, what is the timeline for the fix proposed here (by Ralph Goers) is getting into the next release of maven. Greatly appreciate your comments and direction in this regard. Thanks.. Harsha was (Author: hg2008): Hello: Could someone provide a pointer to the process where a can patch and get a release of maven install plugin and manve-project. I've a simple patch to the problem mentioned in this issue (MNG-624) and MNG-3057. Also, what is the timeline for the fix proposed here (by Ralph Goers) is getting into the next release of maven. Greatly appreciate your comments and direction in this regard. Thanks.. Harsha > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145750#action_145750 ] Harsha Rai commented on MNG-624: Hello: Could someone provide a pointer to the process where a can patch and get a release of maven install plugin and manve-project. I've a simple patch to the problem mentioned in this issue (MNG-624) and MNG-3057. Also, what is the timeline for the fix proposed here (by Ralph Goers) is getting into the next release of maven. Greatly appreciate your comments and direction in this regard. Thanks.. Harsha > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- 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] Reopened: (MWAR-166) exclude the transitive dependency
[ http://jira.codehaus.org/browse/MWAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Meng reopened MWAR-166: --- I use the latest version already (2.1-alpha-2), May be I misunderstood the usage. Here is what I want -- In the project pom.xml, we define ubhsc service true and the service-2.5.1.jar are depends on serviceSub-2.6.1.jar (transitive) It ends up adding the serviceSub-2.6.1.jar to WEB-INF/lib folder and not adding service-2.5.1.jar to the WEB-INF/lib folder. Here what I really need is add service-2.5.1.jar to the WEB-INF/lib folder, but exclude the serviceSub-2.6.1.jar from the WEB-INF/lib folder. How to achieve this without using overlay or exclude ? Thanks > exclude the transitive dependency > - > > Key: MWAR-166 > URL: http://jira.codehaus.org/browse/MWAR-166 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Michael Meng >Assignee: Stephane Nicoll >Priority: Critical > > Would you please add a flag which will allow user to have a flexibility to > include/exclude the transitive dependent jars in the WEB-INF/lib folder? > The true defined inthe dependency is working as desired. > if we have a war project which depends on A.jar and A.jar transitively > depends on B.jar (B.jar is not defined in pom.xml). currently the A.jar and > B.jar are both included in the lib folder. > If we define A.jar as true, then A.jar is exclude from > lib folder, but B.jar are included. > What we really want is A.jar to be in lib and B.jar not to be include. > Thanks -- 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: (MNG-3722) Fail to run CXF code generation with 2.0.10 RC
[ http://jira.codehaus.org/browse/MNG-3722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3722. --- Resolution: Fixed > Fail to run CXF code generation with 2.0.10 RC > -- > > Key: MNG-3722 > URL: http://jira.codehaus.org/browse/MNG-3722 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.10 >Reporter: nicolas de loof >Assignee: John Casey > Fix For: 2.0.10 > > Attachments: test.zip > > > The attached project contains only a WSDL 2 Java code generation with a > dependency to slf4j. > Running "mvn install" fails in 2.0.10-RC9 with a NoSuchMethodError : trace on > commons-logging SLF4J API. > This MAY be a cxf plugin issue, as maybe it doesn't build the JAXB classpath > correctly... > Running with maven2 2.0.9 doesn't throw this error (the code generation fails > as the sample WSDL is RPC/encoded, but this is not the issue to be > demonstrated here) -- 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: (MNG-3723) ${project.basedir} is not interpolated
[
http://jira.codehaus.org/browse/MNG-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-3723.
---
Resolution: Fixed
fixed in RC10
> ${project.basedir} is not interpolated
> --
>
> Key: MNG-3723
> URL: http://jira.codehaus.org/browse/MNG-3723
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.10
> Environment: Maven 2.0.10-RC8, JDK 1.6.0._06, maven-eclipse-plugin 2.4
>Reporter: Paul Benedict
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.10
>
>
> Here is what I did. I do not know if all the steps are necessary to reproduce
> the bug, but the bug is reproducible:
> 1. Check out a multi-level project
> 2. Install the parent with -N
> 3. Go into one of the children projects and then run eclipse:eclipse
> 4. You will see a folder named ${project.basedir} when execution is finished.
> Works fine in 2.0.9 and fails with 2.0.10. This is definitely a regression.
--
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: (SCM-407) git scm:changelog does not have TCK Test yet
git scm:changelog does not have TCK Test yet Key: SCM-407 URL: http://jira.codehaus.org/browse/SCM-407 Project: Maven SCM Issue Type: Test Components: maven-scm-provider-git Affects Versions: 1.1 Reporter: Mark Struberg The maven-scm-provider-gitexe currently does not have the TCK test for the changelog command. -- 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: (MWAR-166) exclude the transitive dependency
[ http://jira.codehaus.org/browse/MWAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-166. Assignee: Stephane Nicoll Resolution: Won't Fix It's not something that you need to manage in plugins. Use excludes section if you want to exclude a dependency. Note that optional works as expected in the latest release > exclude the transitive dependency > - > > Key: MWAR-166 > URL: http://jira.codehaus.org/browse/MWAR-166 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Michael Meng >Assignee: Stephane Nicoll >Priority: Critical > > Would you please add a flag which will allow user to have a flexibility to > include/exclude the transitive dependent jars in the WEB-INF/lib folder? > The true defined inthe dependency is working as desired. > if we have a war project which depends on A.jar and A.jar transitively > depends on B.jar (B.jar is not defined in pom.xml). currently the A.jar and > B.jar are both included in the lib folder. > If we define A.jar as true, then A.jar is exclude from > lib folder, but B.jar are included. > What we really want is A.jar to be in lib and B.jar not to be include. > Thanks -- 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: (MWAR-158) Overlaying breaks configuration of webXml with a fatal error
[ http://jira.codehaus.org/browse/MWAR-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-158: - Priority: Critical (was: Blocker) > Overlaying breaks configuration of webXml with a fatal error > > > Key: MWAR-158 > URL: http://jira.codehaus.org/browse/MWAR-158 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.1-alpha-1 > Environment: Maven 2.0.9 > SuSE Linux 10.3 > java version "1.5.0_09" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) > Java HotSpot(TM) Server VM (build 1.5.0_09-b03, mixed mode) >Reporter: Michael Heß >Priority: Critical > Attachments: webXmlBug.tar.gz > > > When using overlays, it is no longer possible to use the webXml configuration > value. The following exception is thrown: > [INFO] [war:war] > [INFO] Packaging webapp > [INFO] Assembling webapp[webXmlBug] in > [/home/mhe/workspace_spielwiese/webXmlBug/target/webXmlBug] > [INFO] Processing war project > OverlayPackagingTask performPackaging overlay.getTargetPath() null[INFO] > Processing overlay[ id de.ordix.webXmlBug:overlay] > [INFO] Unpacking overlay[ id de.ordix.webXmlBug:overlay] > [INFO] Expanding: > /home/mhe/.m2/repository/de/ordix/webXmlBug/overlay/1.0-SNAPSHOT/overlay-1.0-SNAPSHOT.war > into > /home/mhe/workspace_spielwiese/webXmlBug/target/war/work/de.ordix.webXmlBug/overlay > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Should not happen, path[WEB-INF/web.xml] is flagged as being > registered but was not found. > [INFO] > > [INFO] Trace > java.lang.IllegalStateException: Should not happen, path[WEB-INF/web.xml] is > flagged as being registered but was not found. > at > org.apache.maven.plugin.war.util.WebappStructure.getOwner(WebappStructure.java:157) > at > org.apache.maven.plugin.war.util.WebappStructure.registerFile(WebappStructure.java:105) > at > org.apache.maven.plugin.war.packaging.AbstractWarPackagingTask.copyFile(AbstractWarPackagingTask.java:140) > [...] > I have attached a testcase, which reproduces the problem. Just build overlay > and webXmlBug with "mvn clean install". > (I know the testcase is synthetic. If you want a "real world" scenario, just > replace the resources-copy step with e.g. jsp-precompiling.) -- 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: (MWAR-166) exclude the transitive dependency
[ http://jira.codehaus.org/browse/MWAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-166: - Priority: Critical (was: Blocker) > exclude the transitive dependency > - > > Key: MWAR-166 > URL: http://jira.codehaus.org/browse/MWAR-166 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.1 >Reporter: Michael Meng >Priority: Critical > > Would you please add a flag which will allow user to have a flexibility to > include/exclude the transitive dependent jars in the WEB-INF/lib folder? > The true defined inthe dependency is working as desired. > if we have a war project which depends on A.jar and A.jar transitively > depends on B.jar (B.jar is not defined in pom.xml). currently the A.jar and > B.jar are both included in the lib folder. > If we define A.jar as true, then A.jar is exclude from > lib folder, but B.jar are included. > What we really want is A.jar to be in lib and B.jar not to be include. > Thanks -- 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: (MPH-46) Improve the output of help:describe
[ http://jira.codehaus.org/browse/MPH-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPH-46. -- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 fixed > Improve the output of help:describe > --- > > Key: MPH-46 > URL: http://jira.codehaus.org/browse/MPH-46 > Project: Maven 2.x Help Plugin > Issue Type: Improvement >Affects Versions: 2.0.2 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.1 > > > More like help:help, ie with indentation -- 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-124) maxEntries is used in the JIRA URL
maxEntries is used in the JIRA URL
--
Key: MCHANGES-124
URL: http://jira.codehaus.org/browse/MCHANGES-124
Project: Maven 2.x Changes Plugin
Issue Type: Bug
Components: jira-report
Affects Versions: 2.0
Reporter: Vincent Siveton
By default, the maxEntries is set to 100 and the generated JIRA url uses it,
i.e.:
{noformat}
http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11138&statusIds=6&sorter/field=issuekey&sorter/order=ASC&sorter/field=issuetype&sorter/order=ASC&tempMax=100&reset=true&decorator=none
{noformat}
The Javadoc plugin 2.5 has more than 100 issues but the issues list size return
by JIRA is 100 without any 2.5 fixVersion!
A workaround is to increase the maxEntries
--
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: (MECLIPSE-483) eclipse:eclipse fails to generate references to eclipse workspace projects on multiparent module structure
eclipse:eclipse fails to generate references to eclipse workspace projects on multiparent module structure -- Key: MECLIPSE-483 URL: http://jira.codehaus.org/browse/MECLIPSE-483 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Vytautas Civilis To make it simpler, I have following modules structure: Parent A -> extends -> Parent B Parent B defines modules: B.m1 and B.m2 Parent A defines modules: A.m3 and A.m4 Using flat layout, if that matters, so B, m1, m2, A, m3, m4 are in the same workspace folder, to make things easier. Now, when generating .classpath for modules in B, the .classpath files are correct -> module m1 reference _eclipse project_ of the m2 (if it does depend of course). Contrary, generated .classpath for A is incorrect. If the module A.m3 depends on B.m1, then .classpath will contain reference to the B.m1 _jar_, but _not_ eclipse project. That's because module B.m1 is not explicitly specified in A modules (which it shouldn't). In other words, mvn eclipse:eclipse fails to look up deeper than one parent. I suggest eclipse:eclipse should lookup all the way up parents tree for defined modules, that exist in the eclipse workspace. cvl -- 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
