Re: Can no longer deploy project artifacts using maven3

2011-04-06 Thread Tim Pizey
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

2011-04-06 Thread Jason van Zyl

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

2011-04-06 Thread Tim Pizey
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

2011-04-06 Thread Jason van Zyl
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

2011-04-06 Thread Marc Rohlfs

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

2011-04-06 Thread Tim Pizey
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

2011-04-06 Thread Tim Pizey
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

2011-04-06 Thread Marc Rohlfs
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

2011-04-05 Thread Tim Pizey
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

2011-04-05 Thread John Casey
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