Hi, I have a requirement where i want to exclude dependent jars from EAR
packaging and instead use Share Library for the same. For example, please
consider the below dependecy: com.ThirdParty hibernate-core 3.3.1 compile As
you can see, i have mentioned jars having compile scope. I need to make
Specify scope as provided for those dependencies that you expect to be
made available by the container.
/Anders
On Tue, Apr 26, 2011 at 09:05, vaskikamal vaskika...@gmail.com wrote:
Hi, I have a requirement where i want to exclude dependent jars from EAR
packaging and instead use Share
... and the issues list is *always* the wrong list to post anything!
vaskikamal wrote:
Hi, I have a requirement where i want to exclude dependent jars from EAR
packaging and instead use Share Library for the same. For example, please
consider the below dependecy: com.ThirdParty hibernate-core
Is anyone else experiencing that
mvn --no-snapshot-updates
still downloads snapshots?
I created http://jira.codehaus.org/browse/MNG-5064
--
With kind regards,
Geoffrey De Smet
-
To unsubscribe, e-mail:
Besides, i want to make sure all JARs which are currently packaged inside EAR
should be excluded. There are many internal jars which are required at
compile time.
How can i achieve the same?
ANy inputs will be highly appreciated.
Thanks in advance.
Vaski
--
View this message in context:
Hi,
I have tried your suggestion but still the jar is appearing in EAR
packaging. ANy reason for the same.
I have the belo wmentioned understanding for provided scope.
For example, when building a web application for the Java Enterprise
Edition, you would set the dependency on the Servlet API
Hi Anders,
My project is dependent on many thirdparty jars. These jars internally
maintain thier own pom.xml.
I applied your suggestion and change the scope to provided for below
mentioned dependency.
For example, consider the below dependency:
dependency
Anders Hammar wrote:
Yes, you are wrong. The parent has to be computed before the child.
/Anders
On Mon, Apr 25, 2011 at 12:14, zosrothko lt;zosrot...@orange.frgt;
wrote:
Can you be more explicit because otherwise I consider my position as
correct. There is no dependency
Compare it to the relationship between a Java class and a super-class it
extends. The super-class has to be compiled before the class extending it.
Regardless who's opinion is right, this is how it works in Maven as well.
/Anders
On Tue, Apr 26, 2011 at 13:59, zosrothko zosrot...@orange.fr
Regardless who's opinion is right, this is how it works in Maven as well.
My view is more a post order walk than a pre order walk. Thus how can I
specify that the multimodule should be the last in the reactor? (my multi
module, which is an assembly step is depending on the jars produced by its
On 26/04/2011 9:00 AM, Francis ANDRE wrote:
Regardless who's opinion is right, this is how it works in Maven as well.
My view is more a post order walk than a pre order walk. Thus how can I
specify that the multimodule should be the last in the reactor? (my multi
module, which is an assembly
Why not create a separate module to build the assembly and have that
module depend on the other modules it needs. That should do the trick.
Kind regards,
Joachim
On 04/26/2011 03:00 PM, Francis ANDRE wrote:
Regardless who's opinion is right, this is how it works in Maven as well.
My view is
Assuming you are using the maven-ear-plugin, did you try
*earSourceExcludes*http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#earSourceExcludes
--sony
On Tue, Apr 26, 2011 at 7:18 AM, vaskikamal vaskika...@gmail.com wrote:
Hi Anders,
My project is dependent on many thirdparty
I applied your suggestion and change the scope to provided for below
mentioned dependency.
...
Logically, it should have been excluded from EAR packaging. But, it was not.
Make sure you are running mvn clean package so leftover Jars from
previous builds are deleted. I bet that will resolve
Hi,
I have tried the same with little success.
earSourceExcludes excludes the contents from Ear Source Directory but
doesnt exclude it from EAR packaging.
Regards
Vaski
On Tue, Apr 26, 2011 at 8:18 PM, Sony Antony [via Maven]
ml-node+4341094-1281017412-201...@n5.nabble.com wrote:
Its always helpful to be over-specific in emails.
I'm having to make assumptions about your environment that are likely
incorrect and so the advice is not as good as it could be.
In your original email you say it doesn't create any. referring to
eclipse project files (like .project, .classpath,
16 matches
Mail list logo
