maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: #1 thoughts on the goal chain
Date Wed, 12 Jan 2005 09:55:01 GMT
Mark H. Wilkinson wrote:

>On Tue, 2005-01-11 at 20:20 +1100, Brett Porter wrote:
>  
>
>This is typically handled (in Unix make) by using virtual (or 'phony')
>targets: targets that exist in the dependency graph, but which don't map
>to real files in the file system. 
>
Isn't this what goals are now? What are we losing by using only them to 
build the dependencies?
Don't get me wrong - I think having each goal report on its required 
files and modified files is fantastic, but I don't think it should be 
the basis for connecting the mojos.

>There are two possible ways to handle this that I'm aware of:
>     1. The configuration information is held in a file somewhere, so
>        include that file (or files) in the dependency graph. At the
>        worst, touching ~/build.properties will cause everything to
>        rebuild.
>     2. Ignore configuration information held in files. Make the users
>        aware that changing configuration will normally require a build
>        from clean afterwards.
>  
>
I agree. I think we can afford to start at (2) and work at implementing (1).

>I don't imagine
>that this would be a problem for maven as I'm not suggesting that a
>representation of the dependency graph become part of the project source
>tree.
>  
>
Correct. There will probably be a static, installation wide cache of the 
base DAG, but it does get modified project to project, and caching that 
is probably not worthwhile.

>For the end users? I would expect that the standard plugins would
>include a number of convenience virtual targets. In the example in my
>previous email I included a 'jar:jar' virtual target that depended on
>the project's artifact being up to date. Normal operation for the end
>user will likely use the short names they are using today.
>  
>
I don't know that its good to leave such a wide gap between end users 
and developers. Users should be able to easily write plugins, and 
developers should be using the system day to day as a user would.

>>>     * The user can create any intermediate target. For example, you can
>>>       'm2 target/surefire-reports/org.codehaus.plexus.PlexusTestCaseTest.txt'
>>>      
>>>
>>I'm not sure this is entirely useful, sorry.
>>    
>>
>
>Our experiences must differ then - I've often wanted to regenerate a
>single report in the generated site over and over again (e.g. getting
>the checkstyle errors out of a source tree).
>  
>
Me too, but there's no way I'm typing that. I'd prefer the current m2 
surefire:test -Dtestcase=org.codehaus.plexus.PlexusTestCaseTest.
It's roughly the same length, but easier to read and unambiguous. In 
your example,

m2 target/surefire-reports/org.codehaus.plexus.PlexusTestCaseTest.*xml*

would do the same thing (and generate both the txt and xml versions 
again most likely). I think that kind of amiguity is harmful.

>Agreed - if antrl were required for the build it should be included in
>the POM. Perhaps that was a bad example. There are some other use cases
>where being able to just name a plugin on the command line would be
>useful:
>  
>
I think those given are all useful, and definitely are allowed to be run 
from the command line.

I'm not sure how passionately you want to stick to integrating file 
dependencies into the current mojo dependency scheme, but I Can think of 
a couple of things that would be helpful to get out from this:
1) apply timestamp checking rules to the existing goal based resolution 
to achieve the benefits you are aiming for
2) look for any specific flaws in the current resolution docs based on 
this argument so alternatives can be investigated

WDYT?

Thanks,
Brett


Mime
View raw message