Try your custom made poms in another project and you'll find that they
won't work. Will you create a pom for each jar in each project? no
thanks.
poms in the repo are not supposed to change, we're fixing them now
because there're a lot of errors, but our intention is to stop doing
that after some
Why not? You will declare all dependencies you need by hands, as you
did it in Maven 1. Thus, your project will be protected from changes
in Acegi's pom in public repository.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additio
But that won't work for everybody, just you.
On 11/23/05, Igor Bljahhin <[EMAIL PROTECTED]> wrote:
> Hello!
>
> I think I have found solution what is suitable for me.
> For Acegi Security framework I have created my own pom
> "acegi-security-0.9.0.pom" with the following content:
>
>
> 4.0.0
>
Hello!
I think I have found solution what is suitable for me.
For Acegi Security framework I have created my own pom
"acegi-security-0.9.0.pom" with the following content:
4.0.0
acegisecurity
acegi-security
0.9.0
jar
aspectj
aspectjrt
1.2
commo
I'll try to address that for acegi by creating submodules for ldap,
single sign on, etc...
On 11/21/05, Brett Porter <[EMAIL PROTECTED]> wrote:
> We can actually do that using profiles, but we haven't greatly used it
> yet. In particular, we don't do activation selectively through a
> dependency.
We can actually do that using profiles, but we haven't greatly used it
yet. In particular, we don't do activation selectively through a
dependency.
We do highly encourage avoiding this complexity in your own dependency
graphs, however.
- Brett
On 11/22/05, Wim Deblauwe <[EMAIL PROTECTED]> wrote:
I don't think that is the way forward. There should be very good explenation
on how to specify your dependencies, so projects that use your project only
got the dependencies they want.
What would be an improvement in my eyes, is that you can somehow relate
functionality (with some kind of keyword)
I think the gist of this thread is that, yes, we can add optional or
exclusions -- but why not simply add a dependency attribute such as::
or even
Although it seems that this should be a project-specific property and should
not be transitive itself. In other words, it should be ignored if it
Hi Carlos,
I agree with you. The pom can be improved greatly by specifying only oro and
commons-codec as "mandatory" dependencies. All others should be optional.
I'll watch closely this bug :)
Thanks.
Eric
On 11/21/05, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> The problem is that the pom c
The problem is that the pom can be improved to add some of them as optional.
I'll solve that when solving http://jira.codehaus.org/browse/MEV-161.
On 11/21/05, Eric Jacob <[EMAIL PROTECTED]> wrote:
> If you want to use all the Acegi's features, sure you need all these jars.
> But since I don't nee
If you want to use all the Acegi's features, sure you need all these jars.
But since I don't need single sign on (cas), ldap or jsp support (directory,
taglibs) or caching (ehcache), why should I have these dependencies included
in my application?
I think transitive dependency is great, but someti
I think there's something more wrong if a jar says it has dependencies
and it doesn't actually need them.
Are you sure you don't need these? If so, consider using your own
repository before ibiblio and strip these of their dependencies.
On 11/21/05, Eric Jacob <[EMAIL PROTECTED]> wrote:
> Hi John
Hi John,
Thanks for your suggestion. It worths a look! But I still think the ability
to disable transitive dependency would be a good thing. It just doesn't feel
right to me to exclude more dependencies than I really need.
Eric
On 11/18/05, John Tolentino <[EMAIL PROTECTED]> wrote:
>
> Hi Eric,
Hi Eric,
If you look at it's pom
(http://www.ibiblio.org/pub/packages/maven2/acegisecurity/acegi-security/0.9.0/acegi-security-0.9.0.pom),
this artifact have 21 direct dependencies. Exclude those and the other
transitive dependencies will be excluded as well. You can easily do this
if you cop
Im not sure if there's already a jira issue for this, if none you can
file a jira issue for your request. :)
regards,
-allan
Arik Kfir wrote:
I agree - perhaps an element inside the
section?
On 11/19/05, Barry Kaplan <[EMAIL PROTECTED]> wrote:
Allan Ramirez wrote:
Hi,
add the
I agree - perhaps an element inside the
section?
On 11/19/05, Barry Kaplan <[EMAIL PROTECTED]> wrote:
> Allan Ramirez wrote:
>
> > Hi,
> >
> > add the tag to your
> > and put the artifacts you want to exclude.
>
>
> For 72 dependencies! I think we need the ability to disable transitive
> per d
Allan Ramirez wrote:
Hi,
add the tag to your
and put the artifacts you want to exclude.
For 72 dependencies! I think we need the ability to disable transitive
per dependency, or maybe a wildcard excludes pattern. I also dream of
the ability to have a top-level excludes (eg, "never ever
Hi,
add the tag to your
and put the artifacts you want to exclude.
acegisecurity
acegi-security
0.9.0
runtime
groupId-of-the-artifact
artifactId-of-the-artifact
regards,
-allan
Eric Jacob wrote:
But what about acegi-security-0.9.0.jar? I need it in my webapp.
Thanks.
Eric
But what about acegi-security-0.9.0.jar? I need it in my webapp.
Thanks.
Eric
On 11/18/05, Pablo <[EMAIL PROTECTED]> wrote:
>
> Eric Jacob wrote:
>
> >Hi,
> >
> >Putting the following dependency results in 72 jars downloaded in
> >WEB-INF/lib!
> >
> >
> >acegisecurity
> >acegi-security
> >0.9.0
Eric Jacob wrote:
Hi,
Putting the following dependency results in 72 jars downloaded in
WEB-INF/lib!
acegisecurity
acegi-security
0.9.0
runtime
Hi
If you set provided then these dependencies will not be
included in /WEB-INF/lib
Cheers
Pablo
--
Hi,
Putting the following dependency results in 72 jars downloaded in
WEB-INF/lib!
acegisecurity
acegi-security
0.9.0
runtime
Of course, I can exclude unecessary dependencies, but it's a real pain. A
better solution would be to disable transitive dependencies all together. Is
it supported?
Th
21 matches
Mail list logo
