Help with Maven 2 error!

[Shaun McGlinchey <sh...@hotmail.com>]

I have made no changes to my configuration, files of a Maven project which 
was until recently working.

When trying to build the project I get the following error:

[WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0-SNAPSHOT:runtime' is 
invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0 
POM.
[WARNING] POM for 'com.sun.xml.stream.buffer:streambuffer:pom:0.3:runtime' 
is invalid. It will be ignored for artifact resolution. Reason: Failed to 
validate POM

Can anybody tell me what has caused this problem?

Thankyou
Shaun

_________________________________________________________________
Windows Live™ Messenger has arrived. Click here to download it for free! 
http://imagine-msn.com/messenger/launch80/?locale=en-gb


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Question about transitive dependencies

[Tom Huybrechts <to...@gmail.com>]

Say you depend on a ClassA from dependency A. Class A extends ClassB
from dependency B. When you compile against ClassA you will also need
ClassB even if you do not access it directly.
That is the reason B is automatically put on your compile classpath if
you depend on A.

There are several ways to avoid that a dependency is passed
transitively. You can change the scope to provided or set set
<optional>true</optional> in the POM of the dependency . As far as I
understand it, both have the same effect on the compile time
classpath. If you want to exclude a transitive dependency in the POM
that declares the dependency, you will need to use the exclusion
mechanism.

More information can be found in:
* http://maven.apache.org/pom.html
* http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

Tom


On 12/1/06, Heck, Joe <Jo...@dig.com> wrote:
> I couldn't answer this for one of the devs in our team, so I thought I'd
> push the question to you all for any feedback you could provide.
>
> Any insight would be great...
>
> -joe
> -- --
>
> Can anyone explain to me why transitive dependencies (even of
> dependencies that are specified as "compile" scope in your project) are
> put on the compile time classpath?
> It seems to me that transitive dependencies on the compile time
> classpath are useless at best, since you shouldn't need them to build
> the project. If you have a transitive dependency that you actually do
> need for your project to build, doesn't that pretty much by definition
> mean that it should be a direct dependency of your project instead?
>
> For example say that I have a project in which I specify the artifact
> "Foo" as a dependency, and foo has a dependency on project "Bar".
>
> If my project doesn't have any direct dependency on Bar then there's no
> reason I need Bar to be in my classpath when I build, but having it
> there should be benign.
>
> But if my project does depend on Bar then just specifying Foo as a
> dependency could cause my project to build fine. It might not even be
> obvious that I'm getting my Bar dependency through Foo. This situation
> could potentially lead to bugs in my build or in my code if the Foo
> project decides to upgrade to Bar 2.0 and my code isn't compatible with
> it or if Foo drops its dependency on Bar altogether.
>
> So, is there a reason I'm missing for why you'd ever want to put a
> transitive dependency on your compile time classpath?
>
> Is there a way to cause a project to not put transitive dependencies on
> its compile time classpath but to keep them on the runtime classpath?
>
> ---------------------------------------------------------------------
> 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: Question about transitive dependencies

[Alexander Sack <pi...@gmail.com>]

On 12/1/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 12/1/06, Alexander Sack <pi...@gmail.com> wrote:
> >
> > And in fact, one can actually remove the transitive dependencies that
> are
> > unwanted during the build classpath by declaring them in the POM as
> > "provided."  I believe that fits his scenario where he is building
> against
> > a
> > library that has a transitive dependency that he does not want on his
> > build
> > classpath for whatever reason (packaging, etc.).
>
>
> My understanding is the "provided" is essentially the opposite of
> "runtime"
> ... it leaves the dependency on the compile classpath but does not include
> it in the output.   Whereas, "runtime" leaves it off the compile classpath
> but does include it in the output.


Craig, yea, your right.  My apologies.  I'm using provided in one project as
a way to avoid output
not build scope since as the original poster stated, transitive dependencies
are relatively harmless.

My issue was in fact that transitive dependencies were being packaged and I
wanted to remove them.

Again, sorry for the confusion and thanks for the correction!  :D

-aps

-- 
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson

Re: Question about transitive dependencies

[Craig McClanahan <cr...@apache.org>]

On 12/1/06, Alexander Sack <pi...@gmail.com> wrote:
>
> And in fact, one can actually remove the transitive dependencies that are
> unwanted during the build classpath by declaring them in the POM as
> "provided."  I believe that fits his scenario where he is building against
> a
> library that has a transitive dependency that he does not want on his
> build
> classpath for whatever reason (packaging, etc.).


My understanding is the "provided" is essentially the opposite of "runtime"
... it leaves the dependency on the compile classpath but does not include
it in the output.   Whereas, "runtime" leaves it off the compile classpath
but does include it in the output.

In a web app, I'll want to declare the servlet API as a "provided" API so
that I can use it in my own code.  The servlet container will make it
available to me at runtime, so I don't want to include it in the war.  But,
if I'm also using something like the MyFaces JSF implementation, which has
both an API jar and an implementation JAR, I'll want the API jar declared as
"compile" scope (so its on the classpath and included in the war), but the
impl JAR declared "runtime" scope (so it is *not* possible for me to
accidentally compile against classes in the MyFaces implementation, where I
should be programming solely to JSF APIs), but is included so that the
runtime app will work.

Craig


-aps


Craig


On 12/1/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> > On 12/1/06, Alexander Sack <pi...@gmail.com> wrote:
> > >
> > > This maybe an artifact of the fact that many plugins use the classpath
> > for
> > > runtime constraints as well.
> >
> >
> > It's also possible to avoid this behavior, by declaring a scope of
> > <runtime>
> > on the dependency.  That way, the module is *not* included on the
> compile
> > time classpath (unless it's declared with compile scope by someone else
> > you
> > depend on), but *is* included for runtime (for example, in a webapp it'd
> > be
> > included in WEB-INF/lib).
> >
> > -aps
> >
> >
> > Craig
> >
> >
>
>
> --
> "What lies behind us and what lies in front of us is of little concern to
> what lies within us." -Ralph Waldo Emerson
>
>

Re: Question about transitive dependencies

[Alexander Sack <pi...@gmail.com>]

And in fact, one can actually remove the transitive dependencies that are
unwanted during the build classpath by declaring them in the POM as
"provided."  I believe that fits his scenario where he is building against a
library that has a transitive dependency that he does not want on his build
classpath for whatever reason (packaging, etc.).

-aps

On 12/1/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 12/1/06, Alexander Sack <pi...@gmail.com> wrote:
> >
> > This maybe an artifact of the fact that many plugins use the classpath
> for
> > runtime constraints as well.
>
>
> It's also possible to avoid this behavior, by declaring a scope of
> <runtime>
> on the dependency.  That way, the module is *not* included on the compile
> time classpath (unless it's declared with compile scope by someone else
> you
> depend on), but *is* included for runtime (for example, in a webapp it'd
> be
> included in WEB-INF/lib).
>
> -aps
>
>
> Craig
>
>


-- 
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson

Re: Question about transitive dependencies

[Craig McClanahan <cr...@apache.org>]

On 12/1/06, Alexander Sack <pi...@gmail.com> wrote:
>
> This maybe an artifact of the fact that many plugins use the classpath for
> runtime constraints as well.


It's also possible to avoid this behavior, by declaring a scope of <runtime>
on the dependency.  That way, the module is *not* included on the compile
time classpath (unless it's declared with compile scope by someone else you
depend on), but *is* included for runtime (for example, in a webapp it'd be
included in WEB-INF/lib).

-aps


Craig

Re: Question about transitive dependencies

[Alexander Sack <pi...@gmail.com>]

This maybe an artifact of the fact that many plugins use the classpath for
runtime constraints as well.

-aps

On 12/1/06, Heck, Joe <Jo...@dig.com> wrote:
>
> I couldn't answer this for one of the devs in our team, so I thought I'd
> push the question to you all for any feedback you could provide.
>
> Any insight would be great...
>
> -joe
> -- --
>
> Can anyone explain to me why transitive dependencies (even of
> dependencies that are specified as "compile" scope in your project) are
> put on the compile time classpath?
> It seems to me that transitive dependencies on the compile time
> classpath are useless at best, since you shouldn't need them to build
> the project. If you have a transitive dependency that you actually do
> need for your project to build, doesn't that pretty much by definition
> mean that it should be a direct dependency of your project instead?
>
> For example say that I have a project in which I specify the artifact
> "Foo" as a dependency, and foo has a dependency on project "Bar".
>
> If my project doesn't have any direct dependency on Bar then there's no
> reason I need Bar to be in my classpath when I build, but having it
> there should be benign.
>
> But if my project does depend on Bar then just specifying Foo as a
> dependency could cause my project to build fine. It might not even be
> obvious that I'm getting my Bar dependency through Foo. This situation
> could potentially lead to bugs in my build or in my code if the Foo
> project decides to upgrade to Bar 2.0 and my code isn't compatible with
> it or if Foo drops its dependency on Bar altogether.
>
> So, is there a reason I'm missing for why you'd ever want to put a
> transitive dependency on your compile time classpath?
>
> Is there a way to cause a project to not put transitive dependencies on
> its compile time classpath but to keep them on the runtime classpath?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
"What lies behind us and what lies in front of us is of little concern to
what lies within us." -Ralph Waldo Emerson

Question about transitive dependencies

["Heck, Joe" <Jo...@dig.com>]

I couldn't answer this for one of the devs in our team, so I thought I'd
push the question to you all for any feedback you could provide.

Any insight would be great...

-joe
-- -- 

Can anyone explain to me why transitive dependencies (even of
dependencies that are specified as "compile" scope in your project) are
put on the compile time classpath? 
It seems to me that transitive dependencies on the compile time
classpath are useless at best, since you shouldn't need them to build
the project. If you have a transitive dependency that you actually do
need for your project to build, doesn't that pretty much by definition
mean that it should be a direct dependency of your project instead? 

For example say that I have a project in which I specify the artifact
"Foo" as a dependency, and foo has a dependency on project "Bar".

If my project doesn't have any direct dependency on Bar then there's no
reason I need Bar to be in my classpath when I build, but having it
there should be benign.

But if my project does depend on Bar then just specifying Foo as a
dependency could cause my project to build fine. It might not even be
obvious that I'm getting my Bar dependency through Foo. This situation
could potentially lead to bugs in my build or in my code if the Foo
project decides to upgrade to Bar 2.0 and my code isn't compatible with
it or if Foo drops its dependency on Bar altogether.

So, is there a reason I'm missing for why you'd ever want to put a
transitive dependency on your compile time classpath?

Is there a way to cause a project to not put transitive dependencies on
its compile time classpath but to keep them on the runtime classpath?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Help with Maven 2 error!

[Wayne Fay <wa...@gmail.com>]

Neither of those are errors. Both are warnings.

Where's the error?

Wayne

On 12/1/06, Shaun McGlinchey <sh...@hotmail.com> wrote:
> I have made no changes to my configuration, files of a Maven project which
> was until recently working.
>
> When trying to build the project I get the following error:
>
> [WARNING] POM for 'org.jvnet.staxex:stax-ex:pom:1.0-SNAPSHOT:runtime' is
> invalid. It will be ignored for artifact resolution. Reason: Not a v4.0.0
> POM.
> [WARNING] POM for 'com.sun.xml.stream.buffer:streambuffer:pom:0.3:runtime'
> is invalid. It will be ignored for artifact resolution. Reason: Failed to
> validate POM
>
> Can anybody tell me what has caused this problem?
>
> Thankyou
> Shaun
>
> _________________________________________________________________
> Windows Live™ Messenger has arrived. Click here to download it for free!
> http://imagine-msn.com/messenger/launch80/?locale=en-gb
>
>
> ---------------------------------------------------------------------
> 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