I've also posted this question on Stack Overflow:
https://stackoverflow.com/questions/63885408/maven-dependency-plugin-useddependency-vs-ignoredunuseddeclareddependencies
On 2020/09/02 15:09:43, Shelley wrote:
> What is the difference between the maven-dependency-
What is the difference between the maven-dependency-plugin's
*ignoredUnusedDeclaredDependencies* [1] and *usedDependencies *[2]?
I have several runtime/test-runtime dependencies that are flagged by the
plugin as unused and declared and would like to ignore them. Both of these
parameters seem to ac
fun errors to debug. I had to manually fix the archives created by
hand.
Ryan Shelley
On Oct 3, 2010, at 8:16 AM, "Justin Edelson"
wrote:
> In general, yes, using the assembly plugin.
>
> On Oct 3, 2010, at 11:09 AM, Dirk Reske wrote:
>
>> Hello,
>>
>&g
Sure enough, a free-style build with a maven executor worked just fine! I
posted this same question to the Hudson mailing list, so hopefully someone will
know the issue.
Thanks!
-Ryan
-Original Message-
From: Shelley, Ryan [mailto:ryan.shel...@disney.com]
Sent: Tuesday, September 21
le?
If using native maven job, please re-try with freestyle one. Might be a
hudson bug?
Cheers
2010/9/21 Shelley, Ryan
> I have a build that runs from Hudson on a farm of 4 linux boxes. Hudson
> pulls down from our source control and builds the modules. When Hudson
> builds the
I have a build that runs from Hudson on a farm of 4 linux boxes. Hudson pulls
down from our source control and builds the modules. When Hudson builds the
project, some test cases fail because certain plugins aren't being merged from
a parent pom into the effective pom. To test the failure, I
I was able to test with 2.2.1 and it appears resolved.
-Ryan
-Original Message-
From: users-return-110277-ryan.shelley=disney@maven.apache.org
[mailto:users-return-110277-ryan.shelley=disney@maven.apache.org] On
Behalf Of Shelley, Ryan
Sent: Friday, April 09, 2010 7:37 AM
To
l
+-app/
+-pom.xml
do you get the error when running Maven from / and /app/ or just /?
Justin
On 4/8/10 7:04 PM, Shelley, Ryan wrote:
> We've been building our application on Maven 2.1 for awhile just fine.
> We build it manually and with a continuous integration tool (Hudson)
>
We've been building our application on Maven 2.1 for awhile just fine.
We build it manually and with a continuous integration tool (Hudson)
without issue. I moved Hudson from a Windows box to a Linux box, and
suddenly we started getting this following error running the tests:
2010-04-08 15:56:
Is there any way to bind a goal's execution not only to a lifecycle *phase*,
but to limit the execution to a specific *lifecycle *as well?
I would like to bind a goal to the integration-test phase of the standard
build lifecycle, but exclude it from being executed in a forked lifecycle
(clover).
I have a single web project which requires three distinct .war endstates,
where the only difference between each are the runtime dependencies (some
configuration files may also be different in the future). Are there any
recommendations for accomplishing this?
Some background:
* The assembly plugi
I have a project which uses the jaxb plugin [1] and is instrumented using
the clover plugin [2]. This project consistently results in build failures
caused by duplicate classes during compilation. Clover seems to be causing
the jaxb generated-sources to be duplicated:
[INFO] [compiler:compile]
In a JAR project, when declaring a dependency with type "zip," the generated
manifest class-path excludes the zip dependency. Further, when generating
the eclipse artifacts, the .classpath also excludes the zip dependency.
This seems to occur because the ArtifactHandler isAddedToClasspath is fal
The sample usage example of the maven-war-plugin [1] demonstrates a war's
project structure with images in the src/main/resources directory, and a
resulting package structure with the images in web-inf/classes. According
to the Servlet 2.4 specification [2]:
"The WEB-INF node is not part of the
When a WAR is defined as a dependency of another project, is there any
configuration to allow the war's dependencies to be discovered transitively?
This behavior is desired in the scenario where utility JARs are packaged in
an EAR, not in the dependent WARs (http://jira.codehaus.org/browse/MWAR-9
We have noticed some odd behavior related to the maven-assembly-plugin...
With the latest 2.2-SNAPSHOT version of the maven-assembly-plugin, the
ability to define multiple "include" dependencySets and to define
dependencies by any combination of groupId, artifactId, type, and classifier
(using wi
The dependencies were being declared in an EAR which only recognizes a
limited set of standard mappings by default. The zip type had to be
configured as a custom artifactTypeMapping:
http://maven.apache.org/plugins/maven-ear-plugin/introduction.html
Wendy Smoak-3 wrote:
>
> You'
With some of our JAR/WAR projects, we create secondary project end states with
the ZIP format using the assembly plugin. Is there any way to declare these
assembled zips as dependencies of other projects? Thanks!
-
Want to start your own business? Learn how on
The 4.0.0 POM schema indicates that the finalName includes the extension [1],
but when running "package," the default packaging type extension is
automatically appended. For example, if test.zip is
used for a jar project, the resulting artifact is test.zip.jar. Is this an
issue with the packa
19 matches
Mail list logo
