On Tue, 2 May 2006, Sean McNamara wrote:

> On page 45 of the new maven book, it states:
>
> "The original contents of src/main/resources can be found starting at the 
> base of the JAR and the application.properties file is there in the META-INF 
> directory. You will also notice some other files there like 
> META-INF/MANIFEST.MF, as well as a pom.xml and pom.properties file. These 
> come standard with the creation of a JAR in Maven. You can create your own 
> manifest if you choose, but Maven will generate one by default if you don't."
>
> I'm in a situation where I need to specify entries in the Class-Path
> attribute in MANIFEST.MF.  Putting the manifest file in
> "src/main/resources/META-INF/" results in a manifest being generated by
> maven, and the one in resources being stored under
> WEB-INF/classes/META-INF.
>
> Did I misunderstand this portion of the book?

No, but war packaging is different. The normal contents of a JAR go in
WEB-INF/classes/ if packaging is a war. Normally compiled classes are put
in /, but not in the case of a war. So maybe the book was being to general
in this case.

>
> Ideally, I would be able to accomplish what I'm after by specifying the
> "addClasspath" attribute for the WAR archiver, but doing this includes
> all jars with the default scope in the classpath which is not what I'm
> after.  Default scope items should be bundled inside the WEB-INF/lib
> folder of the war as normal, but there are a couple that are provided
> inside the application EAR and these are what I'd like to add to the
> manifest classpath.

What do you mean by 'default scope'? addClasspath will add all
dependencies with scope compile/runtime. If you want other jars,
you'll have to wait a bit for a new Maven version as this is not
configurable yet.

Btw, it's not that bad to have too many jars in the manifest; only the
ones that exist will be used. On the other hand, usually all needed jars
for a WAR should be in WEB-INF/lib - in your case, the war only works when
it's deployed within an ear, and is no longer usable as a standalone
webapp (using remote or local interfaces). Also classloading for
enterprise modules differs per container, so it's not a given that this
classpath idea will even work properly.

-- Kenney

>
> Any pointers?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to