Re: Re: [ANN] Apache Maven EAR Version 3.0.0 Released

[Thorsten Heit]

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
> > deploy the EAR anymore to Wildfly 11 server from within Eclipse:
> 
> 
> Sorry to say...you have expected that major version change to not change 

> something ? ...Maybe I misunderstand a thing here...

That was absolutely not my intention :-)
I don't mind if there are changes when a major version is released.


> > Result:
> > After the copying process has finished, Wildfly doesn't start the EAR
> > because it cannot find the WAR module that is referenced in the
> > application.xml
> 
> If I correctly understand that's only happening within Eclipse?

Yes, that's what I'm seeing. Building the EAR from the command line works 
(as expected).


> The 3.0.0 version contains a change to handle all the time by default a 
> full mapping of artifact names which is noticed on the start page:
> 
> http://maven.apache.org/plugins/maven-ear-plugin/
> 
> There is  which by default contains:
> 
> @{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@
> 
> So if you like to go back just change this configuration in your build 
> and it should work as before but with the risk of failing in case of 
> same artifactId's..

Ok, thanks, I'll give this a try.
I guess I won't have failing builds because that's what would already have 
happened actually with m-ear-p 2.10.1 ;-)

OTOH, do you know who is responsible for the now invalid output file 
mapping with m-ear-p 3.0.0 when I'm deploying the EAR in Eclipse to a 
Wildfly server instance? It seems to me that at least in this part there's 
a bug (?) because the (change in the) output file name mapping isn't 
respected...


Side note:
I like the idea of having the group Id in the file name for artifacts. Is 
something similar planned for m-war-p?


Regards

Thorsten

Re: How to tell maven where to look for extensions (instead of central repository)

[Salvatore]

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, with debug enabled, is:

[WARNING] Failed to read extensions descriptor
/home/my-user/git/my-project/.mvn/extensions.xml: Plugin
com.our-company:kompile-maven-extension:1.0 or one of its dependencies
could not be resolved: Could not find artifact
com.our-company:kompile-maven-extension:jar:1.0 in central (
https://repo.maven.apache.org/maven2)

There is no line showing that maven tried to download the extension from
any other repo. Thats the only one that is checking out apparently. That's
why I thought that maybe extensions are not ready to be downloaded from
custom repos yet...

I have posted this question in StackOverflow too:
https://stackoverflow.com/questions/49284462/failed-to-read-extensions-descriptor-could-not-find-artifact-in-central

Maybe our Sonatype is outdated and we have to updated it to support
extensions? I have to admit I don't know what version are we using, but I
can check that out if it makes sense.

Thank you Karl, I appreciate your help.

2018-03-15 19:54 GMT+01:00 Karl Heinz Marbaise :

> 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 being
>> downloaded by maven from my own repository, but maybe the problem is that
>> this is not possible!
>>
>> And that's pretty much it. If it is indeed possible then I will have to
>> ask
>> a new question, cause maven doesn't seem to care about my repos at all
>> haha.
>>
>
> First question related to that. Which Maven version do you use?
> How have you configured your own repositories? Via settings.xml or via
> repository manager ?
>
> Kind regards
> Karl Heinz Marbaise
>
>
>> Thank you very much in advance.
>> Kind regards,
>> Salva
>>
>>

Re: How to tell maven where to look for extensions (instead of central repository)

[Karl Heinz Marbaise]

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 all 
I see when I run any goal on that project, with debug enabled, is:


[WARNING] Failed to read extensions descriptor 
/home/my-user/git/my-project/.mvn/extensions.xml: Plugin 
com.our-company:kompile-maven-extension:1.0 or one of its dependencies 
could not be resolved: Could not find artifact 
com.our-company:kompile-maven-extension:jar:1.0 in central 
(https://repo.maven.apache.org/maven2)


There is no line showing that maven tried to download the extension from 
any other repo. Thats the only one that is checking out apparently. 
That's why I thought that maybe extensions are not ready to be 
downloaded from custom repos yet...


I have posted this question in StackOverflow too: 
https://stackoverflow.com/questions/49284462/failed-to-read-extensions-descriptor-could-not-find-artifact-in-central


Maybe our Sonatype is outdated and we have to updated it to support 
extensions? I have to admit I don't know what version are we using, but 
I can check that out if it makes sense.


It looks like you have configured many repositories in your settings.xml 
instead of having a single group[1] and the configuration put to the 
repository manager like Nexus...


Furthermore have you checked that the extension you are trying to get is 
really under the given coordinates and the same version available ?



Kind regards
Karl Heinz Marbaise
[1]: 
https://books.sonatype.com/nexus-book/2.8/reference/maven-sect-single-group.html




Thank you Karl, I appreciate your help.

2018-03-15 19:54 GMT+01:00 Karl Heinz Marbaise >:


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 being
downloaded by maven from my own repository, but maybe the
problem is that
this is not possible!

And that's pretty much it. If it is indeed possible then I will
have to ask
a new question, cause maven doesn't seem to care about my repos
at all haha.


First question related to that. Which Maven version do you use?
How have you configured your own repositories? Via settings.xml or
via repository manager ?

Kind regards
Karl Heinz Marbaise




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: How to tell maven where to look for extensions (instead of central repository)

[Karl Heinz Marbaise]

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 being
downloaded by maven from my own repository, but maybe the problem is that
this is not possible!

And that's pretty much it. If it is indeed possible then I will have to ask
a new question, cause maven doesn't seem to care about my repos at all haha.


First question related to that. Which Maven version do you use?
How have you configured your own repositories? Via settings.xml or via 
repository manager ?


Kind regards
Karl Heinz Marbaise


Thank you very much in advance.
Kind regards,
Salva



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

How to tell maven where to look for extensions (instead of central repository)

[Salvatore]

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 repository, but maybe the problem is that
this is not possible!

And that's pretty much it. If it is indeed possible then I will have to ask
a new question, cause maven doesn't seem to care about my repos at all haha.

Thank you very much in advance.
Kind regards,
Salva

Re: javadoc:jar and generated sources

[Laird Nelson]

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 javadoc:jar' alone indeed won't run your protoc plugin,
> which won't add the generated sources as a compile source root.


OK, so that's the explanation for my debugging session.

Best,
Laird

Re: [ANN] Apache Maven EAR Version 3.0.0 Released

[Karl Heinz Marbaise]

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
deploy the EAR anymore to Wildfly 11 server from within Eclipse:



Sorry to say...you have expected that major version change to not change 
something ? ...Maybe I misunderstand a thing here...




Environment:
Eclipse Oxygen.2 (4.7.2, Build id: 20171218-0600)
Wildfly 11
Java 8u162
m2e 1.8.2.20171007-0217
m2e-wtp 1.3.3.20171208-1305


Snippet from my pom.xml:

(...)

 org.apache.maven.plugins
 maven-ear-plugin
 2.10.1
 
 5
 true
 ${project.artifactId}-${project.version}
 true
 
 
 ${project.groupId}
 myapp-war
 /APP
 
 
 

(...)



 
 ${project.groupId}
 myapp-war
 ${project.version}
 war
 






Behaviour with m-ear-p 2.10.1:

Deploying the EAR to Wildfly creates a folder  in /
standalone/deployments/, and in this folder my war is extracted in a
folder myapp-war-.war. This is also referenced in the generated
application.xml:
web-uri: myapp-war-.war

So far, so good.


Behaviour with m-ear-p 3.0.0:

The same folders are generated, i.e.  in
/standalone/deployments/ and myapp-war-${version}.war inside
it, but the generated application.xml now has a different web-uri:
web-uri: -myapp-war-.war





Result:
After the copying process has finished, Wildfly doesn't start the EAR
because it cannot find the WAR module that is referenced in the
application.xml


If I correctly understand that's only happening within Eclipse?



The 3.0.0 version contains a change to handle all the time by default a 
full mapping of artifact names which is noticed on the start page:


http://maven.apache.org/plugins/maven-ear-plugin/

There is  which by default contains:

 @{groupId}@-@{artifactId}@-@{version}@@{dashClassifier?}@.@{extension}@

So if you like to go back just change this configuration in your build 
and it should work as before but with the risk of failing in case of 
same artifactId's..






Who is causing this strange behaviour? The JBoss/Wildfly integration in
Eclipse? m2e? ...?
And what can I do to make it work again (apart from sticking with m-ear-p
2.10.1)?


Interesting side effect:
Building the EAR via command line works and generates a correct EAR, i.e.
contains the WAR module with the groupId in its name.



Kind regards
Karl Heinz Marbaise

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Maven EAR Version 3.0.0 Released

[Thorsten Heit]

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 from within Eclipse:

Environment:
Eclipse Oxygen.2 (4.7.2, Build id: 20171218-0600)
Wildfly 11
Java 8u162
m2e 1.8.2.20171007-0217
m2e-wtp 1.3.3.20171208-1305


Snippet from my pom.xml:

(...)

org.apache.maven.plugins
maven-ear-plugin
2.10.1

5
true
${project.artifactId}-${project.version}
true


${project.groupId}
myapp-war
/APP




(...)




${project.groupId}
myapp-war
${project.version}
war




Behaviour with m-ear-p 2.10.1:

Deploying the EAR to Wildfly creates a folder  in /
standalone/deployments/, and in this folder my war is extracted in a 
folder myapp-war-.war. This is also referenced in the generated 
application.xml:
web-uri: myapp-war-.war

So far, so good.


Behaviour with m-ear-p 3.0.0:

The same folders are generated, i.e.  in 
/standalone/deployments/ and myapp-war-${version}.war inside 
it, but the generated application.xml now has a different web-uri:
web-uri: -myapp-war-.war

Result:
After the copying process has finished, Wildfly doesn't start the EAR 
because it cannot find the WAR module that is referenced in the 
application.xml


Who is causing this strange behaviour? The JBoss/Wildfly integration in 
Eclipse? m2e? ...?
And what can I do to make it work again (apart from sticking with m-ear-p 
2.10.1)?


Interesting side effect:
Building the EAR via command line works and generates a correct EAR, i.e. 
contains the WAR module with the groupId in its name.


Best regards

Thorsten

Re: javadoc:jar and generated sources

[Thomas Broyer]

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 root. Running
'mvn generate-sources javadoc:jar' would work differently; and obviously
binding javadoc:jar to a phase in your build (after generate-sources phase,
default  being 'package') and running 'mvn package' should then work the
same.

Le mar. 13 mars 2018 18:57, Laird Nelson  a écrit :

> I am finding that the sourcepath for javadoc:jar (when run as part of the
> release profile) is different from the sourcepath for javadoc:javadoc in my
> project that involves (protoc-) generated sources.
>
> (The net effect is that at release time, everything works fine up until
> release:perform, which fails (!) during the attach-javadocs execution I've
> configured following the documentation (
>
> https://maven.apache.org/plugin-developers/cookbook/attach-source-javadoc-artifacts.html#Configuring_Maven_Javadoc_Plugin
> )
> ).
>
> I have a  stanza centralizing my maven-javadoc-plugin
> configuration that does not mention sourcepath in any way.
>
> mvn help:effective-pom -Prelease shows exactly what I would expect, and no
> additional maven-javadoc-plugin configuration.
>
> Somehow, the sourcepath for javadoc:javadoc has the generated-sources
> directory in it; the sourcepath for javadoc:jar does not.
>
> Here is the pluginManagement section (it's quite ordinary):
>
> 
>   maven-javadoc-plugin
>   3.0.0-M1
>   
> -missing
>   
> 
>
> When I run mvn -X javadoc:javadoc and inspect the options file, I see this:
>
> -sourcepath
> '/Users/ljnelson/Projects/frob/src/main/java:
>
> */Users/ljnelson/Projects/frob/target/generated-sources/protobuf/java:/Users/ljnelson/Projects/frob/target/generated-sources/protobuf/grpc-java*
> :/Users/ljnelson/Projects/frob/src/main/javadoc'
>
> When I run mvn -X javadoc:jar and inspect the options file, I see only
> this:
>
> -sourcepath
>
> '/Users/ljnelson/Projects/frob/src/main/java:/Users/ljnelson/Projects/frob/src/main/javadoc'
>
> The javadoc:jar goal outputs a bunch of warnings.  When I run it locally
> (mvn javadoc:jar), they show up as warnings.  When it is run as part of the
> maven-release-plugin's perform goal, it fails the build.
>
> I'm at a loss as to how to go about fixing this.  Is it, perhaps, the job
> of the plugin in charge of generating the sources to do something here?
>
> Best,
> Laird
>

Re: old version of dependencies getting included into project

[Stephen Coy]

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. 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 to figure out the reason but the old versions don't
> appear there. They also don't appear in the build log. I deleted the old
> versions from my local maven repo. Didn't help. Any ideas on how to figure
> this out?
> 
> thanks,
> Jon.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: old version of dependencies getting included into project

[Anders Hammar]

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 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 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 to figure out the reason but the old versions
> > don't
> > > appear there. They also don't appear in the build log. I deleted the
> old
> > > versions from my local maven repo. Didn't help. Any ideas on how to
> > figure
> > > this out?
> >
> > Did you do a "mvn clean" after upgrading?
> > Maybe the old JARs just didn't get purged from you build directory.
> >
> > hth,
> > - martin
> >
>

Re: old version of dependencies getting included into project

[Jonathan Yom-Tov]

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 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 to figure out the reason but the old versions
> don't
> > appear there. They also don't appear in the build log. I deleted the old
> > versions from my local maven repo. Didn't help. Any ideas on how to
> figure
> > this out?
>
> Did you do a "mvn clean" after upgrading?
> Maybe the old JARs just didn't get purged from you build directory.
>
> hth,
> - martin
>

Re: old version of dependencies getting included into project

[Jonathan Yom-Tov]

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 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 sure to upgrade the war plugin to the latest version. It
> could be a bug.
>
> /Anders
>
> On Thu, Mar 15, 2018 at 7:45 AM, Jonathan Yom-Tov <
> jon.yom...@huha-analytics.com> wrote:
>
> > 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 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 dependencies getting included into project
> > >
> > > hi,
> > >
> > > 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 to figure out the reason but the old versions
> > don't
> > > appear there. They also don't appear in the build log. I deleted the
> old
> > > versions from my local maven repo. Didn't help. Any ideas on how to
> > figure
> > > this out?
> > >
> > > thanks,
> > > Jon.
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > >
> >
>

Re: old version of dependencies getting included into project

[Martin Hoeller]

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 to figure out the reason but the old versions don't
> appear there. They also don't appear in the build log. I deleted the old
> versions from my local maven repo. Didn't help. Any ideas on how to figure
> this out?

Did you do a "mvn clean" after upgrading?
Maybe the old JARs just didn't get purged from you build directory.

hth,
- martin


pgpaGnJq21bFC.pgp
Description: Digitale Signatur von OpenPGP

Re: old version of dependencies getting included into project

[Anders Hammar]

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 sure to upgrade the war plugin to the latest version. It
could be a bug.

/Anders

On Thu, Mar 15, 2018 at 7:45 AM, Jonathan Yom-Tov <
jon.yom...@huha-analytics.com> wrote:

> 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 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 dependencies getting included into project
> >
> > hi,
> >
> > 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 to figure out the reason but the old versions
> don't
> > appear there. They also don't appear in the build log. I deleted the old
> > versions from my local maven repo. Didn't help. Any ideas on how to
> figure
> > this out?
> >
> > thanks,
> > Jon.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>