You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2008/03/01 00:40:31 UTC
Re: Wagon changes and WebDAV
On 01/03/2008, at 9:02 AM, Jason van Zyl wrote:
> Here's the direction I would like to go in:
>
> http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment
>
> Full support for all types of transport for retrieval and deployment
> in a standard way that doesn't bloat out the core.
Yes, I'm generally in favour of the proposal - it is how we've always
wanted it to work.
Comments on the proposal:
- I don't see anything that allows strictly versioning the providers.
This may not be a concern as I don't know if that really impacts
reproducibility of the build, but there does need to be a way to pin
it down. How about an optional element in the deployment target
(currently <repository> under distMgmt):
<provider>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ssh-external</artifactId>
<version>1.0</version>
</provider>
- +1 to move selected configuration into the distMgmt. However,
anything that might be overridden on a case-by-case basis (like
altDeploymentRepository) should not be in there
- I don't see any point of putting the deploy plugin version in there
- the standard mechanism is fine.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Wagon changes and WebDAV
Posted by Brett Porter <br...@apache.org>.
On 01/03/2008, at 11:30 AM, Jason van Zyl wrote:
>>
>> Yes, I'm generally in favour of the proposal - it is how we've
>> always wanted it to work.
>>
>
> I'm just chucking out ideas.
Yep, I just meant in reference to not needing to distribute stuff in
the core.
>>
>> - I don't see any point of putting the deploy plugin version in
>> there - the standard mechanism is fine.
>>
>
> It may not be the deploy plugin if it became a core version
> component, but what do you mean by the standard mechanism? In <build/
> > and <distributionManagement/> or do you mean the auto version
> selection?
Yeah, I think it's worth continuing to use the deploy plugin and
specifying it in the <build/> section (along with version and
configuration), but maybe scoping it back to the alternate deployment
scenarios (like altDeploymentRepository, deploy-file), and pushing
more of the standard configuration into distributionManagement like
you indicated (And that functionality into the core component if
relevant).
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Wagon changes and WebDAV
Posted by Jason van Zyl <ja...@maven.org>.
On 29-Feb-08, at 3:40 PM, Brett Porter wrote:
>
> On 01/03/2008, at 9:02 AM, Jason van Zyl wrote:
>
>> Here's the direction I would like to go in:
>>
>> http://docs.codehaus.org/display/MAVEN/URL-based+dynamic+loading+of+providers+for+artifact+retrieval+and+deployment
>>
>> Full support for all types of transport for retrieval and
>> deployment in a standard way that doesn't bloat out the core.
>
> Yes, I'm generally in favour of the proposal - it is how we've
> always wanted it to work.
>
I'm just chucking out ideas.
> Comments on the proposal:
> - I don't see anything that allows strictly versioning the
> providers. This may not be a concern as I don't know if that really
> impacts reproducibility of the build, but there does need to be a
> way to pin it down. How about an optional element in the deployment
> target (currently <repository> under distMgmt):
> <provider>
> <groupId>org.apache.maven.wagon</groupId>
> <artifactId>wagon-ssh-external</artifactId>
> <version>1.0</version>
> </provider>
>
> - +1 to move selected configuration into the distMgmt. However,
> anything that might be overridden on a case-by-case basis (like
> altDeploymentRepository) should not be in there
> - I don't see any point of putting the deploy plugin version in
> there - the standard mechanism is fine.
>
It may not be the deploy plugin if it became a core version component,
but what do you mean by the standard mechanism? In <build/> and
<distributionManagement/> or do you mean the auto version selection?
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org