You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Yann Le Du <le...@gmail.com> on 2005/12/27 18:16:46 UTC
[m2] Artifact relocations and scope priorities
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
Re: [m2] Artifact relocations and scope priorities
Posted by Yann Le Du <le...@gmail.com>.
I reolcated jspapi locally, that solved the problem.
I found nothing in JIRA about it, so I tried to file a patch following
http://maven.apache.org/guides/mini/guide-maven-evangelism.html .
Unfortunately, I can't reach the subversion repo with svn:// protocol
(probably firewall at my corp.). Is there a https access ?
--
Yann
2005/12/27, Carlos Sanchez <ca...@apache.org>:
>
> IIRC there was a jira issue that was fixed
>
> On 12/27/05, Yann Le Du <le...@gmail.com> wrote:
> > 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 <ca...@apache.org>:
> > >
> > > You can probably exclude jspapi in acegi
> > >
> > > 1.0.0-RC1 has the right dependencies
> > >
> > > On 12/27/05, Yann Le Du <le...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] Artifact relocations and scope priorities
Posted by Carlos Sanchez <ca...@apache.org>.
IIRC there was a jira issue that was fixed
On 12/27/05, Yann Le Du <le...@gmail.com> wrote:
> 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 <ca...@apache.org>:
> >
> > You can probably exclude jspapi in acegi
> >
> > 1.0.0-RC1 has the right dependencies
> >
> > On 12/27/05, Yann Le Du <le...@gmail.com> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: [m2] Artifact relocations and scope priorities
Posted by Yann Le Du <le...@gmail.com>.
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 <ca...@apache.org>:
>
> You can probably exclude jspapi in acegi
>
> 1.0.0-RC1 has the right dependencies
>
> On 12/27/05, Yann Le Du <le...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: [m2] Artifact relocations and scope priorities
Posted by Carlos Sanchez <ca...@apache.org>.
You can probably exclude jspapi in acegi
1.0.0-RC1 has the right dependencies
On 12/27/05, Yann Le Du <le...@gmail.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org