Re: Dependencies that should not be on the classpath
On Fri, Oct 12, 2012 at 11:22 PM, Barrie Treloar baerr...@gmail.com 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. -- Chris Conroy
Re: Dependencies that should not be on the classpath
On Mon, Oct 15, 2012 at 12:19 PM, Chris Conroy ccon...@gmail.com wrote: On Fri, Oct 12, 2012 at 11:22 PM, Barrie Treloar baerr...@gmail.comwrote: 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
Re: Dependencies that should not be on the classpath
There's a real maven design problem here, if you ask me. Maven overloads the 'type' of an artifact. A 'war' dependency is legitimate and a different thing from a 'jar' dependency. Sadly, though, all jar files are equally treated as the output of the standard java lifecycle, suitable for classpath. Javadoc is a counterexample. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies that should not be on the classpath
On Fri, Oct 12, 2012 at 3:59 PM, Chris Conroy ccon...@gmail.com wrote: Is there any way to specify that a dependency should not be on the build classpath? I am using the maven-javadoc-plugin to generate an aggregate javadoc jar for my top level project. In a sub-project, I have a dependency on the javadoc jar so that I can serve the javadoc from a jetty server. This results in some strange behavior with m2e (full context here: http://www.mail-archive.com/m2e-users@eclipse.org/msg02900.html) that revealed that the javadoc jar is actually ending up on the build classpath. However, it doesn't really make sense for the javadoc jar to be on the build classpath. Is there any way that I can tell maven that something is a *non-Java *dependency that should get run at the right phase but should not be part of the build classpath? Rename it from .jar to .zip? That's a bunch of work, I'm afraid. -- Chris Conroy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Dependencies that should not be on the classpath
On Sat, Oct 13, 2012 at 6:29 AM, Chris Conroy ccon...@gmail.com wrote: Is there any way to specify that a dependency should not be on the build classpath? I am using the maven-javadoc-plugin to generate an aggregate javadoc jar for my top level project. In a sub-project, I have a dependency on the javadoc jar so that I can serve the javadoc from a jetty server. This results in some strange behavior with m2e (full context here: http://www.mail-archive.com/m2e-users@eclipse.org/msg02900.html) that revealed that the javadoc jar is actually ending up on the build classpath. However, it doesn't really make sense for the javadoc jar to be on the build classpath. Is there any way that I can tell maven that something is a *non-Java *dependency that should get run at the right phase but should not be part of the build classpath? 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. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org