Maven proxies / Let's get together

[Tamás Cservenák <t....@gmail.com>]

Hello all,

since the first maven proxy appeared, the well known maven-proxy on
codehaus, things changed. Slightly.

Now, we have (or soon will have) these:

Archiva
Artifactory
Gatekeeper
Proximity

All of these are able to act as "maven proxy" and a few (or a lot of)
things more than that. Every one of them will have its own strength
(or weakness), it's own goal and it's own targeted users.

But do not forget, in these "proxies" we have pretty much more stuff
then just proxies!

All of them does some pretty much similar things, like indexing for
example. Till now, we have showed a "bad" face of open source:
divergence. We were divergating in maven proxy theme. We now have even
blogs comparing one proxy tool to another, and silly comments on them
:)

And now is, I think , time to take different direction and show some
convergence ability too!

All these tools are more or less RMs (repository managers) than "just"
plain vanilla proxies.

I think, there is a need -- not on behalf either of proxies and it's
developers, but on behalf of broad Maven community -- to make some non
proxy Maven related tools (like Maven plugin for Eclipse or whatever
else) better. And I think those tools would benefit, with some
standard API's on proxy side (eg. some common remoting iface, or
common index format, make SLP obligatory on proxies and make some
common proxy plugin for maven, etc).  And I think proxy side would
benefit of those tools too.

----

Let's reformulate this from a plain Maven developer's perspective:

I, developer using Maven, would like to use XXX independently of my
deployed maven proxy.
I would like to use Maven from my laptop in my company (with some
super-duper 'corporate' level maven proxy), but also to use the same
laptop from my home LAN (with some modest 'entry' level maven proxy).

(XXX is some tool, could be Maven plugin for Eclipse/Netbeans/IDEA, for example)

----

Here are some points I am suggesting:

We, as a maven community, could define some ruleset for a proxies to
be "Maven compliant".

We could define extra, extended set of requirements as, for instance,
SLP compliance.

We could define  some API (remote? WS?) to interrogate proxy's capabilities.

We could define some common downloadable repo index format (or more
levels of them, like full, medium, basic indexes).

We could define some API to issue queries against proxy and get some
standard responses.

Then, we (maven community) could make ONE proxy plugin and do this
irrespectively of deployed proxy "brand":

There will be still plenty of room for maven-archiva-plugin or
maven-gatekeeper-plugin, but all your basics need would be solved by
this one plugin.

-----

Here is some ideas - example of what I would be thrilled to have:

$ mvn proxy:setup

... locates proxy, queries it's capabilities, modifies your
settings.xml appropriately.

$ mvn proxy:info

... show the exact address, location, capabilities of the used proxy,
proxied reposes, etc

$ mvn proxy:search -Dsearch=SomeSearchQuery

... list items

etc. But, these functionalities could be usable from some Eclipse
plugin, Netbeans plugin, etc. since they are reached by some standard
WS API.

I know this is far away from now, but I'm sure that every proxy
community could -- for start -- do some little steps in this
direction, even at costs of hacks in the first round.

-------

And at the end, you may thinking: "why the hell should we make a proxy
SLP or WS enabled?" I used the term "proxy" throughout this text, but
as I stated on the beginning: all these proxies (applies even to
obsoleted maven-proxy!) are NOT just proxies, they are a lot more.
Just calling them "proxy" suited me, even if I made an intentional
mistake by doing it.

These ideas or similar to these ideas were already (partially?)
visioned/presented by jvanzyl on IRC. I just did not see some
responses about it.

Any thoughts?

Have fun,
~t~

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

Re: Maven proxies / Let's get together

[Jason van Zyl <ja...@maven.org>]

On 1 Jun 07, at 12:02 PM 1 Jun 07, Tamás Cservenák wrote:

> Hello,
>
> no, i'm not talking about bringing them under one project.
>
> I think it is too late for that. IMHO, every MRM (MRM as Maven Repo  
> Manager
> and not Archiva predecessor) team achieved a lot, and it would be
> irrealistic to expect from them to throw it away or dissect it. And  
> even if
> they do, the result would be very probably a MRM called  
> "Frankenstein, the
> most versatile Maven Repository Manager" that would never work :)
>

I think this is the best approach and I think that applications based  
around maven should be ejected from Maven itself and either go TLP or  
somewhere else. As a group we should be focusing on the core apis and  
tools which are suffering I believe because of a focus on tools.

> I was talking about common MRM API defined by Maven (maven  
> community, not
> MRM developers/community). This common API could be implemented by  
> various
> MRMs fully or partially (depending on their MRM capabilities).
>
> And also, all "maven tools" like maven plugins or 3rd party tools  
> could use
> this API to gain some benefit regardless of actual MRM on the far  
> end. Like
> the mentioned m2eclipse or netbeans plugin, to reach remote repo  
> indexes for
> example, etc.
>
>
> ~t~
>
>
> On 6/1/07, Tim Moloney <t....@verizon.net> wrote:
>>
>> Since you said that all of the current maven proxies are essentially
>> repository managers and you are suggesting that we combine them  
>> and all
>> of their features into one project...

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------




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

Re: Maven proxies / Let's get together

[Tamás Cservenák <t....@gmail.com>]

Hello,

no, i'm not talking about bringing them under one project.

I think it is too late for that. IMHO, every MRM (MRM as Maven Repo Manager
and not Archiva predecessor) team achieved a lot, and it would be
irrealistic to expect from them to throw it away or dissect it. And even if
they do, the result would be very probably a MRM called "Frankenstein, the
most versatile Maven Repository Manager" that would never work :)

I was talking about common MRM API defined by Maven (maven community, not
MRM developers/community). This common API could be implemented by various
MRMs fully or partially (depending on their MRM capabilities).

And also, all "maven tools" like maven plugins or 3rd party tools could use
this API to gain some benefit regardless of actual MRM on the far end. Like
the mentioned m2eclipse or netbeans plugin, to reach remote repo indexes for
example, etc.


~t~


On 6/1/07, Tim Moloney <t....@verizon.net> wrote:
>
> Since you said that all of the current maven proxies are essentially
> repository managers and you are suggesting that we combine them and all
> of their features into one project...

Re: Maven proxies / Let's get together

[Tim Moloney <t....@verizon.net>]

This email message caught my attention because I am about to start 
investigating the different maven proxies available.

Since you said that all of the current maven proxies are essentially 
repository managers and you are suggesting that we combine them and all 
of their features into one project, I would like to suggest that the 
combined proxy/resource manager also support managing OSGi Bundle 
Repositories (OBRs).

Apache's implementation of OSGi, Felix, uses Maven as its build tool and 
it would be very convenient to have all of these projects work together 
seamlessly.

Tim


Tamás Cservenák wrote:
> Hello all,
>
> since the first maven proxy appeared, the well known maven-proxy on
> codehaus, things changed. Slightly.
>
> Now, we have (or soon will have) these:
>
> Archiva
> Artifactory
> Gatekeeper
> Proximity
>
> All of these are able to act as "maven proxy" and a few (or a lot of)
> things more than that. Every one of them will have its own strength
> (or weakness), it's own goal and it's own targeted users.
>
> But do not forget, in these "proxies" we have pretty much more stuff
> then just proxies!
>
> All of them does some pretty much similar things, like indexing for
> example. Till now, we have showed a "bad" face of open source:
> divergence. We were divergating in maven proxy theme. We now have even
> blogs comparing one proxy tool to another, and silly comments on them
> :)
>
> And now is, I think , time to take different direction and show some
> convergence ability too!
>
> All these tools are more or less RMs (repository managers) than "just"
> plain vanilla proxies.
>
> I think, there is a need -- not on behalf either of proxies and it's
> developers, but on behalf of broad Maven community -- to make some non
> proxy Maven related tools (like Maven plugin for Eclipse or whatever
> else) better. And I think those tools would benefit, with some
> standard API's on proxy side (eg. some common remoting iface, or
> common index format, make SLP obligatory on proxies and make some
> common proxy plugin for maven, etc).  And I think proxy side would
> benefit of those tools too.
>
> ----
>
> Let's reformulate this from a plain Maven developer's perspective:
>
> I, developer using Maven, would like to use XXX independently of my
> deployed maven proxy.
> I would like to use Maven from my laptop in my company (with some
> super-duper 'corporate' level maven proxy), but also to use the same
> laptop from my home LAN (with some modest 'entry' level maven proxy).
>
> (XXX is some tool, could be Maven plugin for Eclipse/Netbeans/IDEA, 
> for example)
>
> ----
>
> Here are some points I am suggesting:
>
> We, as a maven community, could define some ruleset for a proxies to
> be "Maven compliant".
>
> We could define extra, extended set of requirements as, for instance,
> SLP compliance.
>
> We could define  some API (remote? WS?) to interrogate proxy's 
> capabilities.
>
> We could define some common downloadable repo index format (or more
> levels of them, like full, medium, basic indexes).
>
> We could define some API to issue queries against proxy and get some
> standard responses.
>
> Then, we (maven community) could make ONE proxy plugin and do this
> irrespectively of deployed proxy "brand":
>
> There will be still plenty of room for maven-archiva-plugin or
> maven-gatekeeper-plugin, but all your basics need would be solved by
> this one plugin.
>
> -----
>
> Here is some ideas - example of what I would be thrilled to have:
>
> $ mvn proxy:setup
>
> ... locates proxy, queries it's capabilities, modifies your
> settings.xml appropriately.
>
> $ mvn proxy:info
>
> ... show the exact address, location, capabilities of the used proxy,
> proxied reposes, etc
>
> $ mvn proxy:search -Dsearch=SomeSearchQuery
>
> ... list items
>
> etc. But, these functionalities could be usable from some Eclipse
> plugin, Netbeans plugin, etc. since they are reached by some standard
> WS API.
>
> I know this is far away from now, but I'm sure that every proxy
> community could -- for start -- do some little steps in this
> direction, even at costs of hacks in the first round.
>
> -------
>
> And at the end, you may thinking: "why the hell should we make a proxy
> SLP or WS enabled?" I used the term "proxy" throughout this text, but
> as I stated on the beginning: all these proxies (applies even to
> obsoleted maven-proxy!) are NOT just proxies, they are a lot more.
> Just calling them "proxy" suited me, even if I made an intentional
> mistake by doing it.
>
> These ideas or similar to these ideas were already (partially?)
> visioned/presented by jvanzyl on IRC. I just did not see some
> responses about it.
>
> Any thoughts?
>
> Have fun,
> ~t~
>
> ---------------------------------------------------------------------
> 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