On 11/22/05, Chris Berry <[EMAIL PROTECTED]> wrote: > My need is for WSDL file dependencies. If I am building, say, a web service > which makes use of other web services, then I need only the WSDL of those > web services -- then from it I create the necessary interface code using a > code generator (Axis' WSDL2Java). This is a true dependency and should be > treated as such. I do not think this should be treated as a external > resource when it is truly a dependency.
In this case, you'd need to create a POM, and we'd need to have some way for the POM to point at the resource outside of the repository. Is that what you are suggesting? > In my experiece, these properties are application specific and are typically > related to the build for the project at hand. And for larger organizations > with build systems there is often a uniformity in these properties for all > internal projects. That's our experience too, which is why we gave the power of configuring it to the final POM in the form of an artifact filter fed to plugin configuration. This probably isn't documented well enough - I have noted it in JIRA as something needing attention. Basically this takes your suggestion: > I wonder if the answer to this dilemma is to only allow properties at the > base project level, and to ignore them at the child levels?? But pushes the configuration into the plugin configuration to avoid confusion. We also highly recommend using some sort of sensible default to minimise the amount of configuration - for example, the war plugin uses all compile/runtime but not test time or "provided" dependencies. That said, the war plugin doesn't allow you to filter the artifacts yet, and it should. I hope that clears it up, sorry for the delay in replying. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
