Re: Can no longer deploy project artifacts using maven3
Hi Jason, thank you for your detailed reply. On 6 April 2011 13:59, Jason van Zyl wrote: >> On Apr 6, 2011, at 8:33 AM, Tim Pizey wrote: >> >> Hi Jason, Marc, >> >> Thankyou for your help. >> >> I am now back to working for M2 and M3, but it looks like I need to >> get with the plot and use Nexus. >> >> I have never understood why the maven generated site does not link to >> the default distribution repo., > > I think this would be a harmful conflation of concerns. > The site plugin's > concern is documentation, that people try to use it as a general purpose > publishing mechanism is bad. I think that this is where we differ. The beauty of Maven, as I saw it, was the conflation of code and documentation. Particularly in a CI environment there is no reason for the code and documentation to get out of step. By separating the two we have allowed the two fail situations: 1. where the artifact in the public repositories has no up-to-date documentation. 2. where the documentation exists but not the artifact referred to. I cannot see the case for publishing an artifact without publishing the site, the two steps need to be separated on a developers machine, but they should, in my view, not be separable at the publishing step. > But additionally we have found cases where > projects have published their own repositories and then don't maintain them. > They vanish, people complain and then Maven is blamed. There is no reason why central should not be an aggregating service, just not the source, so a decentralised model does not entail Maven being blamed. As long as the site has existed and the aggregator has seen it then it does not matter if the site disappears. > The chances are very > high that we can maintain your repository infrastructure better then you > can. No disputing that, I wiped mine yesterday :) It would be lovely if all previous versions were being stored elsewhere. > That's not meant to be a slight it's just that we do this everyday, > have full time people, it's monitored, replicated and users have come to > expect everything to just work, be production quality even though they are > depending heavily on an OSS infrastructure that they are not paying for. > We > try to provide that infrastructure because we know how many things can, and > do, go awry. > > > nor why the decision was taken not to persue per dependency repos. > > If by this you mean why we don't let everyone maintain their own > repositories and aggregate them? That was not what I meant, though it is what I think would be best. What I meant was that you are not able to specify in the pom a repository for a particular dependency. So to use say http://webmacro.sourceforge.net/maven2/ for one dependency it has to be polled for every dependency. There is an issue in JIRA on this marked 'won't fix'. > The answer to this is that if it were a > consortium of enterprises who's viability depended on the availability of > the repositories it might work. But with OSS projects that come and go, many > networks that go up and down, security concerns, possible outages, and the > general dissipation of interest we know that it would cause an unacceptable > level of grief for users and the system would likely collapse if everyone > just tried to manage their own repositories. I cannot think of the major OOS infrastructure sites which have disappeared. sourceforge? google code ? java.net ? I am not suggesting that there is no role for repo1 or Nexus, just that they should pull not require projects to push. > That said there is nothing stopping any project from publishing their own > repositories and providing instructions on how to use that repository as > part of project build. Users don't like it. The distributed approach is nice > in theory, but for a bunch of OSS projects in practice it fails. We've had > lots of example of project releasing to repositories, publishing POMs and > then the repositories being removed. I am not sure which ones you are thinking of, but only ones I can think of that have disappeared have been corporations. The core open source organisations are stronger than ever: apache, codehaus, sourceforge, googlecode I think they can now be taken for granted and bet on to outlast any commercial concern. >> The central repo strategy has failed a few times since maven1, and the >> repo-as-proxy (Nexus) >> would make even more sense if it were proxying a lot of other small repos. > > Maven Central since being on Contegix has had very little downtime. While on > Ibiblio, yes it stopped working all the time. That's why I moved it off > Ibiblio a long time ago. I think users of Maven Central get pretty good > service for something they don't pay for. Sure, I love the net, there is lots of free stuff on it. >> I just do not see why, as a project owner, with control over my own >> webspace I should have to involve a third party to distribute my >> artifacts. > You're not forced at all. But most Maven users have com
Re: Can no longer deploy project artifacts using maven3
On Apr 6, 2011, at 8:33 AM, Tim Pizey wrote: > Hi Jason, Marc, > > Thankyou for your help. > > I am now back to working for M2 and M3, but it looks like I need to > get with the plot and use Nexus. > > I have never understood why the maven generated site does not link to > the default distribution repo., I think this would be a harmful conflation of concerns. The site plugin's concern is documentation, that people try to use it as a general purpose publishing mechanism is bad. But additionally we have found cases where projects have published their own repositories and then don't maintain them. They vanish, people complain and then Maven is blamed. The chances are very high that we can maintain your repository infrastructure better then you can. That's not meant to be a slight it's just that we do this everyday, have full time people, it's monitored, replicated and users have come to expect everything to just work, be production quality even though they are depending heavily on an OSS infrastructure that they are not paying for. We try to provide that infrastructure because we know how many things can, and do, go awry. > nor why the decision was taken not to persue per dependency repos. If by this you mean why we don't let everyone maintain their own repositories and aggregate them? The answer to this is that if it were a consortium of enterprises who's viability depended on the availability of the repositories it might work. But with OSS projects that come and go, many networks that go up and down, security concerns, possible outages, and the general dissipation of interest we know that it would cause an unacceptable level of grief for users and the system would likely collapse if everyone just tried to manage their own repositories. That said there is nothing stopping any project from publishing their own repositories and providing instructions on how to use that repository as part of project build. Users don't like it. The distributed approach is nice in theory, but for a bunch of OSS projects in practice it fails. We've had lots of example of project releasing to repositories, publishing POMs and then the repositories being removed. > > The central repo strategy has failed a few times since maven1, and the > repo-as-proxy (Nexus) > would make even more sense if it were proxying a lot of other small repos. Maven Central since being on Contegix has had very little downtime. While on Ibiblio, yes it stopped working all the time. That's why I moved it off Ibiblio a long time ago. I think users of Maven Central get pretty good service for something they don't pay for. > > I just do not see why, as a project owner, with control over my own > webspace I should have to involve a third party to distribute my > artifacts. You're not forced at all. But most Maven users have come to expect artifacts to be in Maven Central. If you provide the instructions they can build using your artifact wherever they are. But here the burden is on you. The vast majority of users publish and consume via HTTP and expect artifacts to be in Maven Central. That is the what we choose to support well. The SSH libraries for Java are flaky, using executables is fraught with permissions problems, platform problems while the HTTP libraries are far more reliable in general. Additionally I doubt there is a single Maven developer who uses SCP to deploy and we are all generally in favor of repository managers. So in the spirit of OSS why would we scratch an itch non of us have. > Why not have a default repo generated as part of the site > plugin? > What's stopping you from implementing that? I personally think it's a bad idea, and would result in large scale failure. I would never implement it but if you wanted to add that functionality to the site plugin there's nothing stopping you. Whether that approach would be popular you would find out. I believe you are in the great minority using SCP to deploy, as such much of the burden to support this approach is yours. > thanks for the great help > Tim > > > On 6 April 2011 13:23, Jason van Zyl wrote: >> If this is for a Sourceforge (I saw Webmacro in there) project then the >> route that many have gone is to drop SCP, and use Nexus OSS. There are 1300 >> projects using Nexus OSS now, it's easier to get your project into Maven >> Central and you don't have to worry about the Maven repository >> infrastructure. It would honestly have taken you less time to setup >> something with: >> >> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide >> >> Then trying to fiddle with the SCP stuff. You still get all your project >> download statistics and like and far less hassle. >> >> If you jump into #mavencentral on Codehaus IRC I imagine we can get you >> setup from end to end in a couple hours. >> >> On Apr 6, 2011, at 7:49 AM, Tim Pizey wrote: >> >>> Hi, >>> >>> I now have my project deploying u
Re: Can no longer deploy project artifacts using maven3
Hi Jason, Marc, Thankyou for your help. I am now back to working for M2 and M3, but it looks like I need to get with the plot and use Nexus. I have never understood why the maven generated site does not link to the default distribution repo., nor why the decision was taken not to persue per dependency repos. The central repo strategy has failed a few times since maven1, and the repo-as-proxy (Nexus) would make even more sense if it were proxying a lot of other small repos. I just do not see why, as a project owner, with control over my own webspace I should have to involve a third party to distribute my artifacts. Why not have a default repo generated as part of the site plugin? thanks for the great help Tim On 6 April 2011 13:23, Jason van Zyl wrote: > If this is for a Sourceforge (I saw Webmacro in there) project then the > route that many have gone is to drop SCP, and use Nexus OSS. There are 1300 > projects using Nexus OSS now, it's easier to get your project into Maven > Central and you don't have to worry about the Maven repository > infrastructure. It would honestly have taken you less time to setup something > with: > > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide > > Then trying to fiddle with the SCP stuff. You still get all your project > download statistics and like and far less hassle. > > If you jump into #mavencentral on Codehaus IRC I imagine we can get you setup > from end to end in a couple hours. > > On Apr 6, 2011, at 7:49 AM, Tim Pizey wrote: > >> Hi, >> >> I now have my project deploying using scp. >> >> I added an explicit configuration for the deploy plugin to the pom: >> >> maven-deploy-plugin >> 2.5 >> >> >> org.apache.maven.wagon >> wagon-ssh >> 1.0-beta-7 >> >> >> >> >> To get Maven (M2) to deploy using scp you need to add >> the wagon-ssh.jar in your /usr/local/apache-maven/lib or equivalent, >> (if you do not you will get a spurious "failed to create directory >> message" and a NPE) >> >> You do not need an section for M2 or M3. >> >> Thanks for your help, >> I would welcome the ssh wagon being part of the default install. >> >> cheers >> Tim >> >> -- >> Tim Pizey - http://pizey.net/~timp >> Centre for Genomics and Global Health - http://cggh.org >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > There's no sense in being precise when you don't even know what you're > talking about. > > -- John von Neumann > > > > -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
If this is for a Sourceforge (I saw Webmacro in there) project then the route that many have gone is to drop SCP, and use Nexus OSS. There are 1300 projects using Nexus OSS now, it's easier to get your project into Maven Central and you don't have to worry about the Maven repository infrastructure. It would honestly have taken you less time to setup something with: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide Then trying to fiddle with the SCP stuff. You still get all your project download statistics and like and far less hassle. If you jump into #mavencentral on Codehaus IRC I imagine we can get you setup from end to end in a couple hours. On Apr 6, 2011, at 7:49 AM, Tim Pizey wrote: > Hi, > > I now have my project deploying using scp. > > I added an explicit configuration for the deploy plugin to the pom: > > maven-deploy-plugin > 2.5 > > > org.apache.maven.wagon > wagon-ssh > 1.0-beta-7 > > > > > To get Maven (M2) to deploy using scp you need to add > the wagon-ssh.jar in your /usr/local/apache-maven/lib or equivalent, > (if you do not you will get a spurious "failed to create directory > message" and a NPE) > > You do not need an section for M2 or M3. > > Thanks for your help, > I would welcome the ssh wagon being part of the default install. > > cheers > Tim > > -- > Tim Pizey - http://pizey.net/~timp > Centre for Genomics and Global Health - http://cggh.org > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: Can no longer deploy project artifacts using maven3
Hi Tim, On 06/04/11 12:34, Tim Pizey wrote: I cannot see in what sense ssh is an extension ... In the sense that it is not incuded in the Maven core anymore ... ;) ... But if You really need different configurations for M2 and M3, You could use different profiles that are automatically activated when the build is executed with M2 or M3. Thanks, yes, different profiles occurred to me, but really I want a single pom which will build under m2 and m3. Currently scp does not work under M2 or M3. It is a single POM. Both profiles (I think You only need one for M3) are defined inside the POM. Return to the original version of Your POM an define the scp build extension in a profile, that is automatically activated when the build is executed with M3. I'd suggest to use a repository manager, it provides You with several advantages over a simple docroot and normally work fine with the HTTP(S) protocols. I guess I am forced to, but I have used this simple, elegant mechanism since maven1 ! I do not see the use case for repository managers, and am in disagreement with the decision not to support per-dependency repositories. (My take on the success of the internet is decentralization). I'd say repository managers provide even more elegant features. They allow (amongst others) proxying public repos (to reduce traffic and download/build times), Legacy (M1) to default (M2/M3) repo layout transformation, automatic snapshot clean-up and finding dependencies by contained Java classes. Define Your repo manager as a mirror in Your settings.xml ... What should I do about older M2 repositories? eg http://webmacro.sourceforge.net/maven2/ Proxy them in the repo manager ... See [2], it provides a list of the commonly used repository mangers along with some general information. Especially take a look at the feature matrix [3], it will help You to select the right one for Your needs - I'd suggest to take a closer look at Nexus ;) So scp support has been removed to drive people to Nexus ?? I don't know why it was removed - maybe someone else can answer this. I'd suggest that one of the reasons was to get a lighter (and faster) Maven core. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Hi, I now have my project deploying using scp. I added an explicit configuration for the deploy plugin to the pom: maven-deploy-plugin 2.5 org.apache.maven.wagon wagon-ssh 1.0-beta-7 To get Maven (M2) to deploy using scp you need to add the wagon-ssh.jar in your /usr/local/apache-maven/lib or equivalent, (if you do not you will get a spurious "failed to create directory message" and a NPE) You do not need an section for M2 or M3. Thanks for your help, I would welcome the ssh wagon being part of the default install. cheers Tim -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Hi Marc, On 6 April 2011 09:52, Marc Rohlfs wrote: > Tim, I hope You don't mind the question, but did You add the the wagon jar > to the MAVEN_HOME/lib directory on Your Hudson server, too? Thanks, no, I had not. I have now, and it still does not work: http://jenkins.paneris.net/job/melati/138/console > Anyway, I'd rather not add any libraries to the MAVEN_HOME/lib directory, > because this needs to be done on each and every server and workstation where > the Maven build has to be executed and would most likely be forgotten when > setting up new environments. Furthermore, You won't be able to use Hudsons > automatic installation support for Maven any more. I agree. I cannot see in what sense ssh is an extension and I do not want to manually upgrade maven. > I thought that adding the wagon JAR as a build extension as well as adding > adding it as a plugin dependency would work with both M2 and M3. But if You > really need different configurations for M2 and M3, You could use different > profiles that are automatically activated when the build is executed with M2 > or M3. [1] shows how this could be achieved. Thanks, yes, different profiles occurred to me, but really I want a single pom which will build under m2 and m3. Currently scp does not work under M2 or M3. > One last question: How is the Your Maven repository realised? Reading Your > posts, I assume that You might use an Apache server and copy the artifacts > to the docroot (using the scp wagon). yes, you have it: melati Melati M2 Repository scp://melati.org/data/www/maven2/ melati_site scp://melati.org/data/www/melati/ > I'd suggest to use a repository > manager, it provides You with several advantages over a simple docroot and > normally work fine with the HTTP(S) protocols. I guess I am forced to, but I have used this simple, elegant mechanism since maven1 ! I do not see the use case for repository managers, and am in disagreement with the decision not to support per-dependency repositories. (My take on the success of the internet is decentralization). What should I do about older M2 repositories? eg http://webmacro.sourceforge.net/maven2/ > See [2], it provides a list > of the commonly used repository mangers along with some general information. > Especially take a look at the feature matrix [3], it will help You to select > the right one for Your needs - I'd suggest to take a closer look at Nexus ;) So scp support has been removed to drive people to Nexus ?? > Kind regards > > Marc Thank you very much for your detailed reply. I can use straight file:// urls, as my CI server is on the same machine, and only ever deploy from a CI build, but that does not fix http://webmacro.sourceforge.net/maven2/ As others have successfully got scp working I am sure it will work for me soon. thanks again for your help Tim > > [1] > https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-Usingmavensiteplugin2.xwithMaven2.xandmavensiteplugin3.xwithMaven3.x > [2] http://maven.apache.org/repository-management.html > [3] > http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix > -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Tim, I hope You don't mind the question, but did You add the the wagon jar to the MAVEN_HOME/lib directory on Your Hudson server, too? Anyway, I'd rather not add any libraries to the MAVEN_HOME/lib directory, because this needs to be done on each and every server and workstation where the Maven build has to be executed and would most likely be forgotten when setting up new environments. Furthermore, You won't be able to use Hudsons automatic installation support for Maven any more. I thought that adding the wagon JAR as a build extension as well as adding adding it as a plugin dependency would work with both M2 and M3. But if You really need different configurations for M2 and M3, You could use different profiles that are automatically activated when the build is executed with M2 or M3. [1] shows how this could be achieved. One last question: How is the Your Maven repository realised? Reading Your posts, I assume that You might use an Apache server and copy the artifacts to the docroot (using the scp wagon). I'd suggest to use a repository manager, it provides You with several advantages over a simple docroot and normally work fine with the HTTP(S) protocols. See [2], it provides a list of the commonly used repository mangers along with some general information. Especially take a look at the feature matrix [3], it will help You to select the right one for Your needs - I'd suggest to take a closer look at Nexus ;) Kind regards Marc [1] https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-Usingmavensiteplugin2.xwithMaven2.xandmavensiteplugin3.xwithMaven3.x [2] http://maven.apache.org/repository-management.html [3] http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
John, Thank you very much for the reply. I have two setups, local and on a CI server, which is still running maven2. This did not work under maven2 on the CI server: http://jenkins.paneris.net/job/melati/134/console but I will try at work tomorrow under maven3. I guess not that many people maintain a private repository using scp, but I maintain 4 this way, so scp no longer being supported by default means that I have to find a way through this, ideally a setup which works for maven2 and maven3. thanks again Tim On 5 April 2011 20:07, John Casey wrote: > Try turning that extension into a dependency embedded in the > maven-deploy-plugin configuration, IIRC: > > > > > maven-deploy-plugin > 2.5 > > > org.apache.maven.wagon > wagon-ssh > 1.0-beta-7 > > > > > > > On 4/5/11 1:16 PM, Tim Pizey wrote: >> >> Hi, >> >> I have tried to update my project to use maven3 (version 3.0.2), >> however I can no longer deploy artifacts to my repository. >> >> I have found a number of notes about how to do this: >> >> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html >> >> Gives Transport Protocols (Wagons) Unlike Maven 2, Maven 3 supports out of the box only http:, https: and file: as transport protocols. >> >> Why? >> Surely scp is both a central use case and existing functionality. >> >> To use other transport protocols like scp:, the appropriate wagons have to be explicitly declared in the POM as a build extension. >> If the wagon in question is only used for deployment, it can alternatively be declared as a dependency of the Maven Deploy Plugin. For more information, see Guide to Using Extensions. >> >> I have everything set up as per >> >> http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html >> >> I have followed the recommeds in >> http://maven.40175.n5.nabble.com/Wagon-in-3-0-No-connector-td3256506.html >> and followed exactly >> http://johnsjavapda.blogspot.com/2010/11/maven-wagon.html >> >> As so often with these things I am upgrading Maven at the same time as >> using a new install on Window7, >> I have checked that I can scp to the repository. >> >> I have added the wagon jar to the MAVEN_HOME/lib directory >> >> >> I am using cgywin on windows7, the actual error is: >> >> [INFO] >> >> [INFO] BUILD FAILURE >> [INFO] >> >> [INFO] Total time: 29.056s >> [INFO] Finished at: Tue Apr 05 17:56:51 BST 2011 >> [INFO] Final Memory: 21M/534M >> [INFO] >> >> [ERROR] Failed to execute goal >> org.apache.maven.plugins:maven-deploy-plugin:2.5: >> deploy (default-deploy) on project melati-parent: Failed to deploy >> artifacts/met >> adata: No connector available to access repository melati_to >> (scp://melati.org/d >> ata/www/maven2/) of type default using the available factories >> WagonRepositoryCo >> nnectorFactory -> [Help 1] >> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute >> goal o >> rg.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on >> proje >> ct melati-parent: Failed to deploy artifacts/metadata: No connector >> available to >> access repository melati_to (scp://melati.org/data/www/maven2/) of type >> default >> using the available factories WagonRepositoryConnectorFactory >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor >> .java:217) >> at >> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor >> .java:153) >> >> >> thanks in advance >> Tim >> > > -- > John Casey > Developer, PMC Member - Apache Maven (http://maven.apache.org) > Blog: http://www.johnofalltrades.name/ > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Tim Pizey - http://pizey.net/~timp Centre for Genomics and Global Health - http://cggh.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Try turning that extension into a dependency embedded in the maven-deploy-plugin configuration, IIRC: maven-deploy-plugin 2.5 org.apache.maven.wagon wagon-ssh 1.0-beta-7 On 4/5/11 1:16 PM, Tim Pizey wrote: Hi, I have tried to update my project to use maven3 (version 3.0.2), however I can no longer deploy artifacts to my repository. I have found a number of notes about how to do this: https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html Gives Transport Protocols (Wagons) Unlike Maven 2, Maven 3 supports out of the box only http:, https: and file: as transport protocols. Why? Surely scp is both a central use case and existing functionality. To use other transport protocols like scp:, the appropriate wagons have to be explicitly declared in the POM as a build extension. If the wagon in question is only used for deployment, it can alternatively be declared as a dependency of the Maven Deploy Plugin. For more information, see Guide to Using Extensions. I have everything set up as per http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html I have followed the recommeds in http://maven.40175.n5.nabble.com/Wagon-in-3-0-No-connector-td3256506.html and followed exactly http://johnsjavapda.blogspot.com/2010/11/maven-wagon.html As so often with these things I am upgrading Maven at the same time as using a new install on Window7, I have checked that I can scp to the repository. I have added the wagon jar to the MAVEN_HOME/lib directory I am using cgywin on windows7, the actual error is: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 29.056s [INFO] Finished at: Tue Apr 05 17:56:51 BST 2011 [INFO] Final Memory: 21M/534M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5: deploy (default-deploy) on project melati-parent: Failed to deploy artifacts/met adata: No connector available to access repository melati_to (scp://melati.org/d ata/www/maven2/) of type default using the available factories WagonRepositoryCo nnectorFactory -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal o rg.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on proje ct melati-parent: Failed to deploy artifacts/metadata: No connector available to access repository melati_to (scp://melati.org/data/www/maven2/) of type default using the available factories WagonRepositoryConnectorFactory at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor .java:153) thanks in advance Tim -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
