[jira] Updated: (MNG-4396) Ant plugin fails with Maven-3
[ http://jira.codehaus.org/browse/MNG-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4396: --- Affects Version/s: (was: 3.0) 3.0-alpha-3 > Ant plugin fails with Maven-3 > - > > Key: MNG-4396 > URL: http://jira.codehaus.org/browse/MNG-4396 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 3.0-alpha-3 >Reporter: Niall Pemberton > Attachments: output.txt, pom.xml > > > Apache Commons has an ant plugin which is used to generate custom download > and issue tracking pages for the 30+ components: > * http://commons.apache.org/commons-build-plugin/ > * > http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/ > This works fine with maven 2.x but when I tried to run the goals using > maven-3 built from the latest source today it fails. I'm attaching the output > (run with -X) . There is a small test project which can be used to show this > problem here: > * > http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/src/test-project/ > There are two goals: > * mvn commons:download-page > * mvn commons:jira-page > These should each create an xml document in the xdocs directory -- 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-4396) Ant plugin fails with Maven-3
Ant plugin fails with Maven-3 - Key: MNG-4396 URL: http://jira.codehaus.org/browse/MNG-4396 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 3.0 Reporter: Niall Pemberton Attachments: output.txt, pom.xml Apache Commons has an ant plugin which is used to generate custom download and issue tracking pages for the 30+ components: * http://commons.apache.org/commons-build-plugin/ * http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/ This works fine with maven 2.x but when I tried to run the goals using maven-3 built from the latest source today it fails. I'm attaching the output (run with -X) . There is a small test project which can be used to show this problem here: * http://svn.apache.org/repos/asf/commons/proper/commons-build-plugin/trunk/src/test-project/ There are two goals: * mvn commons:download-page * mvn commons:jira-page These should each create an xml document in the xdocs directory -- 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-2633) jtds 1.2.4 upload
jtds 1.2.4 upload - Key: MAVENUPLOAD-2633 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2633 Project: Maven Upload Requests Issue Type: Bug Reporter: Dan Tran Here is the discussion link leading to this upload request http://sourceforge.net/projects/jtds/forums/forum/104388/topic/3425769 -- 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: (SCM-333) Continuum ignores a new given password for a cvs account until the cvsroot is also changed
[ http://jira.codehaus.org/browse/SCM-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195059#action_195059 ] Fabrício Lemos commented on SCM-333: I could reproduce this bug on Continuum-1.3.4 > Continuum ignores a new given password for a cvs account until the cvsroot is > also changed > -- > > Key: SCM-333 > URL: http://jira.codehaus.org/browse/SCM-333 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.0 >Reporter: Peter Kehren > Fix For: 1.x > > > I changed (only!) the password of a cvs account and set this new password in > a project definition in continuum by the web interface. The next build of the > project did not work, because of a wrong password (no access to cvs was > reported). It seems, that continuum uses the old password although a new > password was set. After changing the cvsroot (replaced ip number by dns > entry; 100% NOT the reason for this error) the cvs system could be accessed; > the new password was used. -- 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-3004) Allow build lifecycle to execute tasks in parallel
[ http://jira.codehaus.org/browse/MNG-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195045#action_195045 ] Nicolas Frenay commented on MNG-3004: - I agree with Hans-Peter Störr idea. If someone is able to attack this problem now, it could be done in a way that it's only available if you're offline. When the thread-safe issue is fixed, this new feature will be ready to go. It also gives extra-time to test performance with parallelization, as it will probably require some "tweaking". Configurable maximum number of threads comes to my mind. > Allow build lifecycle to execute tasks in parallel > -- > > Key: MNG-3004 > URL: http://jira.codehaus.org/browse/MNG-3004 > Project: Maven 2 > Issue Type: Improvement > Components: Bootstrap & Build, General, Performance >Affects Versions: 2.0.6 >Reporter: Nigel Magnay > Fix For: 2.3.x > > Attachments: parallel-builds.patch > > > One of the great advantages with maven over scripted build environments is > that it can calculate the dependencies of the build, and it could execute > items that are independent of each other in parallel. > Unfortunately it currently doesn't do this, which would be a big win over > tools such as 'ant'. It also means that multicore machines have lots of idle > capacity when running a serial build that could be utilised. > I had a quick shot at seeing what might be required. Bear in mind this is the > first time I have looked at maven internally, and I was just trying to feel > my way around and build a POC. I got some of the way there, but my build > threads don't seem to have the correct classpath - I think this is something > to do with plexus / classworlds - but I don't know enough. > It'd be great to get this feature in a future version, or a way of running my > hack (figuring out why in a thread has not the plexus stuff) in the interim. -- 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-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195024#action_195024 ] Stephen Pack commented on MNG-4301: --- I believe the previous comment is the workaround for maven 2.2.0; for maven 2.2.1, you need to add httpclient in the configuration. Without that addition, I got the exception "Cannot find setter nor field in org.apache.maven.wagon.providers.http.LightweightHttpWagon for 'httpConfiguration'" > Invalid checksums on deploy when using webdav without extension > --- > > Key: MNG-4301 > URL: http://jira.codehaus.org/browse/MNG-4301 > Project: Maven 2 > Issue Type: Bug > Components: Deployment >Affects Versions: 2.2.1 > Environment: n/a >Reporter: Kevin Shekleton >Priority: Blocker > > With maven 2.2.1, our deployments via webdav are producing invalid checksums, > similar to the issue reported in MNG-4235. > From maven 2.0.8 and previous, the following build extension was required to > deploy via webdav: > > > org.apache.maven.wagon > wagon-webdav > 1.0-beta-2 > > > Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and > the aforementioned build extension must be removed from the project. If it > was included in the project the deployment would fail as Maven would report > multiple versions of wagon-webdav present. > With maven 2.2.0, our deployment suffered from invalid checksums reported in > MNG-4235. > With maven 2.2.1, we still see the invalid checksums on deployment as > reported in MNG-4235. However, I've found that if you add the above build > extension into the project, we don't experience this issue (of generating > invalid checksums). Is this workaround an intentional change brought about > by the fix of MNG-4235? -- 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-252) javadoc link : nonproxyhosts not used
[ http://jira.codehaus.org/browse/MJAVADOC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194986#action_194986 ] Martijn Verburg commented on MJAVADOC-252: -- Hi Vincent, sorry to take so long to get back to you. Is that option you mention to be used in conjunction with your patched version of this plugin? > javadoc link : nonproxyhosts not used > - > > Key: MJAVADOC-252 > URL: http://jira.codehaus.org/browse/MJAVADOC-252 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven-2.0.10 > jdk 1.6_014 >Reporter: Maxime Gréau >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.6.1 > > Attachments: link_nonproxy_2.0.10.patch, link_nonproxy_2.2.0.patch > > > - Prerequisite : > > - web access via http proxy > - javadoc-plugin configuration with true > - $MVN_HOME/conf/settings.xml with configuration above ( internal-host is > host to access the internal javadoc web sites ) > > > true > http > myproxyhost > myproxyport > internal-host > > > Launch the mvn site-deploy command. > If you have a dependency with an internal javadoc web site, the plugin tried > to link this javadoc with the http proxy and logged: > "Error fetching link: http://internal-host//apidocs/package-list. Ignored > it." > This is a bug because this javadoc isn't accessible via http proxy. > So I attached 2 patches : > - the first one (link_nonproxy_2.0.10.patch) is compatible (and tested) with > mvn 2.0.9 and 2.0.10 but included a method directly copied from > ProxyUtils.java (wagon-provider-api-1.0-beta-6.jar) > - the second (link_nonproxy_2.2.0.patch) used 2 classes from > wagon-provider-api-1.0-beta-6.jar dependency so it requires mvn 2.2 -- 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-4397) -Dnetbeans.execution=true breaks reaktor builds on windows
[
http://jira.codehaus.org/browse/MNG-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194978#action_194978
]
Benjamin Bentmann edited comment on MNG-4397 at 10/16/09 4:25 AM:
--
Insufficient information to debug, please re-open when a reproducible test
project is available. See also the instructions given at
http://jira.codehaus.org/browse/MNG
was (Author: bentmann):
Insufficient information to debug, please re-open when a reproducible test
project is available.
> -Dnetbeans.execution=true breaks reaktor builds on windows
> --
>
> Key: MNG-4397
> URL: http://jira.codehaus.org/browse/MNG-4397
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.2.1
> Environment: Windows XP, Windows 7
>Reporter: Johan Andrén
>Assignee: Benjamin Bentmann
>
> When building our multimodule project with the netbeans.execution property
> set (Just like the netbeans plugin run maven) none of the modules get
> installed in the local repository.
> Project structure is something like this with dependencies from project2 on
> project1 etc.
> root
> -- multi1
> project1 (jar)
> project2 (ejb)
> -- multi2
> project3 (nbm)
> project4 (nbm)
> project5 (nbm-application)
> Commandline from root of our top project to build all modules in the tree:
> 'mvn install -Dnetbeans.execution=true'
> In the output the modules that are not installed the part with
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing ...
> is not even present for each project built.
> If one of the leaf projects is built with netbeans.execution=true it gets
> installed as expected.
> The problem does not appear on OsX or linux with the same project.
--
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-4397) -Dnetbeans.execution=true breaks reaktor builds on windows
[
http://jira.codehaus.org/browse/MNG-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4397.
--
Resolution: Incomplete
Assignee: Benjamin Bentmann
Insufficient information to debug, please re-open when a reproducible test
project is available.
> -Dnetbeans.execution=true breaks reaktor builds on windows
> --
>
> Key: MNG-4397
> URL: http://jira.codehaus.org/browse/MNG-4397
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.2.1
> Environment: Windows XP, Windows 7
>Reporter: Johan Andrén
>Assignee: Benjamin Bentmann
>
> When building our multimodule project with the netbeans.execution property
> set (Just like the netbeans plugin run maven) none of the modules get
> installed in the local repository.
> Project structure is something like this with dependencies from project2 on
> project1 etc.
> root
> -- multi1
> project1 (jar)
> project2 (ejb)
> -- multi2
> project3 (nbm)
> project4 (nbm)
> project5 (nbm-application)
> Commandline from root of our top project to build all modules in the tree:
> 'mvn install -Dnetbeans.execution=true'
> In the output the modules that are not installed the part with
> [INFO] [install:install {execution: default-install}]
> [INFO] Installing ...
> is not even present for each project built.
> If one of the leaf projects is built with netbeans.execution=true it gets
> installed as expected.
> The problem does not appear on OsX or linux with the same project.
--
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: (MEAR-114) Properties in task not taken into consideration when defining an execution id for an auto generating application.xml
Properties in task not taken into consideration when defining an
execution id for an auto generating application.xml
-
Key: MEAR-114
URL: http://jira.codehaus.org/browse/MEAR-114
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.2
Environment: Windows XP, M2Eclipse, Eclipse Galileo
Reporter: Anthony BOUQUET
{code:xml}
com.logic.silogisme.pidi
TransfertOT-WAR
my-custom-context-root
{code}
But this doesn't work (it produce an application.xml with default contextRoot)
{code:xml}
execution-1
com.logic.silogisme.pidi
TransfertOT-WAR
my-custom-context-root
{code}
This is problematic if we want to use multiple executions .
--
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-4397) -Dnetbeans.execution=true breaks reaktor builds on windows
-Dnetbeans.execution=true breaks reaktor builds on windows
--
Key: MNG-4397
URL: http://jira.codehaus.org/browse/MNG-4397
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.2.1
Environment: Windows XP, Windows 7
Reporter: Johan Andrén
When building our multimodule project with the netbeans.execution property set
(Just like the netbeans plugin run maven) none of the modules get installed in
the local repository.
Project structure is something like this with dependencies from project2 on
project1 etc.
root
-- multi1
project1 (jar)
project2 (ejb)
-- multi2
project3 (nbm)
project4 (nbm)
project5 (nbm-application)
Commandline from root of our top project to build all modules in the tree: 'mvn
install -Dnetbeans.execution=true'
In the output the modules that are not installed the part with
[INFO] [install:install {execution: default-install}]
[INFO] Installing ...
is not even present for each project built.
If one of the leaf projects is built with netbeans.execution=true it gets
installed as expected.
The problem does not appear on OsX or linux with the same project.
--
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: (MRESOURCES-109) Problem when variables are replaced in under windows in the ressources files
[
http://jira.codehaus.org/browse/MRESOURCES-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MRESOURCES-109.
---
Resolution: Not A Bug
> Problem when variables are replaced in under windows in the ressources files
>
>
> Key: MRESOURCES-109
> URL: http://jira.codehaus.org/browse/MRESOURCES-109
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Environment: Windows
>Reporter: Alexandre Navarro
>
> Problem when variables are replaced in under windows in the ressources files.
> For instance, I have a persistence.xml in src/main/ressources
> with
> ${basedir}/target/classes
> After filtering, the String was changed to
> C\:\\HOMEWARE\\workspace-3.5\\efts-trunk\\efts-referential/target/classes
> The \ after C: is abnormal.
> In maven 2.0.9, it works (no \) but in maven 2.2.1 it does not work.
--
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: (MRESOURCES-109) Problem when variables are replaced in under windows in the ressources files
[
http://jira.codehaus.org/browse/MRESOURCES-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194976#action_194976
]
Alexandre Navarro commented on MRESOURCES-109:
--
Sorry, you're totally right, I force the ressource plugin to 2.4.1 and it works.
You can close the issue.
Thank you.
> Problem when variables are replaced in under windows in the ressources files
>
>
> Key: MRESOURCES-109
> URL: http://jira.codehaus.org/browse/MRESOURCES-109
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
> Environment: Windows
>Reporter: Alexandre Navarro
>
> Problem when variables are replaced in under windows in the ressources files.
> For instance, I have a persistence.xml in src/main/ressources
> with
> ${basedir}/target/classes
> After filtering, the String was changed to
> C\:\\HOMEWARE\\workspace-3.5\\efts-trunk\\efts-referential/target/classes
> The \ after C: is abnormal.
> In maven 2.0.9, it works (no \) but in maven 2.2.1 it does not work.
--
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
