[m2] Project relative dependencies

[John Fallows <jo...@gmail.com>]

My company uses a homegrown version control system that manages
dependencies by presenting a unified "view" of both sources and
dependent JARs.  Therefore, the auto-download mechanism used by Maven
to resolve dependencies is not required.

However, Maven2 presents many other advantages that we would like to
leverage.  Is it possible to override the dependency resolution
behavior such that dependencies could be resolved to local JARs in the
"view", rather than requiring a remote or local Maven2 repository?

Given that design discussions are currently in progress for Maven2,
hopefully this would be good timing to include the JAR override
usecase, if it is not already supported or planned.

Kind Regards,
John Fallows

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[Brett Porter <br...@gmail.com>]

> On 5/29/05, Brett Porter <br...@gmail.com> wrote:
> > On 5/28/05, John Fallows <jo...@gmail.com> wrote:
>
> I was having difficulty in getting m2-a2 to recognize additional
> repository entries other than the default "central" one.  I was also
> having difficulty overriding the "central" repository definition.  Are
> these known issues targeted for m2-a3?

Recognising additional ones from the POM should work just fine - but
it may be related to the other issue you've listed, where overriding
doesn't work. That is in JIRA - if you could post additional details
(what settings you added to the POM) we can look into that as well.

> When I change the central repository mirror url to "custom://..." for
> dependency retrieval, I get an error: "custom" unrecognized protocol
> during dependency artifact resolution.

Ah, that's also a bug then. I can fix that relatively easily. I'll
drop it into JIRA first though.

Thanks,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[John Fallows <jo...@gmail.com>]

Brett,

Thanks for the pointers, see below.

On 5/29/05, Brett Porter <br...@gmail.com> wrote:
> On 5/28/05, John Fallows <jo...@gmail.com> wrote:
> > Perhaps we could also create a custom wagon implementation, similar to
> > the FileWagon, but resolve the dependencies from a project-relative
> > location?
> 
> This is the recommended way. However the requests you will get will be
> in the repository layout, so you may need to map those paths. Wagon is
> not aware of any Maven specifics.
> 
> > How does one register such a custom wagon implementation with Maven2?
> 
> For now - drop it into the lib directory.

I have created a custom wagon implementation that seems to meet our
current repository needs.  It uses a custom protocol in the syntax,
eg. "custom://...", and the wagon uses "custom" as the role hint in
the plexus component metadata.

It can successfully deploy using the "custom" protocol, which is great!  

I was having difficulty in getting m2-a2 to recognize additional
repository entries other than the default "central" one.  I was also
having difficulty overriding the "central" repository definition.  Are
these known issues targeted for m2-a3?

So, as a workaround, I have been using a mirror of central in
settings.xml instead.

When I change the central repository mirror url to "custom://..." for
dependency retrieval, I get an error: "custom" unrecognized protocol
during dependency artifact resolution.

This appears to be happening because the lightweight http wagon is
still used for downloads, and it is trying to create a URL object with
protocol "custom". Of course, it fails because Java has no
URLStreamHandler for the "custom" protocol.

So, is it a bug that the "custom" wagon is not being used for
dependency retrieval, or is some additional step required beyond
dropping the "custom" wagon jar into the lib directory?

Perhaps the http wagon is being used because the central repository
url is http protocol, even though the mirror is "custom" protocol?

Kind Regards,
John Fallows.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[Brett Porter <br...@gmail.com>]

On 5/28/05, John Fallows <jo...@gmail.com> wrote:
> Perhaps we could also create a custom wagon implementation, similar to
> the FileWagon, but resolve the dependencies from a project-relative
> location?

This is the recommended way. However the requests you will get will be
in the repository layout, so you may need to map those paths. Wagon is
not aware of any Maven specifics.

> How does one register such a custom wagon implementation with Maven2?

For now - drop it into the lib directory.

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[John Fallows <jo...@gmail.com>]

Brett,

So I did some more digging, and found your custom wagon implementation
that can manage storage and retrieval of artifacts via CVS or
Subversion.

http://blogs.codehaus.org/people/brett/archives/001066_storing_your_maven_repository_in_cvssubversion.html

Perhaps we could also create a custom wagon implementation, similar to
the FileWagon, but resolve the dependencies from a project-relative
location?

How does one register such a custom wagon implementation with Maven2?

This would seem to have the downside of copying the artifact from the
project-relative location to the local repository cache in the user's
homedir, but it's a start - and it's probably a smaller delta from
this to using Maven2 with a real central repository.

Kind Regards,
John Fallows.

On 5/27/05, Brett Porter <br...@gmail.com> wrote:
> (copying to users list for the record)
> 
> On 5/27/05, John Fallows <jo...@gmail.com> wrote:
> > Hi Brett,
> >
> > I understand.  What I'm asking for is for Maven2 to make the
> > "dependency resolver" API pluggable, so that we can configure our
> > projects to use a custom implementation of a common API, without
> > needing to compile a custom Maven2 build, and making it much easier to
> > uptake new Maven2 releases.
> >
> > Our corporate version control solution delivers the JARs along with
> > the source as a unified "view".  Although the implementation is
> > different, you can think of it as though the JARs were checked in to
> > source control.
> >
> > Right now, we have a mixture of Makefiles and Ant build scripts that
> > reference these JARs using project-relative paths so that the builds
> > are self contained.
> >
> > We would need to replace the "dependency resolver" implementation to
> > map each [groupId, artifactId, version] to a project-relative path,
> > pointing at each "checked-in" JAR.  We do not need automatic
> > transitive dependency resolution, nor automatic download of
> > dependencies.  We would trigger build failure if a dependency in the
> > POM was not mapped locally.
> >
> > Kind Regards,
> > John Fallows.
> >
> > On 5/27/05, Brett Porter <br...@gmail.com> wrote:
> > > Can you detail more about your custom solution, and what it does?
> > >
> > > As you'll see from our comments, because this does away with a whole
> > > lot of Maven's features what you'd be faced with is probably
> > > recompiling your own Maven distribution from source, with your own
> > > resolver implementation (it shouldn't require any changes to Maven's
> > > code, just the configuration).
> > >
> > > - Brett
> > >
> > > On 5/27/05, John Fallows <jo...@gmail.com> wrote:
> > > > Hey Brett,
> > > >
> > > > I commented on the doc at
> > > >
> > > > http://docs.codehaus.org/display/MAVEN/Custom+Repository+or+Resolver+Implementations
> > > >
> > > > In short, we can live without transitive dependencies, since we want
> > > > to control every single dependency ourselves.
> > > >
> > > > Kind Regards,
> > > > John Fallows.
> > > >
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[Brett Porter <br...@gmail.com>]

(copying to users list for the record)

On 5/27/05, John Fallows <jo...@gmail.com> wrote:
> Hi Brett,
> 
> I understand.  What I'm asking for is for Maven2 to make the
> "dependency resolver" API pluggable, so that we can configure our
> projects to use a custom implementation of a common API, without
> needing to compile a custom Maven2 build, and making it much easier to
> uptake new Maven2 releases.
> 
> Our corporate version control solution delivers the JARs along with
> the source as a unified "view".  Although the implementation is
> different, you can think of it as though the JARs were checked in to
> source control.
> 
> Right now, we have a mixture of Makefiles and Ant build scripts that
> reference these JARs using project-relative paths so that the builds
> are self contained.
> 
> We would need to replace the "dependency resolver" implementation to
> map each [groupId, artifactId, version] to a project-relative path,
> pointing at each "checked-in" JAR.  We do not need automatic
> transitive dependency resolution, nor automatic download of
> dependencies.  We would trigger build failure if a dependency in the
> POM was not mapped locally.
> 
> Kind Regards,
> John Fallows.
> 
> On 5/27/05, Brett Porter <br...@gmail.com> wrote:
> > Can you detail more about your custom solution, and what it does?
> >
> > As you'll see from our comments, because this does away with a whole
> > lot of Maven's features what you'd be faced with is probably
> > recompiling your own Maven distribution from source, with your own
> > resolver implementation (it shouldn't require any changes to Maven's
> > code, just the configuration).
> >
> > - Brett
> >
> > On 5/27/05, John Fallows <jo...@gmail.com> wrote:
> > > Hey Brett,
> > >
> > > I commented on the doc at
> > >
> > > http://docs.codehaus.org/display/MAVEN/Custom+Repository+or+Resolver+Implementations
> > >
> > > In short, we can live without transitive dependencies, since we want
> > > to control every single dependency ourselves.
> > >
> > > Kind Regards,
> > > John Fallows.
> > >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[Brett Porter <br...@gmail.com>]

Can you detail more about your custom solution, and what it does? 

As you'll see from our comments, because this does away with a whole
lot of Maven's features what you'd be faced with is probably
recompiling your own Maven distribution from source, with your own
resolver implementation (it shouldn't require any changes to Maven's
code, just the configuration).

- Brett

On 5/27/05, John Fallows <jo...@gmail.com> wrote:
> Hey Brett,
> 
> I commented on the doc at
> 
> http://docs.codehaus.org/display/MAVEN/Custom+Repository+or+Resolver+Implementations
> 
> In short, we can live without transitive dependencies, since we want
> to control every single dependency ourselves.
> 
> Kind Regards,
> John Fallows.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[Brett Porter <br...@gmail.com>]

http://docs.codehaus.org/display/MAVEN/Custom+Repository+or+Resolver+Implementations

It's not immediately possible to drop in alternative implementations,
so it will take some time for us to work this one through.

If you are wondering why we can't support file based jar overrides out
of the box - it would not work with transitive dependencies.

Your best bet is to setup an internal m2 repository at the moment, or
work with us on the above design topic.

Thanks,
Brett

On 5/23/05, John Fallows <jo...@gmail.com> wrote:
> Thanks for the update Brett.
> 
> > I will discuss this with the Maven developers. While jar overrides
> > themselves (in the m1 sense) won't be supported, alternate repository
> > implementations might (so you could write your own).
> 
> I'd be happy enough to write a replacement dependency resolution
> implementation, I just need a good hook.  It would be a real shame to
> have to drop M2 simply because of this initial hurdle.
> 
> Later on we might be able to go a bit further and introduce a central
> M2 repos as well, but for now we need the ability to take baby steps.
> 
> Kind Regards,
> John Fallows.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: [m2] Project relative dependencies

[Brett Porter <br...@gmail.com>]

John,

I will discuss this with the Maven developers. While jar overrides
themselves (in the m1 sense) won't be supported, alternate repository
implementations might (so you could write your own).

- Brett

On 5/20/05, John Fallows <jo...@gmail.com> wrote:
> My company uses a homegrown version control system that manages
> dependencies by presenting a unified "view" of both sources and
> dependent JARs.  Therefore, the auto-download mechanism used by Maven
> to resolve dependencies is not required.
> 
> However, Maven2 presents many other advantages that we would like to
> leverage.  Is it possible to override the dependency resolution
> behavior such that dependencies could be resolved to local JARs in the
> "view", rather than requiring a remote or local Maven2 repository?
> 
> Given that design discussions are currently in progress for Maven2,
> hopefully this would be good timing to include the JAR override
> usecase, if it is not already supported or planned.
> 
> Kind Regards,
> John Fallows
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org