Carlos, This is no problem, I can do any patch for acegi. What I'm asking is if there is a better way to handle this kind of problem. Would e.g. relocate jsp-api (as servlet-api is) solve the problem ? Maybe we can try this, I guess it has to be done anyway. Do you agree ?
-- Yann 2005/12/27, Carlos Sanchez <[EMAIL PROTECTED]>: > > You can probably exclude jspapi in acegi > > 1.0.0-RC1 has the right dependencies > > On 12/27/05, Yann Le Du <[EMAIL PROTECTED]> wrote: > > Hi, > > I noticed something potentially confusing with artifact relocations. > > > > Say I want to declare a 'provided' jsp-api 2.0 dependency : > > ~ <groupId>javax.servlet</groupId> > > ~ <artifactId>jsp-api</artifactId> > > ~ <version>2.0</version> > > ~ <scope>provided</scope> > > > > I also have a dependency upon acegi-security 0.8.2, which in turn > > unfortunately depends on jsp-api in the "old way" : > > ~ <groupId>jspapi</groupId> > > ~ <artifactId>jsp-api</artifactId> > > ~ <version>2.0</version> > > > > The result is that jsp-api-2.0.jar is included as a compile dependency. > > Of course, I could (and will) send a patch for acegi-security, but this > can > > happen on any other dependency - and I won't catch it. > > The only secure workaround I have found is to dup the dependency - not > very > > elegant : > > ~ <dependency> > > ~ <groupId>javax.servlet</groupId> > > ~ <artifactId>jsp-api</artifactId> > > ~ <version>2.0</version> > > ~ <scope>provided</scope> > > ~ </dependency> > > ~ <dependency> > > ~ <groupId>jspapi</groupId> > > ~ <artifactId>jsp-api</artifactId> > > ~ <version>2.0</version> > > ~ <scope>provided</scope> > > ~ </dependency> > > > > Thoughts ? > > -- > > Yann > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
