AFAIK, optional being true just marks the dep as not being required transitively, but if you can get your hands on it, then use it.
provided means that it's not required transitively... so if A.jar has optional on.jar B and provided on C.jar and you have D.war depending on A.jar then D.war/WEB-INF/lib will include B.jar and not C.jar _In_theory_, I suspect that if you could not find B.jar in any of your repo's then the build of D.war should not fail... but with the proviso that if you cannot get B.jar then building A.jar will fail. _In_practice_, I have always had to build A.jar so I have always had to have B.jar in my local repo and I have never been able to test what happens. Note: Kohsuke has used optional=true in hudson plugins to imply intra plugin optional dependencies, but he had to do work to make that happen. In general I avoid using the whole optional thing as it's just too unclear what it should mean... it may be one of those bits of crust that got into the pom that we have not removed because we cannot change the pom format until M3.1 -Stephen On 23 September 2010 19:41, Max Bowsher <m...@f2s.com> wrote: > It seems to me that in a Maven dependency, <scope>provided</scope> and > <optional>true</optional> have incredibly similar semantics (though > there is an implied difference in meaning to humans). > > > Is there actually any circumstances where one vs. the other produces > differing behaviour? > > Max. > >
