> glassfish_at_javadesktop.org wrote:
> > Well the idea of having a borked jar in the first
> place is what I'm complaining about.
> >
> > The javaee.jar should be an amalgam of all the
> working jsr interface jars that comprise the javaee
> spec.
> >
> The spec does not come with implementation details.
> Not all APIs defined
> by the spec are Java interfaces; there are some Java
> classes as well
> which can have non-trivial implementation code that
> can vary from one
> vendor to another.
I'm not looking for working implementations. They can return null or do nothing for all I care. All I need are implementations that can be fully classloaded.
If you cannot do EasyMock.createMock(X.class) using easymock or easymock with class extensions, then they are useless in my view.
I have no intention of using these jars in deployment, I just need to be able to use them to create mocks for unit testing.
> > Especially in a maven repository, as maven2 will
> _automatically_ use those jars on the classpath for
> the unit tests... giving rise to my issue.
> >
> Are you sure this happens when you use scope as
> *provider*? Are you
> using provider scope or not? The jar has been
> stripped of method bodies
> so that people can't use it in runtime environment.
> We expect users to
> use provider scope.
>
There is a difference between <scope>provided</scope> when talking about transitive dependencies and when talking about classpaths.
When dealing with transitive dependencies, it remains as provided. So anything that depends on an artifact that depends on the javaee artifact will not pull the javaee into it's classpath.
For compiling, the javaee.jar will be on the classpath with scope provided.
The test classpath = all the <scope>test</scope> artifacts; followed by the compile classpath.
Thus, the javaee.jar is on the test classpath... therefore the unit tests will fail if they reference any of the borked classes as they cannot be classloaded.
The only solution (bar removing the borked javaee from the maven repository and replacing with a semi-real one) I see is to then have a real implementation with <scope>test</scope> and leave the borked one with <scope>provided</scope>... but what is the point of that when you already have a functional javaee.jar availble... therefore you would use the functional one with provided scope and not worry about the useless borked one in the first place.
-Stephen.
> Thanks,
> Sahoo
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail:
> users-help_at_glassfish.dev.java.net
[Message sent by forum member 'stephenconnolly' (stephenconnolly)]
http://forums.java.net/jive/thread.jspa?messageID=227006