Yeah, I did make one abortive attempt to implement this at one point, but I sort of lost my way and stopped before things got *really* ugly. Since then I've been waiting until I could see the solution clearly in my mind.
-j On 11/20/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 20 Nov 06, at 3:36 PM 20 Nov 06, John Casey wrote: > It surely can be. I didn't want to have an overly aggressive design > goal > with this initially; my only motivation was to provide easier > access to > maven-artifact*. > Yes, I think most people looking at it would agree it's a little complicated and does need to be simplified. > What I'd ACTUALLY love to do is create/expand a DAG during the POM > walking > that we do via the MavenMetadataSource currently, then go back and > attach > the resolved artifacts to the nodes of that DAG when we do the real > resolution. maven-artifact must have the complete graph in order to be useful. What's currently doing, I strongly assert, is not viable. In order to do any meaningful analysis requires the whole graph. I know we have a listener and you can build it but the graph is a first class citizen and is required as the strategies we develop must be applied to the graph not to the peephole we're using now. > That would give us the ability to reconstruct any subset of the > dependency graph without re-resolving, and would colocate POM metadata > alongside the artifact (which is also a huge PITA to recover at > times). Absolutely, you could decorate each node with any useful information. Jung has a very nifty model for this. They use it for visualization but the same notion would apply for us. Part of fixing many of the issues with maven-artifact I feel will be resolve by putting a real graph back into the fix. > Obviously, this API is nowhere near that sophisticated...if we were to > implement something like that in maven itself, and really take the > time to > see it from the plugin-developer's (AND external component- > developer's) > point of view, I'd have no problem scrapping this library in favor > of that. > I would just suggest trying to incorporate your ideas into maven- artifact sooner rather then later or it will become impossible. I think what you want is necessary for the long-term viability of maven- artifact. The graph must be there intact for analysis. > -john > > On 11/20/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >> >> On 20 Nov 06, at 2:01 PM 20 Nov 06, John Casey wrote: >> >> > It's meant to be a general-case API for using maven-artifact from >> > other >> > systems. The use case I've been working on is allowing >> Buckminster to >> > resolve components using Maven's artifact apis. >> > >> >> Is it an experiment the result of which will be rolled back into >> maven-artifact? >> >> jason. >> >> > -j >> > >> > On 11/18/06, Jason van Zyl <[EMAIL PROTECTED]> wrote: >> >> >> >> >> >> On 10 Nov 06, at 2:16 PM 10 Nov 06, [EMAIL PROTECTED] wrote: >> >> >> >> > Author: jdcasey >> >> > Date: Fri Nov 10 11:16:33 2006 >> >> > New Revision: 473433 >> >> > >> >> > URL: http://svn.apache.org/viewvc?view=rev&rev=473433 >> >> > Log: >> >> > Updates to support buckminster maven integration. >> >> > >> >> >> >> Cool, what does this entail. Being able to use Buckminster >> providers >> >> in Maven? Or Maven Artifact stuff in Buckminster? >> >> >> >> Jason. >> >> >> >> > >> >> > >> >> > >> >> > >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
