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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
