You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Tim Pizey <ti...@gmail.com> on 2011/04/05 19:16:28 UTC
Can no longer deploy project artifacts using maven3
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
--
Tim Pizey - http://pizey.net/~timp
Centre for Genomics and Global Health - http://cggh.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Tim Pizey <ti...@gmail.com>.
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 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.
I feel that that burden has been engineered by the dislocation of the
artefact from its
documentation.
> 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.
Fair point.
>> Why not have a default repo generated as part of the site
>> plugin?
>
>
> What's stopping you from implementing that?
I would love to, I struggle to make the time.
> 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.
Would the change be accepted if you thought it was a bad idea?
> I believe you are in the great minority using SCP to deploy, as such much of
> the burden to support this approach is yours.
I will need to catch up.
Presumably using basic-auth over https?
Thanks for your reply, it is very cool that the project lead still
finds time to reply to the user list.
cheers
Tim
--
Tim Pizey - http://pizey.net/~timp
Centre for Genomics and Global Health - http://cggh.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Jason van Zyl <ja...@sonatype.com>.
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 <ja...@sonatype.com> 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:
>>> <plugin>
>>> <artifactId>maven-deploy-plugin</artifactId>
>>> <version>2.5</version>
>>> <dependencies>
>>> <dependency>
>>> <groupId>org.apache.maven.wagon</groupId>
>>> <artifactId>wagon-ssh</artifactId>
>>> <version>1.0-beta-7</version>
>>> </dependency>
>>> </dependencies>
>>> </plugin>
>>>
>>> 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 <extension> 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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@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
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
Re: Can no longer deploy project artifacts using maven3
Posted by Tim Pizey <ti...@gmail.com>.
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 <ja...@sonatype.com> 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:
>> <plugin>
>> <artifactId>maven-deploy-plugin</artifactId>
>> <version>2.5</version>
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.maven.wagon</groupId>
>> <artifactId>wagon-ssh</artifactId>
>> <version>1.0-beta-7</version>
>> </dependency>
>> </dependencies>
>> </plugin>
>>
>> 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 <extension> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Jason van Zyl <ja...@sonatype.com>.
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:
> <plugin>
> <artifactId>maven-deploy-plugin</artifactId>
> <version>2.5</version>
> <dependencies>
> <dependency>
> <groupId>org.apache.maven.wagon</groupId>
> <artifactId>wagon-ssh</artifactId>
> <version>1.0-beta-7</version>
> </dependency>
> </dependencies>
> </plugin>
>
> 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 <extension> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@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
Posted by Tim Pizey <ti...@gmail.com>.
Hi,
I now have my project deploying using scp.
I added an explicit configuration for the deploy plugin to the pom:
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.5</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>1.0-beta-7</version>
</dependency>
</dependencies>
</plugin>
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 <extension> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Marc Rohlfs <po...@googlemail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Tim Pizey <ti...@gmail.com>.
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:
<distributionManagement>
<repository>
<id>melati</id>
<name>Melati M2 Repository</name>
<url>scp://melati.org/data/www/maven2/</url>
</repository>
<site>
<id>melati_site</id>
<url>scp://melati.org/data/www/melati/</url>
</site>
</distributionManagement>
> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Marc Rohlfs <po...@googlemail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by Tim Pizey <ti...@gmail.com>.
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:
>
> <build>
> <plugins>
> <plugin>
> <artifactId>maven-deploy-plugin</artifactId>
> <version>2.5</version>
> <dependencies>
> <dependency>
> <groupId>org.apache.maven.wagon</groupId>
> <artifactId>wagon-ssh</artifactId>
> <version>1.0-beta-7</version>
> </dependency>
> </dependencies>
> </plugin>
> </plugins>
> </build>
>
> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Tim Pizey - http://pizey.net/~timp
Centre for Genomics and Global Health - http://cggh.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Can no longer deploy project artifacts using maven3
Posted by John Casey <jd...@commonjava.org>.
Try turning that extension into a dependency embedded in the
maven-deploy-plugin configuration, IIRC:
<build>
<plugins>
<plugin>
<artifactId>maven-deploy-plugin</artifactId>
<version>2.5</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh</artifactId>
<version>1.0-beta-7</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org