On Mon, Oct 15, 2012 at 12:19 PM, Chris Conroy <[email protected]> wrote:
> On Fri, Oct 12, 2012 at 11:22 PM, Barrie Treloar <[email protected]>wrote: > >> If you are just serving it from jetty you could use >> >> http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html >> to copy the aggregate jar into the web directory? >> >> Trying to wedge dependencies into this round hole may not be your best >> option. > > > I happen to be using the unpack option to stuff it into the child jar at > the moment, but in either case don't I still need to declare it as a > dependency in order to use unpack or copy from a subproject? Otherwise, I > won't have any guarantee that Maven has built the javadoc by the time it > gets to copying or unpacking it since it's not part of the dependency graph. > > It's not so much that I'm trying to wedge it into a round hole, but I need > an artifact to be built in the aggregator and to use it in the child. It > happens that this isn't a java artifact. If it's valid to do that without > declaring that dependency, then perhaps that fixes my problem (I'll > experiment with it), but hiding that information from the dependency graph > seems like I'd be asking for a successful build based on a lucky ordering > of the dependency graph. > Using the dependency implicitly as you suggest does seem to fix this issue (and another related one I hit with the maven release plugin). I'm not sure how future-proof it is to rely on the artifact from the aggregator project being built before one of its sub-modules, but this does look like the path of least resistance for the moment. -- Chris Conroy
