Tim,
You're exactly right!
I modified my manifest files of the libraries and *poof* no lib/lib
exceptions. All of this, it seems, was due to reliance/use of the
Netbeans/Ant default build operations. Seems like my "simple" solution (in
my environment) is to allow the developers to continue to use their
developer tooling as normal (Netbeans) and make a small modification in the
Hudson build process for that particular project. Any better
suggestions/alternatives to this that anyone has would be appreciated.
Thanks to all for the help. I learned a lot about EE ClassLoaders in the
process...very good information to know. We're not fortunate enough to have
a "build developer", as previously suggested - I guess I'm also filling that
role since I'm the one that brought Java/Netbeans/SVN/Hudson to our team. I
really appreciate the feedback and help.
Steve
On Tue, May 4, 2010 at 10:40 AM, <glassfish_at_javadesktop.org> wrote:
> Steve,
>
> Earlier in the thread you showed some of the structure of your EAR. Was
> that a complete picture?
>
> I ask because one other possibility might be this: If you have a library
> JAR in the /lib directory, and its manifest Class-Path refers to
> lib/get_dev-common.jar, then that would explain why GlassFish tries to find
> the jar in lib/lib because relative URIs in a JAR's manifest Class-Path are
> resolved against the referring JAR.
>
> - Tim
> [Message sent by forum member 'tjquinn']
>
> http://forums.java.net/jive/thread.jspa?messageID=400518
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>