Hi Martin,
Ant, I believe, is what is directly modifying the manifest.mf, under the
direction of the default build script Netbeans generates as part of the
project type (Java Class Library). Netbeans uses Ant by default, you must
explicitly use Maven as a new project type. Personally, I like to "keep
things simple" and stay with Ant if/when possible for a couple reasons:
- I work with developers new to Java (formerly mod-perl shop). In needing
to teach the breadth, I try to hold off on depth whenever possible
- I work only on internal non-Internet accessible networks
(completely segregated). There would be a fair amount of overhead
maintaining and synchronizing an "offline" Maven repo and I'm barely keeping
my head above water as it is.
- Ant, IMHO, it's pretty good =).
The reason why I was looking to writing a build-time script for hudson to
solve this problem is because these libraries are used in both EE and SE
apps (they are class libraries, afterall). So, the default
Netbeans-provided Ant script works well in most other contexts. When I
include them as nested-dependencies within EE applications, however, I get
the problem. Therefore, as hudson creates the build, I was going to take
the latest from svn, modify the manifest, and finally include it in the
default classpath for the EE build (basically, clean it up so it's how EE
builds need it). I would still maintain a clean (default) library project
while "generating" the minor changes through a repeatable means.
I'm not sure this is a Netbeans bug...I believe this is something good (and
helpful) for SE apps, and by now it's certainly something expected by many
developers - changing it (dependencies of a project to be moved into the
<project>/lib directory on build) would cause a lot of heartache. If I'm
wrong, please let me know why and I'll submit a question to the Netbeans
users forum.
Thanks,
Steve
On Wed, May 5, 2010 at 7:24 PM, Martin Gainty <mgainty_at_hotmail.com> wrote:
> Hi Steve-
> Hudson and or netbeans should'nt be modifying the manifest.mf that way
>
> can you identify the entity that Hudson or netbeans uses to create the
> manifest?
> it you did call the maven-jar-plugin did you customise the manifest?
>
> http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
>
> this is a nasty bug that needs to be taken care of immediately
>
> *glad to hear you have a solution*
>
> Martin Gainty
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
>
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
>
>
>
>
>
>
> ------------------------------
> From: smsiebe_at_gmail.com
> Date: Wed, 5 May 2010 10:40:15 -0400
>
> To: users_at_glassfish.dev.java.net
> Subject: Re: FileNotFoundException for lib dependency...
>
> 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
>
>
>
> ------------------------------
> Hotmail has tools for the New Busy. Search, chat and e-mail from your
> inbox. Learn more.<http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1>
>