Wayne,

I don't feel his response was out of line. It was not apparent that
you had already done some of your own homework in the initial email.

You asked a question which, as far as Vincent is concerned, has
already been answered by existing documentation. Since you said
nothing about having previously read the docs, Vincent simply felt
like a RTFM response was adequate. (Especially given the large "we
need more docs" thread recently.)
This is a matter of courtesy and tact. RTFM is generally just rude. And even if it were appropriate, you find out first if this is the case by asking -- you don't RTFM on the off chance it might be true.

still have questions. Instead of simply saying "how do I do this",
perhaps you can post part of your pom.xml and say "this isn't working
as documented, can someone help". And if we can't, or we realize that

Its not a question of something not working as documented, its a question that it isn't (to my knowledge) documented (in full). See below.

either the docs are wrong or the code is wrong as a result of this
email conversation, then we can go open a JIRA issue for the developer
responsible for the module/plugin.

Just glancing at the EAR webpage Vincent sent you, it seems pretty
obvious how to get dependencies into a certain location in an EAR:
 <build>
   <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-ear-plugin</artifactId>
       <configuration>
          <defaultJavaBundleDir>/common/</defaultJavaBundleDir>
       </configuration>
     </plugin>
   </plugins>
 </build>

Are you sure you read this page, and at least attempted to follow the
documentation? Because this seems very clear-cut to me and certainly
not worthy of a full day of trial and error. If it doesn't work as
documented, then its probably a bug in code or docs.
There's more issues than just moving jars into /common/. There's the issue that it not only moves dependencies, but it also moves your EJB jars too, which is undesirable. There's the issue of how to get the classpath in the Ear's manifest to change.to reflect that directory (which it doesn't on my tests -- the classpath shows root, while the jars are in /common). Then there's the issue of how to get all contained archives (ejb jars, sars, wsrs, etc.) and their manifest classpaths, and how to get them to see classes moved into /common/. It make absolutely no sense for me to waste bandwidth iterating everything I tried. I don't want to waste people's time trying focussing my question on debugging whatever crazy hackery I am trying to get it to work. Rather, I just want to know the right way to go about this, hence, the question. If posting my pom.xml would have been the most lucid way to approach asking the question, then I would have. But it didn't really add anything to the question.

B

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

Reply via email to