[jira] Commented: (MAVENUPLOAD-2553) nexus.openqa.org -> central sync
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=186846#action_186846 ] Patrick Lightbody commented on MAVENUPLOAD-2553: Is removing that stuff just some sort of manual process? Would be nice if there were some way to automate that... > nexus.openqa.org -> central sync > > > Key: MAVENUPLOAD-2553 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2553 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Patrick Lightbody >Assignee: Carlos Sanchez > > I've added the maven key to ~/.ssh/authorized_keys. The CSV entry is: > "org.seleniumhq","maven-central-r...@openqa.org:/opt/nexus/sonatype-work/nexus/storage/releases","rsync_ssh","Patrick > Lightbody","patr...@lightbody.net",, -- 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-2553) nexus.openqa.org -> central sync
nexus.openqa.org -> central sync Key: MAVENUPLOAD-2553 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2553 Project: Maven Upload Requests Issue Type: Wish Reporter: Patrick Lightbody I've added the maven key to ~/.ssh/authorized_keys. The CSV entry is: "org.seleniumhq","maven-central-r...@openqa.org:/opt/nexus/sonatype-work/nexus/storage/releases","rsync_ssh","Patrick Lightbody","patr...@lightbody.net",, -- 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-3024) Missing artifact error text improvement
[ http://jira.codehaus.org/browse/MNG-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Lightbody reopened MNG-3024: I see this is done, but the text output looks like utter shit. Attaching a screenshot to show you > Missing artifact error text improvement > --- > > Key: MNG-3024 > URL: http://jira.codehaus.org/browse/MNG-3024 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Patrick Lightbody >Assignee: Jason van Zyl >Priority: Minor > Fix For: 2.0.7 > > Attachments: screenshot-1.jpg > > > I love how when an artifact can't be found, a nice error explains how to > install it locally. This is a great technique for onboarding new maven users > who might otherwise be frustrated, thinking that they can't use things no in > the public repo. Kudos to whoever did this initial work. > Now I suggest you take it a step further by including instructions for > deploying the file to a personal repo. For example: > Caused by: Missing: > -- > 1) j2ssh:j2ssh-core:jar:0.2.9 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=j2ssh -DartifactId=j2ssh-core \ > -Dversion=0.2.9 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=j2ssh -DartifactId=j2ssh-core \ > -Dversion=0.2.9 -Dpackaging=jar -Dfile=/path/to/file > -Durl=... -DrepositoryId=... > Path to dependency: > 1) com.hostedqa:hostedqa-anywhere-server:jar:1.7.4-SNAPSHOT > 2) j2ssh:j2ssh-core:jar:0.2.9 -- 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-3024) Missing artifact error text improvement
[ http://jira.codehaus.org/browse/MNG-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Lightbody updated MNG-3024: --- Attachment: screenshot-1.jpg > Missing artifact error text improvement > --- > > Key: MNG-3024 > URL: http://jira.codehaus.org/browse/MNG-3024 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Patrick Lightbody >Assignee: Jason van Zyl >Priority: Minor > Fix For: 2.0.7 > > Attachments: screenshot-1.jpg > > > I love how when an artifact can't be found, a nice error explains how to > install it locally. This is a great technique for onboarding new maven users > who might otherwise be frustrated, thinking that they can't use things no in > the public repo. Kudos to whoever did this initial work. > Now I suggest you take it a step further by including instructions for > deploying the file to a personal repo. For example: > Caused by: Missing: > -- > 1) j2ssh:j2ssh-core:jar:0.2.9 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=j2ssh -DartifactId=j2ssh-core \ > -Dversion=0.2.9 -Dpackaging=jar -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file > there: > mvn deploy:deploy-file -DgroupId=j2ssh -DartifactId=j2ssh-core \ > -Dversion=0.2.9 -Dpackaging=jar -Dfile=/path/to/file > -Durl=... -DrepositoryId=... > Path to dependency: > 1) com.hostedqa:hostedqa-anywhere-server:jar:1.7.4-SNAPSHOT > 2) j2ssh:j2ssh-core:jar:0.2.9 -- 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-3024) Missing artifact error text improvement
Missing artifact error text improvement --- Key: MNG-3024 URL: http://jira.codehaus.org/browse/MNG-3024 Project: Maven 2 Issue Type: Improvement Components: Artifacts Affects Versions: 2.0.6 Reporter: Patrick Lightbody Priority: Minor I love how when an artifact can't be found, a nice error explains how to install it locally. This is a great technique for onboarding new maven users who might otherwise be frustrated, thinking that they can't use things no in the public repo. Kudos to whoever did this initial work. Now I suggest you take it a step further by including instructions for deploying the file to a personal repo. For example: Caused by: Missing: -- 1) j2ssh:j2ssh-core:jar:0.2.9 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=j2ssh -DartifactId=j2ssh-core \ -Dversion=0.2.9 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=j2ssh -DartifactId=j2ssh-core \ -Dversion=0.2.9 -Dpackaging=jar -Dfile=/path/to/file -Durl=... -DrepositoryId=... Path to dependency: 1) com.hostedqa:hostedqa-anywhere-server:jar:1.7.4-SNAPSHOT 2) j2ssh:j2ssh-core:jar:0.2.9 -- 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: (MSUREFIRE-102) Latest surefire code causes XML parser problems
Latest surefire code causes XML parser problems --- Key: MSUREFIRE-102 URL: http://jira.codehaus.org/browse/MSUREFIRE-102 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Latest surefire as of May 1 Reporter: Patrick Lightbody Priority: Blocker Fix For: 2.2 With the latest releases surefire, the webwork tests ran just fine. With the latest code in trunk, I get weird XML parser errors that only get fixed once I set forkMode=once or childDelegation=false See for yourself: svn co https://svn.apache.org/repos/asf/incubator/webwork2 cd webwork2 mvn install The error I get in various tests is: javax.xml.parsers.FactoryConfigurationError: Provider for javax.xml.parsers.SAXParserFactory cannot be found at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at com.opensymphony.xwork.util.DomHelper.parse(DomHelper.java:86) -- 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: (MSUREFIRE-101) Surefire is giving classloader preferences to main sources before test sources
Surefire is giving classloader preferences to main sources before test sources -- Key: MSUREFIRE-101 URL: http://jira.codehaus.org/browse/MSUREFIRE-101 Project: Maven 2.x Surefire Plugin Type: Bug Environment: Running on trunk as of May 1 Reporter: Patrick Lightbody Priority: Blocker Fix For: 2.2 Giving the classloader preferences to the main files before the test files is opposite of what surefire used to do and different from all other test environments (Ant, IDEA, etc). This is a problem for the XWork build. To reproduce: cvs -d :pserver:[EMAIL PROTECTED]:/cvs login cvs -d :pserver:[EMAIL PROTECTED]:/cvs co xwork cd xwork mvn test If you're using the releases surefire plugin, they will pass just fine. If you're using the latest from trunk, they will fail. This is due to the fact that the tests are picking up src/java/xwork-default.xml instead of src/test/xwork-default.xml. -- 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: (MSUREFIRE-99) TestNG tests that cause commons-logging to load fail
TestNG tests that cause commons-logging to load fail Key: MSUREFIRE-99 URL: http://jira.codehaus.org/browse/MSUREFIRE-99 Project: Maven 2.x Surefire Plugin Type: Bug Environment: (Using latest from SVN as of May 1) Reporter: Patrick Lightbody Fix For: 2.2 Attachments: test.zip If a TestNG test uses commons-logging (either directly or a class that is tested does), this error is returned: == [INFO] Surefire report directory: /Users/plightbo/autoriginate/hostedqa/test/target/surefire-reports --- T E S T S --- [Utils] FAILED TO CREATE CLASS class com.acme.FooTest [INFO] [ERROR] BUILD ERROR [INFO] [INFO] java.lang.reflect.InvocationTargetException; nested exception is org.testng.TestNGException: java.lang.reflect.InvocationTargetException Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. == -- 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: (MASSEMBLY-14) assembly plugin does not include dependencies for all artifacts in reactor.
[ http://jira.codehaus.org/browse/MASSEMBLY-14?page=comments#action_64655 ] Patrick Lightbody commented on MASSEMBLY-14: Edwin, Sounds good, but I would assume the default moduleSet should _only_ be the current module, not all modules in the project. > assembly plugin does not include dependencies for all artifacts in reactor. > --- > > Key: MASSEMBLY-14 > URL: http://jira.codehaus.org/browse/MASSEMBLY-14 > Project: Maven 2.x Assembly Plugin > Type: Bug > Reporter: Erick Dovale > Assignee: Edwin Punzalan > Attachments: MNG-1206-maven-assembly-plugin.patch, test-assembly-m2.zip > > > When trying to create an archive using maven-assembly-plugin the dependencies > for the artifacts in the reactor are not added to the archive. > attached is a whole project structure that can be used to reproduce this > issue. -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
[ http://jira.codehaus.org/browse/MIDEA-44?page=comments#action_62746 ] Patrick Lightbody commented on MIDEA-44: I'm personally OK with it being defaulted to false, like I had in my patch. I'll defer to Brett on what he'd like to do. We do need a way to keep this behavior though: Bret and I find it _extremely_ valuable and haven't had problems with it (I'm also running 5.1). > Optional toggle switch to revert MIDEA-35 > - > > Key: MIDEA-44 > URL: http://jira.codehaus.org/browse/MIDEA-44 > Project: Maven 2.x Idea Plugin > Type: Improvement > Reporter: Patrick Lightbody > Assignee: Brett Porter > Fix For: 2.0 > Attachments: useShortDependencyNames.patch > > > I never had any problems with the short names that were removed when MIDEA-35 > was fixed, but I believe the reporter that it can cause problems. However, I > think that it is a useful enough feature that users should be able to turn it > on if they want to. So here is a patch that does that. -- 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: (MIDEA-46) Macros in reactor projects aren't added to the IDEA project
[ http://jira.codehaus.org/browse/MIDEA-46?page=comments#action_62557 ] Patrick Lightbody commented on MIDEA-46: Whoops, forgot to set the priority of this down - it's far from Major. Very low priority. > Macros in reactor projects aren't added to the IDEA project > --- > > Key: MIDEA-46 > URL: http://jira.codehaus.org/browse/MIDEA-46 > Project: Maven 2.x Idea Plugin > Type: Bug > Reporter: Patrick Lightbody > > > This is a bug in a previous patch I supplied. Basically, the feature that > lets you define a Library source dir works great for single-project maven > builds, but for reactor builds there is a small bug. > Basically, there is a Set that is passed in to the IdeaModuleMojo that gets > populated with names of path mappings when any source dir contains the > pattern $foo$. That Set is then used to populate the ipr file like so: > > > > The problem with my implementation is multiple macro Sets are created, one > for each module that gets build. Except for the root maven project, that Set > is immediately discarded since the project file is only built once. I don't > have a patch for this because I don't have a good suggested fix. > On the plus side, it's not a critical issue. The only problem is that IDEA > won't prompt the user to provide path mappings for those macros. Instead, you > have to do them by hand. -- 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: (MIDEA-46) Macros in reactor projects aren't added to the IDEA project
Macros in reactor projects aren't added to the IDEA project --- Key: MIDEA-46 URL: http://jira.codehaus.org/browse/MIDEA-46 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Patrick Lightbody This is a bug in a previous patch I supplied. Basically, the feature that lets you define a Library source dir works great for single-project maven builds, but for reactor builds there is a small bug. Basically, there is a Set that is passed in to the IdeaModuleMojo that gets populated with names of path mappings when any source dir contains the pattern $foo$. That Set is then used to populate the ipr file like so: The problem with my implementation is multiple macro Sets are created, one for each module that gets build. Except for the root maven project, that Set is immediately discarded since the project file is only built once. I don't have a patch for this because I don't have a good suggested fix. On the plus side, it's not a critical issue. The only problem is that IDEA won't prompt the user to provide path mappings for those macros. Instead, you have to do them by hand. -- 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: (MIDEA-45) Problems with exclude logic
Problems with exclude logic --- Key: MIDEA-45 URL: http://jira.codehaus.org/browse/MIDEA-45 Project: Maven 2.x Idea Plugin Type: Bug Reporter: Patrick Lightbody Attachments: excludeBugFix.patch The latest exclude logic has a couple problems: 1) an add() instead of an addAll() method causes some very funky IDEA behavior 2) a bug from my previous patch - the project's base dir was not used to build up the resource dir, breaking reactor builds 3) the smart logic in getExcludedDirectories() is nice an all, but if the dirs don't exist it does nothing. I provided a simpler implementation that may make most of that method moot, but it doesn't hurt to keep it there either. By comparing the simple strings (after having been sorted), you can achieve almost all the same optimizations. Patch supplied. -- 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: (MIDEA-44) Optional toggle switch to revert MIDEA-35
Optional toggle switch to revert MIDEA-35 - Key: MIDEA-44 URL: http://jira.codehaus.org/browse/MIDEA-44 Project: Maven 2.x Idea Plugin Type: Improvement Reporter: Patrick Lightbody Attachments: useShortDependencyNames.patch I never had any problems with the short names that were removed when MIDEA-35 was fixed, but I believe the reporter that it can cause problems. However, I think that it is a useful enough feature that users should be able to turn it on if they want to. So here is a patch that does that. -- 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: (MINSTALL-12) Parameters should not be read-only
[ http://jira.codehaus.org/browse/MINSTALL-12?page=all ]
Patrick Lightbody updated MINSTALL-12:
--
Attachment: install.diff
> Parameters should not be read-only
> --
>
> Key: MINSTALL-12
> URL: http://jira.codehaus.org/browse/MINSTALL-12
> Project: Maven 2.x Install Plugin
> Type: Improvement
> Versions: 2.1
> Environment: Maven 2.0.2 binary
> Reporter: Patrick Lightbody
> Attachments: install.diff
>
>
> When running the following plugin (as a workaround due to a bug in maven):
>
> maven-install-plugin
> org.apache.maven.plugins
>
>
> validate
>
>
> ${basedir}/repo/opensymphony/webwork/2.2.1-SNAPSHOT/webwork-2.2.1-SNAPSHOT.jar
> opensymphony
> webwork
> 2.2.1-SNAPSHOT
>
>
> install-file
>
>
>
>
> I get this error:
> "Error configuration: org.apache.maven.plugins:maven-install-plugin. Reason:
> ERROR: Cannot override read-only parameter: artifactId in goal:
> install:install-file"
> Bret says:
> (16:49:33) brett: odd
> (16:49:55) brett: hrmph
> (16:50:12) brett: they are all read-only, so can only be set on the command
> line
> (16:50:15) brett: I don't know why that is
> (16:50:28) PSquad32: should i open a feature request?
> (16:50:44) brett: yes, please
> So I did. Done.
--
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
