IMHO this particular issue: integration of cactus plugin with eclipse plugin is affected by the problem which is lying elsewhere.
The problem is that generally support for different type of testing then unit testing is pratically not existing in maven. For example if cactus test cases were kept in separate, dedicated project this particular problem will almost disappear. "Almost" as the problem is that Maven at the moment (I am speaking about default distribution not proprietary plugins) is unable to work with the test cases (mostly based on extension of junit) kept main source tree. It is also unable to create jars/uberjars from test source tree or even notice that test source tree is existing if there in no main source tree I believe that when we will find structured standardized solution for organizing iu-tests most of such problems will really disappear and that the quality of testing will be improved as at the moment maven doesn't really encourage such practices (they are very painful). For example for my current project I have developed a test suite which is benchmarking performance of my application. After every major change in the architecture I am using this test suite for seeing how it is affecting the performance. The same can be done for memory consumption etc. <dream> When test reports (and reports generally) will be promoted to artifacts if will be possible to track performace changes and make complex statistiacl analyzis of them. Also it should be possible to measure the performace of given application with differnt configurations/set of components. It think that this would be really cool. There is a lot of crazy ideas waiting for implementation. E.g. what about using genetic algorithms + continous integration system + iu testing for finding the optimal configuration of given application (e.g. size of caches, number of connection to databases etc.) The truth is that very rarly people have time for performace tuning and it can be mostly automated. And I even doubt that human can do this better then genetic alogorithm if the domain space for genetic algorithm is correctly defined. </dream> Michal > -----Original Message----- > From: Eric Pugh [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 05, 2004 10:59 AM > To: 'Maven Developers List' > Subject: RE: RC2 > > > I think I was the guilty person on this one... > > I wanted to run maven eclipse and get my cactus code > registered as source > code. If this coupling is undesirable, then the property > maven.eclipse.classpath.include could be used instead: > > maven.eclipse.classpath.include src/test-cactus > > Eric > > > -----Original Message----- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: Thursday, February 05, 2004 3:51 AM > > To: 'Maven Developers List' > > Subject: RE: RC2 > > > > > > Hi Jason, > > > > > -----Original Message----- > > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > > Sent: 03 February 2004 22:12 > > > To: Maven Developers List > > > Subject: RE: RC2 > > > > > > On Tue, 2004-02-03 at 15:35, Vincent Massol wrote: > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > Sent: 03 February 2004 01:04 > > > > > To: Maven Developers List > > > > > Subject: RE: RC2 > > > > > > > > > > There's also a bug in the eclipse plugin which causes > it to fail > > > > without > > > > > cactus being present. > > > > > > > > > > I've 'fixed' it locally by commenting out the cactus > > support. What > > do > > > > you > > > > > think we should do? Is there an easy way now to test for the > > existence > > > > of > > > > > a plugin? Or do we add the cactus plugin as a dependency? > > > > > > > > I think we have 2 options: > > > > > > > > 1/ As you say, make it optional by checking the existence of the > > cactus > > > > plugin (or adding the cactus plugin as a dependency) > > > > > > > > 2/ Modifying the eclipse plugin implementation and making it > > pluggable. > > > > We would then move the logic related to Cactus in the > > cactus plugin. > > > > > > > > I'm not sure there's enough cactus-related plugin logic > to warrant > > > > option 2. However, I'm sure we'll need to support other > > "extensions" > > of > > > > the eclipse plugin for other tools so it might make sense > > to have a > > > > pluggable implementation. > > > > > > > > For 1/, would the following work: > > > > > > > > <j:if test="${pom.getPluginContext('cactus-maven') == null}"> > > > > > > Can I ask why there exists such a dependency in the first place? > > > > > > I'm just curious because obviously in some context the > cactus plugin > > is > > > providing some functionality, just wondering how and what and if a > > > cleaner way can be found as I'm sure this situation would arise in > > > relationships among other plugins. > > > > Actually I don't know. I'm not the one who made this > coupling between > > Eclipse plugin and Cactus plugin. I've just had a look at the plugin > > source code and it appears there is a conditional test: > > > > <maven:pluginVar var="cactusSrcDir" plugin='cactus-maven' > > property='cactus.src.dir' /> > > <util:available file="${cactusSrcDir}"> > > <j:set var="cactusSourcePresent" value="true"/> > > </util:available> > > > > and then, depending on whether cactus sources are present, the > > .classpath file for Eclipse is modified to add the cactus > sources and > > the cactus jar is added to the project's classpath. > > > > The need is not only for Cactus. It is the same for example > > for Aspects. > > Thus we could also imagine the same for the aspectj plugin, etc. > > > > I guess we can continue with this coupling as it is light > and provided > > we test for the existence of the plugin. Solution 2/ is better but I > > feel it is too heavyweight (for now at least). What do you think? > > > > Thanks > > -Vincent > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > -- > > > > > dIon Gillard, Multitask Consulting > > > > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > > > > > > > > > > > > > Brett Porter <[EMAIL PROTECTED]> wrote on 03/02/2004 > > 10:39:16 > > > > AM: > > > > > > > > > > > Thanks. > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > > > > Sent: Tuesday, 3 February 2004 10:46 AM > > > > > > > To: Maven Developers List > > > > > > > Subject: Re: RC2 > > > > > > > > > > > > > > > > > > > > > I just found one in the new batch file and fixed it. > > > > > > > > > > > > > > There's also a classloader issue when I try to run > > > > > > > multiproject:site for > > > > > > > maven-plugins. > > > > > > > > > > > > > > Will retest it after the latest bootstrap and file a Jira > > > > > > > report if it > > > > > > > still exists. > > > > > > > -- > > > > > > > dIon Gillard, Multitask Consulting > > > > > > > Blog: http://blogs.codehaus.org/people/dion/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > Brett Porter <[EMAIL PROTECTED]> wrote on > 03/02/2004 > > > > > > > 09:51:37 AM: > > > > > > > > > > > > > > > Only 2 bugs to go: > > > > > > > > > > http://jira.codehaus.org/secure/BrowseProject.jspa?id=10030 > > > > > > > > > > > > > > > > > <http://jira.codehaus.org/secure/BrowseProject.jspa?id=10030&r > > > > > > eport=roadmap> > > > > > > > &report=roadmap > > > > > > > > > > > > > > I'll try and knock them off in the next day or so. > > > > > > > > > > > > > > Anyone have any plugin bugs they wish to have fixed > > before we > > > > release > > > > > > RC2? > > > > > > > > > > > > > > I will also merge CVS back to HEAD when I next have the > > > > opportunity. > > > > > > > > > > > > > > Cheers, > > > > > > > Brett > > > > > > > > > > > > > > -- > > > > > > > Brett Porter > > > > > > > Team Leader, Core Systems > > > > > > > f2 network ~ everything essential > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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] > > > > > > -- > > > jvz. > > > > > > Jason van Zyl > > > [EMAIL PROTECTED] > > > 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 > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
