Jason van Zyl wrote:
> Look at the jakarta-commons/logging module. I implemented a little > mechanism for excluding sources: > > <build> > <sourceModifications> > <sourceModification> > <className>java.util.logging.Logger</className> > <excludes> > <exclude>**/Jdk14Logger.java</exclude> > </excludes> > </sourceModification> > </sourceModifications> > </build> > > So what that does is exclude the Jdk14Logger source file if the > java.util.logging.Logger class isn't present. I've read dirver.jelly and plugins/java-.../plugin.jelly, so I know how <sourceModifications> work. I just think that it is not flexible enough to help me. In the common scenario, people want to disable compilation of this or that class if a jar it depends on is not available in the build environment. <sM> are cool for that. But I'm facing another situation: I have classes that implement a set of interfaces that was incompatibly modified between JDK versions. I might have created two versions of each class, use conditional exclusion for them (notice that <sM> would not help me, unless I found a class that is present in JDK1.3 and not present in JDK1.4!) and then, at runtime check the java.specification.version property and instantiate the right classes. This is quite a lot of fuss. My solution with split source trees eliminates the need for runtime implementaiton switching. Anyway thanks. Maybe I shouldn't be wasting your time writing about a problem that I have already solved. I'm just excited with Maven, so I wanted to write *something*. Maven is just so cool that I haven't any serious problems yet :-) Rafal -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
