update

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

Hi,

Most of the plugin work is now done. I think we're pretty close to a
final format with the @tags. I made one addition today which is:

@requiresDependencyResolution

So that a goal can indicate whether or not it requires transitive
dependency resolution. 

I also pushed the processing of transitive dependencies into the
lifecycle and I will continue to pull some pieces out of the
MavenProjectBuilder and place them into the lifecyle. For example, the
inheritance mechanism now uses a non-filesystem mechanism for specifying
parents so the POMs can be pulled down from a repository. Obviously
being online affects this, how errors are reported and so on. I also
want to push anything important into a lifecycle phase which is small
and hopefully the whole lifecycle will be comprehensible after a couple
hours of browsing.

The next thing I would like to do is try to get the transparent plugin
downloading working. So I've got a phase and I can pick off the pluginId
and from there we have a few things to work out.

Michal, you've got some install code that can be used and I will
probably use a reference to the ArtifactDownloader in the phase which
brings down plugins. So this may force us to deal with plugins like in
the way we were discussing with plexus components where the components
are used from a repository. The ArtifactDownloader wants to move a
MavenArtifact to a repository so I'm just starting to think about what
this means wrt artifact handlers and if this can be the case where we
make the first artifact handler to deal with plugins. Anyway, I'll
continue pushing more bits and bobs into the lifecycle but I would like
to knock off plugin downloading so that the plugins in the mojo project
can be used transparently.

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: update

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

On Tue, 2004-06-15 at 21:27, Brett Porter wrote:

> I guess I do. Why would compile need to follow transitive dependencies? 

To pull down all the dependencies so that you can compile the project if
you have only have, say, plexus listed in your POM. Often times you have
references that need to be resolved even though they may not be strictly
used in your code. I did it in compile and then they are there for
testing but the testing goal could also state it for clarity. Won't
hurt, the stuff won't get downloaded again.

> If
> webwork requires commons-io to compile/execute, but I only use webwork classes,
> I don't need commons-io to compile - just to run, right?

You would think so but often not the case. I did it in compile to be
safe and they will have to come down for testing at any rate.

> - Brett

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: update

[Brett Porter <br...@apache.org>]

> I'm not sure what you mean by "optional first-level dependency
> resolution". Do you mean just parsing the POM for the dependencies
> listed in the POM? If so that's not dependency resolution. We can rename
> it to something like "requiresTransitiveDependencyResolution", I just
> thought that was a little long.

I was referring to the difference between maven clean and maven java:compile -
clean doesn't resolve deps at all, java:compile resolves deps in that project,
war probably resolves all transitive deps too. 

> 
> > Also, what is the user case for enabling/disabling transitive dependency
> > resolution? I assume you disable on compilation, enable on building things
> like
> > WARs?
> 
> Currently the only goal that calls for full dependency resolution is the
> compile goal. I think you have the notion backward. Any goal can say
> whether they want it or not but something like the "clean" goal would
> never 
> 

I guess I do. Why would compile need to follow transitive dependencies? If
webwork requires commons-io to compile/execute, but I only use webwork classes,
I don't need commons-io to compile - just to run, right?

- Brett

Re: update

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

On Tue, 2004-06-15 at 19:45, Brett Porter wrote:
> > @requiresDependencyResolution
> > 
> > So that a goal can indicate whether or not it requires transitive
> > dependency resolution. 
> 
> This is a bit misleading - isn't there also optional first-level dependency
> resolution? How is that handled?

I'm not sure what you mean by "optional first-level dependency
resolution". Do you mean just parsing the POM for the dependencies
listed in the POM? If so that's not dependency resolution. We can rename
it to something like "requiresTransitiveDependencyResolution", I just
thought that was a little long.

> Also, what is the user case for enabling/disabling transitive dependency
> resolution? I assume you disable on compilation, enable on building things like
> WARs?

Currently the only goal that calls for full dependency resolution is the
compile goal. I think you have the notion backward. Any goal can say
whether they want it or not but something like the "clean" goal would
never 

> Thanks,
> Brett

-- 
jvz.

Jason van Zyl
jason@maven.org
http://maven.apache.org

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

 -- Thoreau 

Re: update

[Brett Porter <br...@apache.org>]

> @requiresDependencyResolution
> 
> So that a goal can indicate whether or not it requires transitive
> dependency resolution. 

This is a bit misleading - isn't there also optional first-level dependency
resolution? How is that handled?

Also, what is the user case for enabling/disabling transitive dependency
resolution? I assume you disable on compilation, enable on building things like
WARs?

Thanks,
Brett