Are these dependencies part of a JAR, or some other type? There should definitely be a way to generically exclude - but if they are not in a jar, then it won't be anyway. Maybe a zip is more useful if it is not intended to be on the classpath and instead just be extracted?
- Brett On 6/3/05, Bart Selders <[EMAIL PROTECTED]> wrote: > I have another reason for excluding dependencies from the classpath (m2). > > I am currently using the concept to specify an external resource (for > example a packaged CSS style library) as a dependency in my pom, and > then using a plugin to process that resource - possibly extract it in my > webapp. For that reason I need a way to tell that this dependency should > *not* be included in any of the current scopes, as this dependency is > not something for on the classpath. > > This dependency is i.m.o. not part of the plugin; Rather I want the pom > to specify/overrride which version of this resource must be used. > > But may be you see a better solution for this use case... > > Bart > > > Jason van Zyl wrote: > > On Thu, 2005-06-02 at 10:44 -0400, McGarr, Joseph M. wrote: > > > >>Thanks for the response. To answer your questions plainly, yes, this > >>happens to be a case where the container is providing the dependency at > >>runtime. So my resulting use case would be that I need a method to exclude > >>a dependency from the runtime classpath, which means it should not be > >>packaged with that dependency. Do you need more information? > > > > > > No that's great. This appears to be the case so far where people are > > developing container applications and they need to compile artifacts > > provided by the container environment but you obviously don't need to > > bundle them. > > > > > > > ************************************************************************* > The information contained in this communication is confidential and is > intended solely for the use of the individual or entity to whom it is > addressed.You should not copy, disclose or distribute this communication > without the authority of iBanx bv. iBanx bv is neither liable for > the proper and complete transmission of the information has been maintained > nor that the communication is free of viruses, interceptions or > interference. > > If you are not the intended recipient of this communication please return > the communication to the sender and delete and destroy all copies. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
