Hello,
I have tried with maven 3.3.9 and 3.5.0. I will try with 3.5.3 tomorrow too.
The repos are configured via settings.xml. I have them both as
and as . If the docs are right, the plugin repositories
should be the important ones for extensions but all I see when I run any
goal on that project,
Hi,
On 15/03/18 20:12, Salvatore wrote:
Hello,
I have tried with maven 3.3.9 and 3.5.0. I will try with 3.5.3 tomorrow too.
The repos are configured via settings.xml. I have them both as
and as . If the docs are right, the
plugin repositories should be the important ones for extensions but
Hi,
On 15/03/18 11:51, Salvatore wrote:
Hello, first time here. I have a quick question:
Is it possible to use a maven extension that is not in maven central
without downloading the jar manually? nor doing a mvn install locally?
Cause I have been trying to find out why is my extension not
Hello, first time here. I have a quick question:
Is it possible to use a maven extension that is not in maven central
without downloading the jar manually? nor doing a mvn install locally?
Cause I have been trying to find out why is my extension not being
downloaded by maven from my own
On Thu, Mar 15, 2018 at 1:38 AM Thomas Broyer wrote:
> Be careful in your testing: javadoc:javadoc forks a lifecycle at
> 'generate-sources' phase (and javadoc:aggregate at 'compile' phase),
> whereas javadoc:jar does not!
>
An excellent point.
> So running 'mvn
Hi,
On 15/03/18 12:51, Thorsten Heit wrote:
Hi,
The Apache Maven team is pleased to announce the release of the
Apache Maven EAR Plugin Version 3.0.0
First of all thanks for releasing a new version of this plugin!
I just gave it a try in an internal multi-module project, but now I can't
Hi,
> The Apache Maven team is pleased to announce the release of the
> Apache Maven EAR Plugin Version 3.0.0
First of all thanks for releasing a new version of this plugin!
I just gave it a try in an internal multi-module project, but now I can't
deploy the EAR anymore to Wildfly 11 server
Be careful in your testing: javadoc:javadoc forks a lifecycle at
'generate-sources' phase (and javadoc:aggregate at 'compile' phase),
whereas javadoc:jar does not!
So running 'mvn javadoc:jar' alone indeed won't run your protoc plugin,
which won't add the generated sources as a compile source
I’ve seen this happen when you have WAR overlays.
All dependency management seems to go out the window when using overlays.
Steve C
> On 15 Mar 2018, at 6:39 am, Jonathan Yom-Tov
> wrote:
>
> hi,
>
> I have a fairly large project which compiles to a war file.
It's close to impossible to tell what the problem is without a test project
showing the issue.
/Anders
On Thu, Mar 15, 2018 at 8:44 AM, Jonathan Yom-Tov <
jon.yom...@huha-analytics.com> wrote:
> I'm running `mvn clean package` every time (plus I deleted the old version
> of the jar form my
I'm running `mvn clean package` every time (plus I deleted the old version
of the jar form my local repo), so I don't think that's it.
On Thu, Mar 15, 2018 at 9:14 AM, Martin Hoeller wrote:
> Hi!
>
> On 14 Mar 2018, Jonathan Yom-Tov wrote:
>
> > I have a fairly large project
One of the jars is jackson core, I'm trying to upgrade from 2.4.3 to 2.7.3.
It looks like the coordinates are identical.
I tried upgrading the war plugin to 3.2.0, but that didn't help.
On Thu, Mar 15, 2018 at 9:07 AM, Anders Hammar wrote:
> Could it be that it's a different
Hi!
On 14 Mar 2018, Jonathan Yom-Tov wrote:
> I have a fairly large project which compiles to a war file. I've upgraded
> the jackson dependency to 2.7.3 but for some reason 2.4.3 and 2.4.0 jar
> files are included into the war file in addition to the 2.7.3 version. I
> ran mvn dependency:tree
Could it be that it's a different groupId for all these jackson artifacts?
That what explain why there are several different version for the same
library as Maven sees it as different coordinates.
I would check the jars and see if there's pom in them which would anser
this.
Also, I would make
100%, grep does not lie :-)
There's also something else that's strange: as a workaround I tried to add
a packagingExcludes section to the pom.xml but the unwanted jars were still
included.
On Mar 15, 2018 08:37, "Golan, Yaron" wrote:
> Hi Jon,
> This scenario is very
Hi Jon,
This scenario is very strange.
Are you absolutely sure that the mvn dependency:tree didn't print it out?
-Original Message-
From: Jonathan Yom-Tov [mailto:jon.yom...@huha-analytics.com]
Sent: Wednesday, March 14, 2018 21:40
To: users@maven.apache.org
Subject: old version of
16 matches
Mail list logo