[jira] Created: (MNG-2974) Unable to resolve & download snapshot versions from CLI
Unable to resolve & download snapshot versions from CLI --- Key: MNG-2974 URL: http://jira.codehaus.org/browse/MNG-2974 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.6, 2.0.5, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0 Environment: Windows Reporter: Yves Van Steen When I try to use a snapshot released version of a plugin on the command line interface maven doesn't resolve these and download them from registered the plugin repositories. When using non snapshot versions it is not a problem to resolve and download them. When I add the plugin (a snapshot version) to a POM and run it it does download it. So the problem does not lie with the repo which is registered in the settings.xml in a profile which is active. The problem just seems to lie with the resolving and dowloading part of the process. Cause after the snapshot plugin is download using the POM way it does find the plugin when running it from the CLI. I first discovered this bug when trying to use the Maven install plugin. Here are commands used in the process. Reproding this way of use I got the same result when requesting other snapshot version of plugins that were not in the repository. Command used to load snapshot version from the CLI (this gives the error you find below) mvn org.apache.maven.plugins:maven-install-plugin:2.2-SNAPSHOT:install-file (... + correct plugin params ) Command used to load a specific released version from the CLI mvn org.apache.maven.plugins:maven-install-plugin:2.1:install-file (... + correct plugin params ) Command used to load a the top released version from the CLI mvn org.apache.maven.plugins:maven-install-plugin:install-file (... + correct plugin params ) Settings.xml File apachesnapshots d http://people.apache.org/repo/m2-snapshot-repository/ false true allways ignore Hope I gave you enough information to fix this error. It's not major but does hinder me at this point cause now I have to manually place this plugin in everyone of my developers local repo. -- 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-2974) Unable to resolve & download snapshot versions from CLI
[ http://jira.codehaus.org/browse/MNG-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94767 ] Yves Van Steen commented on MNG-2974: - Sorry, I seem to made it a major bug. This wasn't my intent and now I am unable to change this. > Unable to resolve & download snapshot versions from CLI > --- > > Key: MNG-2974 > URL: http://jira.codehaus.org/browse/MNG-2974 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6 > Environment: Windows >Reporter: Yves Van Steen > > When I try to use a snapshot released version of a plugin on the command line > interface maven doesn't resolve these and download them from registered the > plugin repositories. When using non snapshot versions it is not a problem to > resolve and download them. When I add the plugin (a snapshot version) to a > POM and run it it does download it. So the problem does not lie with the > repo which is registered in the settings.xml in a profile which is active. > The problem just seems to lie with the resolving and dowloading part of the > process. Cause after the snapshot plugin is download using the POM way it > does find the plugin when running it from the CLI. > I first discovered this bug when trying to use the Maven install plugin. > Here are commands used in the process. Reproding this way of use I got the > same result when requesting other snapshot version of plugins that were not > in the repository. > Command used to load snapshot version from the CLI (this gives the error you > find below) > mvn org.apache.maven.plugins:maven-install-plugin:2.2-SNAPSHOT:install-file > (... + correct plugin params ) > Command used to load a specific released version from the CLI > mvn org.apache.maven.plugins:maven-install-plugin:2.1:install-file (... + > correct plugin params ) > Command used to load a the top released version from the CLI > mvn org.apache.maven.plugins:maven-install-plugin:install-file (... + correct > plugin params ) > Settings.xml File > > apachesnapshots > > > d > > http://people.apache.org/repo/m2-snapshot-repository/ > > false > > > true > > allways > > ignore > > > > > Hope I gave you enough information to fix this error. It's not major but > does hinder me at this point cause now I have to manually place this plugin > in everyone of my developers local repo. -- 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-2982) Profile of a pom doesn't execute when running a reactor build of a child pom
Profile of a pom doesn't execute when running a reactor build of a child pom Key: MNG-2982 URL: http://jira.codehaus.org/browse/MNG-2982 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.6, 2.0.5, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0 Environment: Windows Reporter: Yves Van Steen I created a top pom toghether with a profile in a seperate file (profiles.xml). The problem is as follows when I execute the top pom the profile is available. When I execute the lowest pom the profile is available. When I access one of the middle poms the profile is not available. The profile just overrides one of the properties defined in the top pom. The property has to be used in different project who inherit of this pom. I'm guessing this is a bug cause If It was expected workflow it is really strange. I tested It using mvn help:active-profiles. The profile seems active when i run this command on the top pom. I added a example project that you can use to check the problem. This setup adds a profile that overrides property defined in the top pom. The profile is defined in the profiles.xml. Execute mvn install on the top pom and the property gets overriden. Execute the lowest pom (the level4-2 pom) and the property gets overriden. Execute (level2 or level3 pom) and the property has the old value and doesn't get overriden. You know if it gets overriden when you execute level4-2 project and check the echo statement that is added when i execute the antrun plugin. Property name is file.path. C:\path\main\blabla => in the top pom C:\path\custom\blabla => in the profiles.xml The problem with this setup is that when you run the top pom of the lowest pom no problem. But if you execute the reactor build of one of the middle pom functionality breaks. I solved this by placing the profile in settings.xml against the wishes of my supervisor who would have liked the profiles.xml way to 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] Updated: (MNG-2982) Profile of a pom doesn't execute when running a reactor build of a child pom
[ http://jira.codehaus.org/browse/MNG-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yves Van Steen updated MNG-2982: Attachment: bugtest2.rar An example of the problem > Profile of a pom doesn't execute when running a reactor build of a child pom > > > Key: MNG-2982 > URL: http://jira.codehaus.org/browse/MNG-2982 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6 > Environment: Windows >Reporter: Yves Van Steen > Attachments: bug.png, bugtest2.rar > > > I created a top pom toghether with a profile in a seperate file > (profiles.xml). The problem is as follows when I execute the top pom the > profile is available. When I execute the lowest pom the profile is available. > When I access one of the middle poms the profile is not available. > The profile just overrides one of the properties defined in the top pom. The > property has to be used in different project who inherit of this pom. > I'm guessing this is a bug cause If It was expected workflow it is really > strange. I tested It using mvn help:active-profiles. The profile seems > active when i run this command on the top pom. I added a example project > that you can use to check the problem. > This setup adds a profile that overrides property defined in the top pom. The > profile is defined in the profiles.xml. Execute mvn install on the top pom > and the property gets overriden. Execute the lowest pom (the level4-2 pom) > and the property gets overriden. Execute (level2 or level3 pom) and the > property has the old value and doesn't get overriden. You know if it gets > overriden when you execute level4-2 project and check the echo statement that > is added when i execute the antrun plugin. > Property name is file.path. > C:\path\main\blabla => in the top pom > C:\path\custom\blabla => in the profiles.xml > The problem with this setup is that when you run the top pom of the lowest > pom no problem. But if you execute the reactor build of one of the middle > pom functionality breaks. > I solved this by placing the profile in settings.xml against the wishes of my > supervisor who would have liked the profiles.xml way to 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] Updated: (MNG-2982) Profile of a pom doesn't execute when running a reactor build of a child pom
[ http://jira.codehaus.org/browse/MNG-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yves Van Steen updated MNG-2982: Attachment: bug.png The result of mvn help:active-profiles > Profile of a pom doesn't execute when running a reactor build of a child pom > > > Key: MNG-2982 > URL: http://jira.codehaus.org/browse/MNG-2982 > Project: Maven 2 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6 > Environment: Windows >Reporter: Yves Van Steen > Attachments: bug.png, bugtest2.rar > > > I created a top pom toghether with a profile in a seperate file > (profiles.xml). The problem is as follows when I execute the top pom the > profile is available. When I execute the lowest pom the profile is available. > When I access one of the middle poms the profile is not available. > The profile just overrides one of the properties defined in the top pom. The > property has to be used in different project who inherit of this pom. > I'm guessing this is a bug cause If It was expected workflow it is really > strange. I tested It using mvn help:active-profiles. The profile seems > active when i run this command on the top pom. I added a example project > that you can use to check the problem. > This setup adds a profile that overrides property defined in the top pom. The > profile is defined in the profiles.xml. Execute mvn install on the top pom > and the property gets overriden. Execute the lowest pom (the level4-2 pom) > and the property gets overriden. Execute (level2 or level3 pom) and the > property has the old value and doesn't get overriden. You know if it gets > overriden when you execute level4-2 project and check the echo statement that > is added when i execute the antrun plugin. > Property name is file.path. > C:\path\main\blabla => in the top pom > C:\path\custom\blabla => in the profiles.xml > The problem with this setup is that when you run the top pom of the lowest > pom no problem. But if you execute the reactor build of one of the middle > pom functionality breaks. > I solved this by placing the profile in settings.xml against the wishes of my > supervisor who would have liked the profiles.xml way to 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: (MNG-2742) Using a version range in a plugin dependency causes "failure to resolve artifact" error
[ http://jira.codehaus.org/browse/MNG-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96472 ] Yves Van Steen commented on MNG-2742: - I'm seeing the same thing and l'm using the latest maven release (2.0.6). > Using a version range in a plugin dependency causes "failure to resolve > artifact" error > --- > > Key: MNG-2742 > URL: http://jira.codehaus.org/browse/MNG-2742 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP SP2, java version "1.5.0_08" >Reporter: Matthew Adams > Attachments: mvn.txt, pom.xml > > > If I declare a dependency in a plugin using an exact version, Maven correctly > resolves the artifact. If, however, I change the dependency's version to a > version range, Maven no longer resolves the artifact. I'm using the very > same artifact and version range in my project's dependencies and everything > works ok. See my attached pom.xml file for details, in particular, the > comments "" and "". > I am using the "major.minor.revision-buildNumber" version string syntax as > described on the wiki. -- 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: (MDEPLOY-38) deploy:deploy-file fails silently on Windows URL containing invalid host name or share
[ http://jira.codehaus.org/browse/MDEPLOY-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96674 ] Yves Van Steen commented on MDEPLOY-38: --- I know It works for the double backslash way (file://\\windowspc\share\dirs...\). I expected that I had to formulate It like that. Now comes the but. But It only works when you have a single module build. When you have a reactor build (pom with modules) it only deploys the root (or top pom) but sub projects don't get deployed because maven starts to use slashes and not backslashes. Example : Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No deploy) Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No deploy) But It does NOT report a failure on the sub projects. And you can see the use of the normal slash. Is there a fix available for this ?? Thanx for any help > deploy:deploy-file fails silently on Windows URL containing invalid host name > or share > -- > > Key: MDEPLOY-38 > URL: http://jira.codehaus.org/browse/MDEPLOY-38 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Windows >Reporter: Maarten Brugman >Priority: Minor > > When using goal deploy:deploy-file, and a Windows URL is used of the form > "file://host/share/" containing an invalid host name or share, maven > reports XXX K uploaded and BUILD SUCCESSFUL. > NOTE: if a URL of the form "file://\\nonexistenthost\share\..." is used, the > command fails as expected. However, as soon as one backslash after "share" is > replaced by a frontslash, the goal fails silently (i.e. reports success). > Example of silent failure: > mvn deploy:deploy-file -Detc > -Durl=file://nonexistenthost/share/Maven-repository > --> output: > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file://nonexistenthost/share/Maven-repository/javax/faces/jsf-impl/1.1/jsf-impl-1.1.jar > 673K uploaded > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading repository metadata for: 'artifact javax.faces:jsf-impl' > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading project information for jsf-impl 1.1 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Jul 25 16:47:00 CEST 2006 > [INFO] Final Memory: 2M/4M > [INFO] > -- 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: (MDEPLOY-38) deploy:deploy-file fails silently on Windows URL containing invalid host name or share
[ http://jira.codehaus.org/browse/MDEPLOY-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96674 ] Yves Van Steen edited comment on MDEPLOY-38 at 5/22/07 10:41 AM: - Sorry, posted this message @ the wrong topic. I REMOVED THE CONTENT was: I know It works for the double backslash way (file://\\windowspc\share\dirs...\). I expected that I had to formulate It like that. Now comes the but. But It only works when you have a single module build. When you have a reactor build (pom with modules) it only deploys the root (or top pom) but sub projects don't get deployed because maven starts to use slashes and not backslashes. Example : Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No deploy) Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No deploy) But It does NOT report a failure on the sub projects. And you can see the use of the normal slash. Is there a fix available for this ?? Thanx for any help > deploy:deploy-file fails silently on Windows URL containing invalid host name > or share > -- > > Key: MDEPLOY-38 > URL: http://jira.codehaus.org/browse/MDEPLOY-38 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.2.1 > Environment: Windows >Reporter: Maarten Brugman >Priority: Minor > > When using goal deploy:deploy-file, and a Windows URL is used of the form > "file://host/share/" containing an invalid host name or share, maven > reports XXX K uploaded and BUILD SUCCESSFUL. > NOTE: if a URL of the form "file://\\nonexistenthost\share\..." is used, the > command fails as expected. However, as soon as one backslash after "share" is > replaced by a frontslash, the goal fails silently (i.e. reports success). > Example of silent failure: > mvn deploy:deploy-file -Detc > -Durl=file://nonexistenthost/share/Maven-repository > --> output: > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'deploy'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [deploy:deploy-file] (aggregator-style) > [INFO] > > [INFO] [deploy:deploy-file] > Uploading: > file://nonexistenthost/share/Maven-repository/javax/faces/jsf-impl/1.1/jsf-impl-1.1.jar > 673K uploaded > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading repository metadata for: 'artifact javax.faces:jsf-impl' > [INFO] Retrieving previous metadata from remote-repository > [INFO] Uploading project information for jsf-impl 1.1 > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 second > [INFO] Finished at: Tue Jul 25 16:47:00 CEST 2006 > [INFO] Final Memory: 2M/4M > [INFO] > -- 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: (MSITE-232) Deploy multi module site to windows share
Deploy multi module site to windows share - Key: MSITE-232 URL: http://jira.codehaus.org/browse/MSITE-232 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5, 2.0-beta-4 Environment: windows xp sp 2 Reporter: Yves Van Steen I was unable to deploy the sites of my submodules to my windows share. the windows share is one that is under a web path to my apache webserver. For the record some other posted bugs on the JIRA about deploy to windows share did'nt expect this kind of behaviour (the double backslash way, file:\\\...). I did. Don't really find it odd. It only works when you have a single module build. When you have a reactor build (pom with modules) it only deploys the root (or top pom) but sub projects don't get deployed because maven starts to use slashes and not backslashes. Example : Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No deploy) Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No deploy) But It does NOT report a failure on the sub projects. And you can see the use of the normal slash above. Is there a fix available for this ?? Thanx for any help -- 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: (MSITE-232) Deploy multi module site to windows share
[ http://jira.codehaus.org/browse/MSITE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96825 ] Yves Van Steen commented on MSITE-232: -- Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. > Deploy multi module site to windows share > - > > Key: MSITE-232 > URL: http://jira.codehaus.org/browse/MSITE-232 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: windows xp sp 2 >Reporter: Yves Van Steen > > I was unable to deploy the sites of my submodules to my windows share. the > windows share is one that is under a web path to my apache webserver. > For the record some other posted bugs on the JIRA about deploy to windows > share did'nt expect this kind of behaviour (the double backslash way, > file:\\\...). I did. Don't really find it odd. > It only works when you have a single module build. When you have a reactor > build (pom with modules) it only deploys the root (or top pom) but sub > projects don't get deployed because maven starts to use slashes and not > backslashes. > Example : > Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No > deploy) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No > deploy) > But It does NOT report a failure on the sub projects. And you can see the use > of the normal slash above. > Is there a fix available for this ?? > Thanx for any help -- 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: (MSITE-232) Deploy multi module site to windows share
[ http://jira.codehaus.org/browse/MSITE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96825 ] Yves Van Steen edited comment on MSITE-232 at 5/23/07 4:17 AM: --- Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. And that is still deployed something and just not the subprojects. And the deploying of jars works perfectly with the dubbel slash. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. was: Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. > Deploy multi module site to windows share > - > > Key: MSITE-232 > URL: http://jira.codehaus.org/browse/MSITE-232 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: windows xp sp 2 >Reporter: Yves Van Steen > > I was unable to deploy the sites of my submodules to my windows share. the > windows share is one that is under a web path to my apache webserver. > For the record some other posted bugs on the JIRA about deploy to windows > share did'nt expect this kind of behaviour (the double backslash way, > file:\\\...). I did. Don't really find it odd. > It only works when you have a single module build. When you have a reactor > build (pom with modules) it only deploys the root (or top pom) but sub > projects don't get deployed because maven starts to use slashes and not > backslashes. > Example : > Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No > deploy) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No > deploy) > But It does NOT report a failure on the sub projects. And you can see the use > of the normal slash above. > Is there a fix available for this ?? > Thanx for any help -- 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: (MSITE-232) Deploy multi module site to windows share
[ http://jira.codehaus.org/browse/MSITE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96825 ] Yves Van Steen edited comment on MSITE-232 at 5/23/07 4:19 AM: --- Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. And that it still deployed the root of the site and just not the subprojects. And the deploying of jars (deploy plugin) works perfectly with the dubbel slash. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. was: Hey this works. Thanx for you help. It would be nice to get a failure when path is wrong or none existent. And it is a little strang that to refer to a remote client you need to specify the localhost first. And that is still deployed something and just not the subprojects. And the deploying of jars works perfectly with the dubbel slash. Maybe you can adapt the resolution to recognize the \\ after the file:// to see that it is in fact windowsshare name. Because the extra initial / isn't really implied. It's also not mentioned anyware which just enhances the confusion and needless bugs being submitted. In linux It's used for setting the path to the root of the filesystem and not work relative. Which probably everyone knows. Just a suggestion. I like to follow common patterns to minimize in confusion about the use of a product. Thats why I love java. The community strives for this. > Deploy multi module site to windows share > - > > Key: MSITE-232 > URL: http://jira.codehaus.org/browse/MSITE-232 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4, 2.0-beta-5 > Environment: windows xp sp 2 >Reporter: Yves Van Steen > > I was unable to deploy the sites of my submodules to my windows share. the > windows share is one that is under a web path to my apache webserver. > For the record some other posted bugs on the JIRA about deploy to windows > share did'nt expect this kind of behaviour (the double backslash way, > file:\\\...). I did. Don't really find it odd. > It only works when you have a single module build. When you have a reactor > build (pom with modules) it only deploys the root (or top pom) but sub > projects don't get deployed because maven starts to use slashes and not > backslashes. > Example : > Deploy top = file://\\vam7225\repo\www\orbisbe (=> works) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component1 (=> No > deploy) > Deploy subproject = file://\\vam7225\repo\www\orbisbe/component2 (=> No > deploy) > But It does NOT report a failure on the sub projects. And you can see the use > of the normal slash above. > Is there a fix available for this ?? > Thanx for any help -- 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: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error
[ http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100024 ] Yves Van Steen commented on MSITE-211: -- I also have some problems with the beta-5. I'm getting an error "Server string invalid" When removing my proxy declaration all is fine. This error seems only to occur when using the beta-5. beta-4 is fine. The specific error comes from the jsch package which provides ssh support. The trouble is propably the proxy information that is injected in this Session class of the jsch package but the non proxy information is never checked in the wagon scpwagon class which initializes it. > Can't deploy site using site:deploy due to a ProxyHTTP error > > > Key: MSITE-211 > URL: http://jira.codehaus.org/browse/MSITE-211 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: linux ubuntu dapper drake >Reporter: Elid OR >Priority: Blocker > > When I execute the site deployment (with version that comes with maven 2.0.5) > "mvn site:deploy " I got an error see log en debug mode below. This used to > work correctly with maven version 2.04 (so maybe site plugin version > 2.0-beta-4 : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error uploading site > Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy > error: Forbidden > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error uploading > site > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > ... 16 more > Caused by: org.apache.maven.wagon.authentication.AuthenticationException: > Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: > Forbidden > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149) > ... 18 more > Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: > proxy error: Forbidden > at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at com.jcraft.jsch.Session.connect(Unknown Source) > at > org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) > ... 20 more > [INFO] > > [INFO] Total time: 3 seconds > [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007 > [INFO] Final Me
[jira] Commented: (MRELEASE-237) can't release a pom without it's modules
[ http://jira.codehaus.org/browse/MRELEASE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100153 ] Yves Van Steen commented on MRELEASE-237: - If it is possible I would like to see a property to the release plugin -Dblock-reactor that blocks the modules being build/released. mvn -N release:prepare release:perform is the command I use know. and in the configuration of the release plugin ... -N ... This seems to work but is not that clear. Definitly not to maven newbies who just what that one pom released. I've had to roll back some stuff because the -N was forgotten to the command and someone made a mess of things. Defenitily not fun for an administrator but it's my job. You break it, I fix it! The tag will still have all the files and directories in it's path but that I don't mind that much. Maybe you could create an extra property -Dscm-remove-modules property that first of all reacts to the block-reactor property and that sais it removes the module directories from the created tag in the source repository. This would be possible for subversion but not sure for other repository types. So make it scm dependent. Otherwise it was just a configuration in the maven pom like so : ... true true ... If this was in maven, maven would be perfect. To me this is just the last hick up in functionality. > can't release a pom without it's modules > > > Key: MRELEASE-237 > URL: http://jira.codehaus.org/browse/MRELEASE-237 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 >Reporter: Brett Porter > > We have the common pattern of a parent POM which may have modules, but is > released independently from them (plugins, archetypes being a classic > example). This is currently not possible in the release plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
