[ANN] Apache Maven JDeps Plugin 3.0.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
JDeps Plugin, version 3.0.0
 
The JDeps Plugin uses the jdeps tool to analyze classes for internal API 
calls. For more information about the standard jdeps tool, please refer to 
Java+Dependency+Analysis+Tool.
 
http://maven.apache.org/plugins/maven-jdeps-plugin/
 
You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-jdeps-plugin
  3.0.0

 
You can download the appropriate sources etc. from the download page:
 
http://maven.apache.org/plugins/maven-jdeps-plugin/download.cgi

This is the first release of this plugin.
 
Enjoy,
 
-The Apache Maven team

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

[ANN] JAX-WS Maven Plugin version 2.4 Released

[Hervé BOUTEMY]

Hi,

The Mojo team is pleased to announce the release of the JAX-WS Maven Plugin 
version 2.4. 

This plugin contains Maven adapter for JAX-WS's toolset.
The original code was developed in the Codehaus Mojo project, then as of March 
2007, the project moved to jax-ws-commons with version 1.x in 
org.codehaus.mojo groupId and version 2.x in org.jvnet.jax-ws-commons groupId.
In September 2015, for version 2.4, it went back to MojoHaus (the new home of 
Codehaus Mojo) in org.codehaus.mojo groupId.

http://www.mojohaus.org/jaxws-maven-plugin/

To get this update, simply specify the version in your project's plugin 
configuration: 


org.codehaus.mojo
jaxws-maven-plugin
2.4


Release Notes

http://www.mojohaus.org/jaxws-maven-plugin/release-notes-24.html


Enjoy,

The Mojo team.
 
Hervé

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

Re: Problems compiling source java with different encodings

[Hervé BOUTEMY]

maven-compiler-plugin by default uses JDK's javac: it seems javac can't work 
with the encoding soup you have in legacy code. If you find some feature in 
javac to deal with that problem, you'll have to see how to inject the trick 
into maven-compiler-plugin
because Maven, or more precisely maven-compiler-plugin, can't fix the 
compiler, or more precisely not fix since it's not a compiler bug, but add a 
feature to the compiler to support weird source code


You really should fix your encoding soup problem: I suppose you know it :)
because you'll find at every level: how do your developer work with their IDE 
to edit the code? Do they choose to be able to see/update Strings or comments?
Perhaps the legacy code is really dead, so you can avoid this IDE problem...


If you can't fix the real problem nor find javac option to support it, another 
workaround I see could be to make maven-compiler-plugin not use javac but use 
a compiler that supports the encoding soup: I never used this feature myself, 
but here is the maven-compiler-plugin doc [1]


Regards,

Hervé


[1] 
http://maven.apache.org/plugins/maven-compiler-plugin/non-javac-compilers.html

Le mardi 25 août 2015 17:04:05 Néstor Boscán a écrit :
 Yes,
 
 The problem is that the legacy code has comments in Cp1252 and Strings in
 UTF-8. The weird thing is that IDEA and JDeveloper can compile them using
 their internal compilers.
 
 Regards,
 
 Néstor
 
 On Tue, Aug 25, 2015 at 3:36 PM, Russell Gold russell.g...@oracle.com
 
 wrote:
  Do you have the following in your pom.xml?
  
  properties
  
  project.build.sourceEncodingUTF-8/project.build.sourceEncoding
  
  /properties
  
  If not, do you know what encoding is being used in your source file?
  
   On Aug 25, 2015, at 4:01 PM, Néstor Boscán nesto...@gmail.com wrote:
   
   Hi
   
   I have a legacy code that compiles correctly using IDEA or JDeveloper.
  
  But
  
   if I try to use maven compile it generates error because there are
  
  unknoen
  
   characters in the comments. It looks like the legacy code has different
   types of character encoding in the file. Is there a way to compile using
   maven that will not take into consideration the comments?
   
   Regards,
   
   Néstor
  
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org


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

Re: Where has the list of maven project properties gone?

[Hervé BOUTEMY]

here is the core reference:
http://maven.apache.org/ref/3-LATEST/maven-model-builder/

it does not explain everyting that can be found in POM or in settings, since 
there are so much info available
but it points to POM and settings descriptors and explains everything that is 
not POM or settings

Regards,

Hervé

Le vendredi 4 septembre 2015 15:23:19 Steve Cohen a écrit :
> What with the Codehaus "termination of Maven services" and other recent
> developments, what has happened to the handy list of predefined project
> properties and other properties that was once but no longer is available
> from http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide ?
> I need to look up one stinking property that I know I've used before and
> can't find any listings of these.  I can't believe how difficult this
> information has become to find.
> 
> Can someone provide a link to such a list?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

[ANN] Apache Maven Project Info Reports Plugin 2.8.1 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Project 
Info Reports Plugin, version 2.8.1

The Maven Project Info Reports Plugin is a plugin that generates standard 
reports
for the specified project.

http://maven.apache.org/plugins/maven-project-info-reports-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-project-info-reports-plugin
  2.8.1



Release Notes - Apache Maven Project Info Reports Plugin - Version 2.8.1

Bug
* [MPIR-300] Reporting plugins are reported with wrong version if version 
specified via pluginManagement

Improvement
* [MPIR-329] French translation in project-info-report_fr.properties

Task
* [MPIR-333] switch to Fluido
* [MPIR-332] don't warn when removing path from git scm url


Enjoy,

-The Maven team


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

Re: oss push to maven central?

[Hervé BOUTEMY]

notice that search index is updated independently from artifacts themselves:
you should check and be explicit if the content isn't published (ie you don't 
see the artifact in https://repo.maven.apache.org/maven2/...your groupId/your 
artifactid/) or if you don't have it in search result

Regards,

Hervé

Le samedi 12 septembre 2015 21:23:02 Jordan Zimmerman a écrit :
> Sure - thanks.
> 
> 
> 
> On September 12, 2015 at 9:21:06 PM, Dan Tran (dant...@gmail.com) wrote:
> 
> You may want to ping Sonatype instead. I just release maven-wagon at
> repository.apache.org, it went thru within 10 minutes
> 
> -Dan
> 
> On Sat, Sep 12, 2015 at 7:14 PM, Jordan Zimmerman <
> 
> jor...@jordanzimmerman.com> wrote:
> > Hi,
> > 
> > I released from oss.sonatype.org on Friday and it's still not showing
> > on Maven Central. What's up?
> > 
> > -Jordan
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org


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

Re: Reactor projects and ${project.version}

[Hervé BOUTEMY]

the only difference I see, and which makes a huge difference, is that the value 
has to be calculated also when effective model is built from repository 
(instead of project direct build, with its reactor)

I fear it is not so trivial in the context of repository calculation, since 
there is no more reactor available

http://maven.apache.org/ref/3-LATEST/maven-model-builder/

Regards,

Hervé

Le mercredi 16 septembre 2015 19:36:53 Jason van Zyl a écrit :
> Or a core extension but this change is likely not that hard and meshes with
> what we’ve done with the .mvn directory which is to signify the root of the
> reactor.
> > On Sep 16, 2015, at 12:20 PM, Jordan Zimmerman
> >  wrote:
> > 
> > I spoke with Jason and it turns out what I want to do requires a
> > change to core. Therefore:
> > https://issues.apache.org/jira/browse/MNG-5890
> > 
> > On Wed, Sep 16, 2015 at 9:01 AM, Ron Wheeler
> > 
> >  wrote:
> >> Why not make three new separate projects that produce the required war
> >> files.
> >> Only put the minimum configuration in the new projects and let them
> >> depend
> >> on jars that contain the shared code and resources.
> >> 
> >> Maven prefers to produce 1 artifact per project.
> >> 
> >> On 16/09/2015 2:29 AM, Neeraj Malik wrote:
> >>> Dear All,
> >>> 
> >>> I am using maven 3.2.5
> >>> 
> >>> i want to use difference property files to build war for diff
> >>> environments
> >>> and deploy it on local, test and prod accordingly based on maven command
> >>> -
> >>> mvn -Plocal clean install
> >>> 
> >>> 
> >>> /resources/local/env.properties
> >>> /resources/test/env.properties
> >>> /resources/prod/env.properties
> >>> 
> >>> local env property file -
> >>> weblogic.splitDevelopmentDirectoryMode = false
> >>> weblogic.targetName = AdminServer
> >>> weblogic.protocal = http
> >>> weblogic.url = localhost
> >>> weblogic.port = 7001
> >>> weblogic.user = user
> >>> weblogic.password = pass123
> >>> weblogic.upload = false
> >>> weblogic.remote = false
> >>> weblogic.verbose = false
> >>> weblogic.debug = false
> >>> weblogic.noExit = true
> >>> project.build.directory =
> >>> 
> >>> 
> >>> Can you please suggest whats wrong with given POM.
> >>> 
> >>> Thanks.
> >>> 
> >>> Regards
> >>> Neeraj
> >>> 
> >>> 
> >>> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> >>> http://www.w3.org/2001/XMLSchema-instance;
> >>> 
> >>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> >>> 
> >>> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
> >>> 
> >>> 4.0.0
> >>> com.purchase
> >>> Invoice
> >>> 1.0
> >>> war
> >>> 
> >>> 
> >>> 
> >>> 
> >>>
> >>>
> >>>local
> >>> 
> >>> 
> >>> 
> >>>false
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> ${project.basedir}/src/main/resources
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> ${project.basedir}/src/test/resources
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  
> >>>  
> >>>
> >>>
> >>> 
> >>> 
> >>> com.oracle.weblogic
> >>> weblogic-maven-plugin
> >>> 10.3.4
> >>> 
> >>>
> >>>
> >>> 
> >>> 
> >>> install
> >>> 
> >>> 
> >>> deploy
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>
> >>>
> >>>  
> >>>  
> >>>
> >>>
> >>>   
> >>>   
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> weblogic-path
> >>> weblogic-path
> >>> system
> >>> ${WL_HOME}/server/lib/weblogic.jar
> >>> 10.3.5
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> log4j
> >>> log4j
> >>> 1.2.15
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> src/main/resources
> >>> 
> >>> 
> >>> **/*.java
> >>> 
> 

Re: Generate archetype from latest version?

[Hervé BOUTEMY]

did you try to use 'RELEASE' as version?

Regards,

Hervé

Le vendredi 18 septembre 2015 09:22:46 Jordan Zimmerman a écrit :
> Is it possible to tell the Archetype plugin to use the latest version of an
> archetype when generating? That would make it far easier to script. 
> 
> -Jordan


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

Re: Velocity - Archetypes Question

[Hervé BOUTEMY]

Hi

see 
http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html

"The maven-archetype-plugin uses Velocity to expand template files, and this 
documentation talks about 'Velocity Properties', which are values substituted 
into Velocity templates. See The Velocity User's Guide for more information."

Regards,

Hervé

Le mardi 1 décembre 2015 22:44:36 Maria Beckham a écrit :
> Hi there,
> Are archetypes in maven by default based on velocity engine/templates
> processing? If not, could someone pls provide us an sample example of maven
> archetypes using velocity templates(like say for example generating java
> source code)
> 
> Thanks,Maria


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

Re: How to use 5 digit version numbers with Maven ?

[Hervé BOUTEMY]

in fact, the way the issue is described is misleading:
"How to use 5 digit version numbers with Maven ?" and
"Maven only handles 3 digit version numbers using the versions-maven-plugin"

it should be phrased:
"How to use 5 digit version numbers with versions-maven-plugin?" and
"versions-maven-plugin only handles 3 digit version numbers"


because Maven itself has no limitation on digits: like Karl Heinz pointed out, 
there was a limitation in Maven 2, but it was removed in Maven 3 with 
https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning


and FYI, Maven itself does only comparison on versions, no updates

Plugins can do a lot of different things, and multiple plugins propose to 
update version: the most known being maven-release-plugin (from Apache Maven 
team) and versions-maven-plugin (from MojoHaus team)


Regards,

Hervé
(who worked hard a few yeas ago on removing the limitation in Maven 3 :) )

Le jeudi 7 janvier 2016 20:16:44 Karl Heinz Marbaise a écrit :
> Hi,
> 
> On 1/7/16 1:08 PM, Mehul Sanghvi wrote:
> > We need to use 5 digit version numbers going forward.  Maven only handles
> > 3
> > digit version numbers
> 
> where is this documented ?
> 
> which is simply not true.
> 
> https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
> 
> Since Maven 3 you can use as many version numbers as you like...
> 
> > using the versions-maven-plugin.  Is there a way to use 5 digits for
> > project.version ?
> > 
> > What we want to do is use 1.2.3.4.5-SNAPSHOT vs 1.2.3-SNAPSHOT and
> > 1.2.3.4.5 vs 1.2.3 after
> > the release.
> 
> You should simply use itcause it works...
> 
> 
> Furthermore if you use Maven 3.2.5+ you can check the behaviour on
> command line via: (You have to change the maven-artifact-VERSION.jar
> accordingly to your Maven installation) this small CLI app which is
> included in your maven distribution:
> 
> ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar
> 1.0.2.5-SNAPSHOT 1.0.2.6-SNAPSHOT
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1.0.2.5-SNAPSHOT == 1.0.2.5-snapshot
> 1.0.2.5-SNAPSHOT < 1.0.2.6-SNAPSHOT
> 2. 1.0.2.6-SNAPSHOT == 1.0.2.6-snapshot
> ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar
> 1.0.2.5.0.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1.0.2.5.0.0-SNAPSHOT == 1.0.2.5-snapshot
> 1.0.2.5.0.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT
> 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot
> ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar
> 1.0.2.5.10.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1.0.2.5.10.0-SNAPSHOT == 1.0.2.5.10-snapshot
> 1.0.2.5.10.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT
> 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot
> ~$ java -jar /usr/share/maven/lib/maven-artifact-3.2.5.jar
> 1.0.2.5.100.0-SNAPSHOT 1.0.2.6.0.0-SNAPSHOT
> Display parameters as parsed by Maven (in canonical form) and comparison
> result:
> 1. 1.0.2.5.100.0-SNAPSHOT == 1.0.2.5.100-snapshot
> 1.0.2.5.100.0-SNAPSHOT < 1.0.2.6.0.0-SNAPSHOT
> 2. 1.0.2.6.0.0-SNAPSHOT == 1.0.2.6-snapshot
> 
> 
> Kind regards
> Karl Heinz Marbaise
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Re: [VOTE] Retire Maven Application Skin, Maven Classic Skin, Maven Stylus Skin

[Hervé BOUTEMY]

+1

Regards,

Hervé

Le jeudi 24 décembre 2015 23:34:36 Michael Osipov a écrit :
> Hi,
> 
> as previously suggested, it makes sense to retire those skins because
> they haven't been updated for a long time and we don't have the resources
> to maintain them properly [1].
> 
> Last releases:
> Maven Application Skin: 2012-01-18
> Maven Classic Skin: 2012-01-18
> Maven Stylus Skin: 2012-07-30
> 
> I therefore propose that we retire these skins.
> 
> If this vote is successful I will make one final release of the skin, making
> it clear on the skin site that it has been retired. After that the source
> code will be moved into the "retired" area in our Subversion repository.
> 
> The process for retiring a skin is described here:
> http://maven.apache.org/developers/retirement-plan-plugins.html
> (Though these aren't plugins, the process is universal)
> 
> The vote is open for 72 hours.
> 
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
> 
> I would ask kindly those who have already cast their vote to revote to make
> it "official".
> 
> [1]
> http://mail-archives.apache.org/mod_mbox/maven-dev/201512.mbox/%3Ctrinity-8
> ab6577c-ab69-4f9f-86e6-533e0b309a94-1450902628141%403capp-gmx-bs54%3E
> 
> Michael
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Re: doxia-module-confluence : NullPointerException parsing table cell with single space

[Hervé BOUTEMY]

please open a Jira issue:
https://issues.apache.org/jira/browse/DOXIA/

then, if you can, in addition to your explanations, please provide your test 
case as a patch to unit test for the Doxia module:
http://svn.apache.org/repos/asf/maven/doxia/doxia/trunk/doxia-modules/doxia-module-confluence/

and ideally, a patch to fix the issue :)


I'll release Doxia 1.7 shortly, to be able release maven-site-plugin 3.5

I'll try to fix your issue, but not sure (markup parsing is not my main 
skill...)

Regards,

Hervé

Le lundi 18 janvier 2016 07:55:08 Roos Robin a écrit :
> Hi Folks
> 
> I have chosen to use Confluence format to generate my maven site, primarily
> because of good table support.
> 
> I have found that doxia-module-confluence falls over with a
> NullPointerException if an empty cell is represented as a single space.
> 
> Confluence tables usually require this empty space, or they collapse the
> cell to be non-existant.
> 
> Information pertaining to this failure is below.
> 
> Let me know what more I can usefully provide.
> 
> Kind regards, Robin.
> 
> 
> 
> 
> File: src/site/confluence/tables.confluence
> 
> Here is a 3 column table with headers, one row, and data in every column:
> ||One||Two||Three||
> |
> |1|2|3|
> 
> Now there is no data in column Two
> 
> ||One||Two||Three||
> |
> |1||3|
> 
> Now there is a space in column Two
> 
> ||One||Two||Three||
> |
> |1| |3|
> 
> pom.xml excerpt
> 
> 
> 
> 
> ...
> 
> ...
> 
> 
> org.apache.maven.plugins
> maven-site-plugin
> 3.4
> 
> 
> org.apache.maven.doxia
> doxia-module-confluence
> 1.6
> 
> 
> org.apache.maven.doxia
> doxia-module-markdown
> 1.6
> 
> 
> 
> 
> 
> 
> 
> mvn -X clean site
> 
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
> project fitnesse-calypso: Error parsing
> '/Users/robin/tmp3/fitnesse-calypso/src/site/confluence/tables.confluence':
> line [15] null: ParseException: NullPointerException -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
> project fitnesse-calypso: Error parsing
> '/Users/robin/tmp3/fitnesse-calypso/src/site/confluence/tables.confluence':
> line [15] null at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
> 212) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
> 153) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
> 145) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lif
> ecycleModuleBuilder.java:116) at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Lif
> ecycleModuleBuilder.java:80) at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBu
> ilder.build(SingleThreadedBuilder.java:51) at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStart
> er.java:128) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:6
> 2) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
> l.java:43) at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.j
> ava:289) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher
> .java:415) at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error parsing
> '/Users/robin/tmp3/fitnesse-calypso/src/site/confluence/tables.confluence':
> line [15] null at
> org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:146) at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
> luginManager.java:134) at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
> 207) ... 20 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> parsing
> '/Users/robin/tmp3/fitnesse-calypso/src/site/confluence/tables.confluence':
> line [15] null at
> 

Re: own Maven Site plugin

[Hervé BOUTEMY]

IIRC, you're trying to create a reporting plugin, ie a report that can 
contribute to a Maven site

maven-reporting-impl is the component you need, with included example:
http://maven.apache.org/shared/maven-reporting-impl/

Regards,

Hervé

Le samedi 25 juin 2016 22:44:01 Philipp Kraus a écrit :
> Hello,
> 
> I try to build my first Maven site plugin.
> I have defined a class based on AbstractMojo and
> put the annotation @Mojo( name = "rrd-antlr4", defaultPhase =
> LifecyclePhase.SITE ) on top.
> 
> I overload the execute-method and put my plugin content to the method. I
> build the plugin and deploy it my local Maven repository. I’m testing my
> plugin in a testing project with the pom content 
> 
> 
> 
> 
> de.flashpixx
> rrd-antlr4
> 0.1.0
> 
> …..
> 
> If I run "mvn site“ I get "[INFO] configuring report plugin
> de.flashpixx:rrd-antlr4:0.1.0“ but the execute method is not run / called.
> 
> How I can debug the plugin or fix the execution of the plugin?
> 
> Thanks
> 
> Phil


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

[ANN] Apache Maven Doxia 1.7 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Doxia, version 1.7 (which will be used in a future 3.5 version of maven-site-
plugin)
 
Doxia is a content generation framework that provides powerful techniques for 
generating static and dynamic content, supporting a variety of markup 
languages.
 
http://maven.apache.org/doxia/doxia/
 
You can download the appropriate sources etc. from the download page:
 
http://maven.apache.org/doxia/doxia/download.cgi
 

Release Notes - Maven Doxia - Version 1.7

** Bug
* [DOXIA-482] - add an API to avoid translating APT source comments into 
output comments
* [DOXIA-485] - Outdated links in xdoc format description
* [DOXIA-508] - Format characters are interpreted in monospaced text
* [DOXIA-524] - ISO-8859-15 encoding problem with markdown 
* [DOXIA-537] - NullPointerException parsing table cell with single space

** Improvement
* [DOXIA-203] - Add support for level 6 sections and generalize Sink API 
for sections
* [DOXIA-492] - Add support for doxia macros in markdown documents.
* [DOXIA-505] - Upgrade to Commons Configuration 1.10
* [DOXIA-527] - Allow multiple extensions for given format
* [DOXIA-529] - Add macro support to XHTML 

** New Feature
* [DOXIA-224] - Add source name in parser
* [DOXIA-532] - Update handling of comments for Server Side Includes (ie 
comments starting with #)
* [DOXIA-535] - Support .markdown file extension (in addition to current 
.md)

** Task
* [DOXIA-511] - remove deprecated o.a.m.doxia.module.site package
* [DOXIA-526] - remove xerces:xercesImpl dependency
* [DOXIA-531] - improve MacroRequest API with parser and sourceContent 
parameters requirements

** Wish
* [DOXIA-506] - move classes from doxia-core in sink package (same as 
doxia-sink-api) to dedicated sink.impl package


Enjoy,
 
-The Apache Maven team

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

Re: maven-site-plugin 3.5 ClassNotFoundException

[Hervé BOUTEMY]

Hi Maxim,

That's typical of a forced dependency to doxia-core version 1.6 or less (which 
is typical from a project inheriting from an ASF version 17 parent POM because 
of MPOM-69 fix).

I'm still waiting for a little more feedback before releasing ASF parent POM 
version 18 with maven-site-plugin 3.5 (and no Doxia core version forcing).

Now, you should simply add a dependency to maven-site-plugin 3.5 to doxia-core 
version 1.7 and everything will work as expected.

Regards,

Hervé

Le mercredi 24 février 2016 11:21:00 Maxim Solodovnik a écrit :
> Hello All,
> 
> I'm trying to switch to maven-site-plugin 3.5
> unfortunately I'm getting ClassNotFoundException,
> 
> solomax@solomax-pc:$ *mvn -version*
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T22:41:47+06:00)
> Maven home: /opt/maven
> Java version: 1.8.0_66, vendor: Oracle Corporation
> Java home: /opt/jdk1.8.0_66/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.13.0-63-generic", arch: "amd64", family:
> "unix"
> 
> solomax@solomax-pc:$ *java -version*
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> 
> Ubuntu 14.04.3 LTS
> 
> 3.4 works as expecting
> 
> What am I doing wrong?
> 
> here is the stack trace:
> 
> [WARNING] Error injecting: org.apache.maven.plugins.site.render.SiteMojo
> java.lang.NoClassDefFoundError:
> org/apache/maven/doxia/sink/impl/XhtmlBaseSink
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassReal
> m.java:401) at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFir
> stStrategy.java:42) at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(Cla
> ssRealm.java:271) at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:2
> 47) at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:2
> 39) at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassReal
> m.java:401) at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFir
> stStrategy.java:42) at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(Cla
> ssRealm.java:271) at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:2
> 47) at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:2
> 39) at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
> at java.lang.Class.getDeclaredMethods(Class.java:1975)
> at
> com.google.inject.spi.InjectionPoint.getInjectionPoints(InjectionPoint.java:
> 688) at
> com.google.inject.spi.InjectionPoint.forInstanceMethodsAndFields(InjectionPo
> int.java:380) at
> com.google.inject.internal.ConstructorBindingImpl.getInternalDependencies(Co
> nstructorBindingImpl.java:164) at
> com.google.inject.internal.InjectorImpl.getInternalDependencies(InjectorImpl
> .java:613) at
> com.google.inject.internal.InjectorImpl.cleanup(InjectorImpl.java:569) at
> com.google.inject.internal.InjectorImpl.initializeJitBinding(InjectorImpl.ja
> va:555) at
> com.google.inject.internal.InjectorImpl.createJustInTimeBinding(InjectorImpl
> .java:884) at
> com.google.inject.internal.InjectorImpl.createJustInTimeBindingRecursive(Inj
> ectorImpl.java:805) at
> com.google.inject.internal.InjectorImpl.getJustInTimeBinding(InjectorImpl.ja
> va:282) at
> com.google.inject.internal.InjectorImpl.getBindingOrThrow(InjectorImpl.java:
> 214) at
> com.google.inject.internal.InjectorImpl.getProviderOrThrow(InjectorImpl.java
> :1006) at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1038)
> at
> com.google.inject.internal.InjectorImpl.getProvider(InjectorImpl.java:1001)
> at
> 

Re: maven-site-plugin 3.5 ClassNotFoundException

[Hervé BOUTEMY]

Hi,

Not sure there is not a misunderstanding about the new dependency: it's on 
maven-site-plugin to override what I did on ASF v17 [1], not your project 
(hopefully, the build tool requirements don't affect your project 
dependencies). That is like Velocity downgrade [2]:

  org.apache.maven.plugins
  maven-site-plugin
  

  org.apache.maven.doxia
  doxia-core
  1.7

  



I'm waiting for Fluido 1.5 before releasing ASF v18: yes, I'll announce when 
it is ready.

Regards,

Hervé

[1] 
http://svn.apache.org/viewvc/maven/pom/tags/apache-17/pom.xml?view=markup#l234

[2] http://maven.apache.org/plugins/maven-site-plugin/migrate.html

Le mercredi 24 février 2016 13:47:25 Maxim Solodovnik a écrit :
> Hello Hervé,
> 
> Thanks for the quick answer
> I'll wait for apache parent #18, don't want to add additional dependency
> 
> Are you going to announce #18?
> 
> 
> On Wed, Feb 24, 2016 at 12:58 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> 
> wrote:
> > Hi Maxim,
> > 
> > That's typical of a forced dependency to doxia-core version 1.6 or less
> > (which
> > is typical from a project inheriting from an ASF version 17 parent POM
> > because
> > of MPOM-69 fix).
> > 
> > I'm still waiting for a little more feedback before releasing ASF parent
> > POM
> > version 18 with maven-site-plugin 3.5 (and no Doxia core version forcing).
> > 
> > Now, you should simply add a dependency to maven-site-plugin 3.5 to
> > doxia-core
> > version 1.7 and everything will work as expected.
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mercredi 24 février 2016 11:21:00 Maxim Solodovnik a écrit :
> > > Hello All,
> > > 
> > > I'm trying to switch to maven-site-plugin 3.5
> > > unfortunately I'm getting ClassNotFoundException,
> > > 
> > > solomax@solomax-pc:$ *mvn -version*
> > > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> > > 2015-11-10T22:41:47+06:00)
> > > Maven home: /opt/maven
> > > Java version: 1.8.0_66, vendor: Oracle Corporation
> > > Java home: /opt/jdk1.8.0_66/jre
> > > Default locale: en_US, platform encoding: UTF-8
> > > OS name: "linux", version: "3.13.0-63-generic", arch: "amd64", family:
> > > "unix"
> > > 
> > > solomax@solomax-pc:$ *java -version*
> > > java version "1.8.0_66"
> > > Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> > > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> > > 
> > > Ubuntu 14.04.3 LTS
> > > 
> > > 3.4 works as expecting
> > > 
> > > What am I doing wrong?
> > > 
> > > here is the stack trace:
> > > 
> > > [WARNING] Error injecting: org.apache.maven.plugins.site.render.SiteMojo
> > > java.lang.NoClassDefFoundError:
> > > org/apache/maven/doxia/sink/impl/XhtmlBaseSink
> > > at java.lang.ClassLoader.defineClass1(Native Method)
> > > at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> > > at
> > 
> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> > 
> > > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
> > > at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> > > at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
> > > at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
> > > at java.security.AccessController.doPrivileged(Native Method)
> > > at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
> > > at
> > 
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRe
> > al> 
> > > m.java:401) at
> > 
> > org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfF
> > ir> 
> > > stStrategy.java:42) at
> > 
> > org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(C
> > la> 
> > > ssRealm.java:271) at
> > 
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java
> > :2> 
> > > 47) at
> > 
> > org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java
> > :2> 
> > > 39) at java.lang.ClassLoader.defineClass1(Native Method)
> > > at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> > > at
> > 
> > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> > 
> > > at java.net.URLClassLoader.defineClass(URLClassLoader.

[ANN] Apache Maven Doxia Sitetools 1.7 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Doxia Sitetools, version 1.7
 
Doxia Sitetools is an extension of base Doxia component that generates either 
HTML sites, consisting of decoration and content that was generated by Doxia, 
or documents like RTF or PDF.
 
http://maven.apache.org/doxia/doxia-sitetools/
 
You can download the appropriate sources etc. from the download page:
 
http://maven.apache.org/doxia/doxia-sitetools/download.cgi
 

Release Notes - Maven Doxia Sitetools - Version 1.7

** Bug
* [DOXIASITETOOLS-93] - request-scoped default Velocity Tools are not 
accessible
* [DOXIASITETOOLS-107] - Fix link to plexus page in the doxia-site-
renderer web page
* [DOXIASITETOOLS-130] - Doxia document not rendered if "." in 
filename
* [DOXIASITETOOLS-145] - when called from Maven 3, 
SiteTool.getParentProject() should just return project.getParent()

** Improvement
* [DOXIASITETOOLS-82] - Decoration model body/footer type mismatch
* [DOXIASITETOOLS-94] - add plexus container to Velocity context
* [DOXIASITETOOLS-99] - Add typed context variable for creationDate
* [DOXIASITETOOLS-100] - Deprecate all context properties which are 
duplicate or already available through Velocity tools
* [DOXIASITETOOLS-102] - Allow multiple extensions for given format
* [DOXIASITETOOLS-103] - Don't create outputFile in case of an external 
report
* [DOXIASITETOOLS-105] - add Markdown to dependencies
* [DOXIASITETOOLS-118] - Separate inheritance and interpolation 
* [DOXIASITETOOLS-120] - Print artifactId only in modules menu when module 
has no name
* [DOXIASITETOOLS-122] - improve API regarding locales
* [DOXIASITETOOLS-126] - don't copy resources when rendering documents but 
copy all resources in 1 call
* [DOXIASITETOOLS-132] - do not override existing content with template 
when copyResources()
* [DOXIASITETOOLS-136] - improve "Could not parse date: ..., ignoring!" 
message with document reference
* [DOXIASITETOOLS-147] - link breadcrumbs to index.html instead of 
directory (like menus)
* [DOXIASITETOOLS-155] - Change type of decoration model's body/head 
element to string

** New Feature
* [DOXIASITETOOLS-133] - for Velocity processed Doxia files 
(*.extension.vm), add an option to dump generated markup (= *.extension)
* [DOXIASITETOOLS-149] - Create a skin descriptor to contain metadata 
about the skin
* [DOXIASITETOOLS-150] - create a "isLink(href)" function for use in skins
* [DOXIASITETOOLS-154] - Add encoding to skin descriptor to define the 
encoding of site.vm

** Task
* [DOXIASITETOOLS-98] - Decoration model's Modello doc point to a 
statically versioned schema file
* [DOXIASITETOOLS-115] - move doxia-integration-tools from Doxia Tools to 
Doxia Sitetools
* [DOXIASITETOOLS-123] - remove long deprecated SiteTool API
* [DOXIASITETOOLS-125] - getDecorationModel() change siteDirectory from 
String to File
* [DOXIASITETOOLS-131] - don't add Template-specific variables in general 
document Velocity context
* [DOXIASITETOOLS-134] - Remove special handling of date format in 
DefaultSiteRenderer
* [DOXIASITETOOLS-135] - Make input source file encoding default to 
platform encoding
* [DOXIASITETOOLS-137] - add documentation on how site is rendered, 
merging documents and decoration
* [DOXIASITETOOLS-138] - remove skinFile parameter from 
createContextForTemplate
* [DOXIASITETOOLS-151] - Upgrade default skin to Default Skin 1.1
* [DOXIASITETOOLS-153] - Deprecate direct template usage in favor of skin 
only

** Wish
* [DOXIASITETOOLS-92] - Upgrade Velocity from 1.5 to 1.7
* [DOXIASITETOOLS-124] - streamline SiteTools API: hide methods that are 
only used internally
* [DOXIASITETOOLS-139] - don't render Apache license from default template
* [DOXIASITETOOLS-146] - don't translate APT source comments into output 
comments

 
Enjoy,
 
-The Apache Maven team

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

[ANN] Apache Maven Site Plugin 3.5 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Site Plugin, version 3.5
 
The Site Plugin is used to generate a site for the project. The generated site 
also includes the project's reports that were configured in the POM.
 
http://maven.apache.org/plugins/maven-site-plugin/
 
Notice there are breaking changes to know when upgrading:
http://maven.apache.org/plugins/maven-site-plugin/migrate.html

You should specify the version in your project's plugin configuration:
 

  org.apache.maven.plugins
  maven-site-plugin
  3.5

 
You can download the appropriate sources etc. from the download page:
 
http://maven.apache.org/plugins/maven-site-plugin/download.cgi
 

Release Notes - Maven Site Plugin - Version 3.5

** Sub-task
* [MSITE-762] - Upgrade Velocity from 1.5 to 1.7

** Bug
* [MSITE-135] - inherited site.xml files are interpolated with the 
originating project's model values and not the consumer project's values
* [MSITE-604] - Properties from settings.xml are not recognized in site 
distribution management 
* [MSITE-694] - When maven.site.skip=true, mvn site:jar doesn't skip the 
generation of the jar
* [MSITE-702] - Overriding skin resources / Duplicate copying of skin 
resources
* [MSITE-724] - An API incompatibility was encountered while executing 
org.apache.maven.plugins:maven-site-plugin:3.4:jar
* [MSITE-743] - Automatic breadcrumbs generates URLs inconsistent with 
menus: should point to index.html
* [MSITE-744] - Regression in 3.4: File in `generated-site/resources/` 
ignored unless there is a file in `generated-site/markdown/` too
* [MSITE-750] - site plugin doesn't override correctly parent 
distributionManagement site url with another one defined in child project when 
dav:
* [MSITE-752] - Cannot use server side includes.
* [MSITE-754] - ConcurrentModificationException when using site:run
* [MSITE-760] - when using templateFile, skin is downloaded and info 
message "Rendering site with skin"

** Improvement
* [MSITE-696] - site:deploy try to deploy the site of a sub module even if 
the property maven.site.skip is set to true
* [MSITE-708] - Doc about filtering incorrect about macros rules
* [MSITE-723] - "About" report generated even though index.apt is 
available in "generated-site"
* [MSITE-727] - MavenProject/MavenSession Injection as a paremeter instead 
as a component.
* [MSITE-729] - Update version of plexus-archiver to 2.9
* [MSITE-740] - Allow multiple extensions for given format
* [MSITE-746] - FAQ contains inaccurate description regarding the site 
life cycle
* [MSITE-755] - Upgrade Doxia Sitetools from 1.6 to 1.7
* [MSITE-765] - upgrade Doxia from 1.6 to 1.7

** New Feature
* [MSITE-756] - add an option to dump Velocity processed Doxia files

** Task
* [MSITE-753] - remove deprecated template and templateDirectory 
parameters
* [MSITE-759] - Update "Configuring the Site Descriptor" page for Doxia 
(Sitetools) 1.7
* [MSITE-763] - Fix issues reported by dependency:analyze
* [MSITE-766] - Upgrade to Commons Lang 3

** Wish
* [MSITE-326] - Make input source file encoding default to platform 
encoding

 
Enjoy,
 
-The Apache Maven team

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

Re: Maven Fluido Skin incompatibility with new maven-site-plugin 3.5

[Hervé BOUTEMY]

Hi Anthony,

Yes, you're completely right: we're working on it, and tried to make clear 
that Fluido Skin 1.4 is not immediately compatible with Maven Site Plugin 3.5 
[1]

It should be done in 1 or 2 weeks, dependings on the order in which we'll have 
to do the work (perhaps we'll need to to a parent pom release first, I still 
have to wotk on this with Michael Osipov).

In the meantime, you can use the "Velocity 1.5 dependency" workaround I 
documented [2]

Regards,

Hervé

[1] http://maven.apache.org/skins/index.html

[2] http://maven.apache.org/plugins/maven-site-plugin/migrate.html

Le samedi 20 février 2016 05:11:06 Anthony Whitford a écrit :
> I noticed that maven-site-plugin 3.5 does not work with maven-fluido-skin
> 1.4… This looks well known from inspecting the JIRA issues for the skin,
> but when will maven-fluido-skin-1.5 be released?
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Re: Site Plugin 3.5 URL behavior and multi-module builds

[Hervé BOUTEMY]

yes, it is expected behaviour: see "inheritance assembly" step of model 
builder [1]

in your case, your config cause artifactId to be added twice: one on 
project.url and one on site.url before ${project.url} is interpolated

You should just not use ${project.url} in distributionManagement/site: that's 
what is causing you the issue



Notice: this strategy (adding artifactId) was perfect for a good number of 
years, when sites were deployed to filesystems: with sites deployed to git, it 
is known that it does not fit this case, and you're not the first to complain 
(without really understanding why "it does not work as expected" on your case: 
the important part here is *on your case*, because this git case is what cause 
some new requirements that did not exist before)

I have prepared a new feature for (future) Maven 3.4.0 in MNG-5951 [2]
This will give attributes to disable artifactId addition on fields that have 
this url inheritance feature


HTH

Regards,

Hervé


[1] http://maven.apache.org/ref/3-LATEST/maven-model-builder/

[2] https://issues.apache.org/jira/browse/MNG-5951

Le jeudi 10 mars 2016 09:29:09 Elliot Metsger a écrit :
> Hi,
> 
> I'm using the Maven site plugin with a multi-module build.  The generated
> site is going to be deployed to GitHub, so I'm only using the Maven site
> plugin to generate and stage content locally, not deploy.
> 
> I have a placeholder distributionManagement/site element in my POM so that
> site:stage can generate links between the modules of my site.  However, my
> child modules are getting inexplicable values for their site url:
> 
> Parent module distributionManagement/site (${project.url} =
> http://dataconservancy.github.io/package-ingest):
> 
>   
> 
>   github
>   GitHub Pages Website
>   ${project.url}
> 
>   
> 
> Parent module, help:effective-pom:
> 
>   
> github
> GitHub Pages Website
> http://dataconservancy.github.io/package-ingest
>   
> 
> 
> So far, so good.  However, the child module's
> distributionManagement/site/url is not what I expected.  Notice that the
> child module name 'package-ingest-api' is repeated twice in the url:
> 
> Child module, help:effective-pom (project url =
> http://dataconservancy.github.io/package-ingest/package-ingest-api/)
>   
> 
>   github
>   GitHub Pages Website
>   
> http://dataconservancy.github.io/package-ingest/package-ingest-api/package-i
> ngest-api 
> 
>   
> 
> Is this expected behavior?
> 
> Thanks,
> Elliot


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

Re: maven-site-plugin 3.5 ClassNotFoundException

[Hervé BOUTEMY]

great, thanks for the feedback

Regards,

Hervé

Le jeudi 7 avril 2016 12:45:53 Maxim Solodovnik a écrit :
> seems to work as expected with
> 
> 
> 
> 
> site was generated as expected
> I can see no issues with content or layout
> 
> I would say: works for me :)
> 
> On Thu, Apr 7, 2016 at 12:39 PM, Maxim Solodovnik <solomax...@gmail.com>
> 
> wrote:
> > I have changed
> > parent version to be 18-SNAPSHOT
> > maven-site version to be 3.5
> > maven-fluido-skin version to be 1.5
> > 
> > it seems my site.xml is not valid anymore the error is
> > 
> > [ERROR] Failed to execute goal
> > org.apache.maven.plugins:maven-site-plugin:3.5:site (generate-site) on
> > project openmeetings-parent: SiteToolException: Error parsing site
> > descriptor: TEXT must be immediately followed by END_TAG and not START_TAG
> > (position: START_TAG seen ..."text/javascript" src="
> > http://openmeetings.apache.org/js/site.js;>... @40:83) -> [Help 1]
> > 
> > 
> > here:
> > 
> > http://openmeetings.apache.org/js/site.js&quot</a>;>
> > 
> > 
> > Will try to check CHANGELOG for maven-site-plugin
> > 
> > 
> > On Thu, Apr 7, 2016 at 12:29 PM, Maxim Solodovnik <solomax...@gmail.com>
> > 
> > wrote:
> >> Thanks for letting me know
> >> will test right now
> >> 
> >> 
> >> On Thu, Apr 7, 2016 at 12:26 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> >> 
> >> wrote:
> >>> Hi Maxim,
> >>> 
> >>> I just updated 18-SNAPSHOT to use Doxia Sitetools 1.7.1, which contains
> >>> early
> >>> interpolation ${this.*} feature [1]
> >>> 
> >>> It would be great to have some tests from end users before I do the
> >>> maven-
> >>> site-plugin 3.5.1 release
> >>> 
> >>> Regards,
> >>> 
> >>> Hervé
> >>> 
> >>> 
> >>> [1]
> >>> http://maven.apache.org/doxia/doxia-sitetools/doxia-integration-tools/in
> >>> dex.html>>> 
> >>> Le jeudi 3 mars 2016 22:11:59 Maxim Solodovnik a écrit :
> >>> > please let me know if you need any help in testing :)
> >>> > 
> >>> > On Thu, Mar 3, 2016 at 10:07 PM, <herve.bout...@free.fr> wrote:
> >>> > > 18-SNAPSHOT is ready
> >>> > > 
> >>> > > but there are a few feedbacks on edge case issues: I'm torn if we
> >>> 
> >>> should
> >>> 
> >>> > > release now or wait for 3.5.1
> >>> > > 
> >>> > > Regards,
> >>> > > 
> >>> > > Hervé
> >>> > > 
> >>> > > - Mail original -
> >>> > > De: "Maxim Solodovnik" <solomax...@gmail.com>
> >>> > > À: "Maven Users List" <users@maven.apache.org>
> >>> > > Envoyé: Jeudi 3 Mars 2016 09:54:10
> >>> > > Objet: Re: maven-site-plugin 3.5 ClassNotFoundException
> >>> > > 
> >>> > > Is it time to release apache parent 18? :)
> >>> > > 
> >>> > > WBR, Maxim
> >>> > > (from mobile, sorry for the typos)
> >>> > > 
> >>> > > On Feb 27, 2016 14:04, "Maxim Solodovnik" <solomax...@gmail.com>
> >>> 
> >>> wrote:
> >>> > > > Thanks a lot!
> >>> > > > I'll wait for the announce and then will test :)
> >>> > > > 
> >>> > > > On Thu, Feb 25, 2016 at 12:47 PM, Hervé BOUTEMY <
> >>> 
> >>> herve.bout...@free.fr>
> >>> 
> >>> > > > wrote:
> >>> > > >> Hi,
> >>> > > >> 
> >>> > > >> Not sure there is not a misunderstanding about the new
> >>> 
> >>> dependency: it's
> >>> 
> >>> > > on
> >>> > > 
> >>> > > >> maven-site-plugin to override what I did on ASF v17 [1], not your
> >>> > > 
> >>> > > project
> >>> > > 
> >>> > > >> (hopefully, the build tool requirements don't affect your project
> >>> > > >> 
> >>> > > >> dependencies). That is like Velocity downgrade [2]:
> >>> > > >> 

Re: maven-site-plugin 3.5 ClassNotFoundException

[Hervé BOUTEMY]

Hi Maxim,

I just updated 18-SNAPSHOT to use Doxia Sitetools 1.7.1, which contains early 
interpolation ${this.*} feature [1]

It would be great to have some tests from end users before I do the maven-
site-plugin 3.5.1 release

Regards,

Hervé


[1] 
http://maven.apache.org/doxia/doxia-sitetools/doxia-integration-tools/index.html

Le jeudi 3 mars 2016 22:11:59 Maxim Solodovnik a écrit :
> please let me know if you need any help in testing :)
> 
> On Thu, Mar 3, 2016 at 10:07 PM, <herve.bout...@free.fr> wrote:
> > 18-SNAPSHOT is ready
> > 
> > but there are a few feedbacks on edge case issues: I'm torn if we should
> > release now or wait for 3.5.1
> > 
> > Regards,
> > 
> > Hervé
> > 
> > - Mail original -
> > De: "Maxim Solodovnik" <solomax...@gmail.com>
> > À: "Maven Users List" <users@maven.apache.org>
> > Envoyé: Jeudi 3 Mars 2016 09:54:10
> > Objet: Re: maven-site-plugin 3.5 ClassNotFoundException
> > 
> > Is it time to release apache parent 18? :)
> > 
> > WBR, Maxim
> > (from mobile, sorry for the typos)
> > 
> > On Feb 27, 2016 14:04, "Maxim Solodovnik" <solomax...@gmail.com> wrote:
> > > Thanks a lot!
> > > I'll wait for the announce and then will test :)
> > > 
> > > On Thu, Feb 25, 2016 at 12:47 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > > 
> > > wrote:
> > >> Hi,
> > >> 
> > >> Not sure there is not a misunderstanding about the new dependency: it's
> > 
> > on
> > 
> > >> maven-site-plugin to override what I did on ASF v17 [1], not your
> > 
> > project
> > 
> > >> (hopefully, the build tool requirements don't affect your project
> > >> 
> > >> dependencies). That is like Velocity downgrade [2]:
> > >> 
> > >> 
> > >>   org.apache.maven.plugins
> > >>   maven-site-plugin
> > >>   
> > >>   
> > >> 
> > >> 
> > >>   org.apache.maven.doxia
> > >>   doxia-core
> > >>   1.7
> > >> 
> > >> 
> > >>   
> > >>   
> > >> 
> > >> 
> > >> 
> > >> I'm waiting for Fluido 1.5 before releasing ASF v18: yes, I'll announce
> > >> when
> > >> it is ready.
> > >> 
> > >> Regards,
> > >> 
> > >> Hervé
> > >> 
> > >> [1]
> > 
> > http://svn.apache.org/viewvc/maven/pom/tags/apache-17/pom.xml?view=markup#
> > l234> 
> > >> [2] http://maven.apache.org/plugins/maven-site-plugin/migrate.html
> > >> 
> > >> Le mercredi 24 février 2016 13:47:25 Maxim Solodovnik a écrit :
> > >> > Hello Hervé,
> > >> > 
> > >> > Thanks for the quick answer
> > >> > I'll wait for apache parent #18, don't want to add additional
> > 
> > dependency
> > 
> > >> > Are you going to announce #18?
> > >> > 
> > >> > 
> > >> > On Wed, Feb 24, 2016 at 12:58 PM, Hervé BOUTEMY <
> > 
> > herve.bout...@free.fr>
> > 
> > >> > wrote:
> > >> > > Hi Maxim,
> > >> > > 
> > >> > > That's typical of a forced dependency to doxia-core version 1.6 or
> > >> 
> > >> less
> > >> 
> > >> > > (which
> > >> > > is typical from a project inheriting from an ASF version 17 parent
> > 
> > POM
> > 
> > >> > > because
> > >> > > of MPOM-69 fix).
> > >> > > 
> > >> > > I'm still waiting for a little more feedback before releasing ASF
> > >> 
> > >> parent
> > >> 
> > >> > > POM
> > >> > > version 18 with maven-site-plugin 3.5 (and no Doxia core version
> > >> 
> > >> forcing).
> > >> 
> > >> > > Now, you should simply add a dependency to maven-site-plugin 3.5 to
> > >> > > doxia-core
> > >> > > version 1.7 and everything will work as expected.
> > >> > > 
> > >> > > Regards,
> > >> > > 
> > >> > > Hervé
> > >> > > 
> > >> > > Le mercredi 24 février 2016 11:21:

Re: New maven site and doxia with custom velocity doxia

[Hervé BOUTEMY]

Hi,

The code to populate Velocity tools was completely rewritten in 
https://issues.apache.org/jira/browse/DOXIASITETOOLS-93

Previously, it was using default Velocity mechanisms, that were not giving 
consistent results with request-scoped tools.
It was then rewritten to have working request-scoped attributes: but maybe we 
didn't integrate some Velocity mechanisms for extensions.

Please open an issue and if you know how Velocity tools extensions are 
inserted, don't hesitate to provide a fix :)

(and sorry, Doxia Sitetools 1.7.1 is already out and maven-site-plugin 3.5.1 
is under vote: the fix will be released later...)

Regards,

Hervé

Le mardi 12 avril 2016 18:38:21 Eric Barboni a écrit :
> Hi,
> 
>   I had a web site with custom template using custom velocity tools. Using
> an approach equivalent to (reflow-velocity-tools [1]). After using the new
> maven site (3.5) and maven doxia (1.7) the tools is no more detected.
> 
> 
> 
> Is there a workaround or is this option gone.
> 
> 
> 
> [1] https://github.com/andriusvelykis/reflow-maven-skin
> 
> 
> 
> Best Regards
> 
> Eric


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

[ANN] Apache Maven Doxia Sitetools 1.7.1 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Doxia Sitetools, version 1.7.1
 
Doxia Sitetools is an extension of base Doxia component that generates either 
HTML sites, consisting of decoration and content that was generated by Doxia, 
or documents like RTF or PDF.
 
http://maven.apache.org/doxia/doxia-sitetools/
 
You can download the appropriate sources etc. from the download page:
 
http://maven.apache.org/doxia/doxia-sitetools/download.cgi


Release Notes - Maven Doxia Sitetools - Version 1.7.1

** Bug
* [DOXIASITETOOLS-164] - don't use document date from Sink API as creation 
date but as "date" without precision on created or last modified

** Improvement
* [DOXIASITETOOLS-157] - Add support for Velocity #parse and #include with 
relative paths
* [DOXIASITETOOLS-160] - Normalize line endings in skin template content 
on SiteRenderer side rather that Velocity side

** New Feature
* [DOXIASITETOOLS-158] - early interpolation: support ${this.*} as 
expression in site.xml interpolation

** Task
* [DOXIASITETOOLS-152] - Upgrade default skin to Default Skin 1.2
* [DOXIASITETOOLS-159] - Upgrade to Plexus Velocity 1.2
* [DOXIASITETOOLS-161] - Remove custom components.xml because it 
duplicates the default config in Plexus Velocity 1.2
* [DOXIASITETOOLS-162] - Clean up issues reported by 'dependency:analyze'
* [DOXIASITETOOLS-163] - warn if deprecated ${reports}, ${parentProject} 
or ${modules} is found

** Wish
* [DOXIASITETOOLS-144] - Split default-site.vm into 2 parts: default-
site.vm and default-site-macros.vm

 
Enjoy,
 
-The Apache Maven team

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

Re: maven-site-plugin 3.5 ClassNotFoundException

[Hervé BOUTEMY]

I knew I did cleanup in some algorithms, but I didn't expect such an 
improvement in performance: it's great to see!

Regards,

Hervé

Le jeudi 7 avril 2016 12:49:37 Maxim Solodovnik a écrit :
> Great thing I can notice: build time was reduced from *5:30 min* to *03:40*
> min !!
> great :)
> 
> On Thu, Apr 7, 2016 at 12:48 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> 
> wrote:
> > great, thanks for the feedback
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 7 avril 2016 12:45:53 Maxim Solodovnik a écrit :
> > > seems to work as expected with
> > > 
> > > 
> > > 
> > > 
> > > site was generated as expected
> > > I can see no issues with content or layout
> > > 
> > > I would say: works for me :)
> > > 
> > > On Thu, Apr 7, 2016 at 12:39 PM, Maxim Solodovnik <solomax...@gmail.com>
> > > 
> > > wrote:
> > > > I have changed
> > > > parent version to be 18-SNAPSHOT
> > > > maven-site version to be 3.5
> > > > maven-fluido-skin version to be 1.5
> > > > 
> > > > it seems my site.xml is not valid anymore the error is
> > > > 
> > > > [ERROR] Failed to execute goal
> > > > org.apache.maven.plugins:maven-site-plugin:3.5:site (generate-site) on
> > > > project openmeetings-parent: SiteToolException: Error parsing site
> > > > descriptor: TEXT must be immediately followed by END_TAG and not
> > 
> > START_TAG
> > 
> > > > (position: START_TAG seen ..."text/javascript" src="
> > > > http://openmeetings.apache.org/js/site.js;>... @40:83) -> [Help 1]
> > > > 
> > > > 
> > > > here:
> > > > 
> > > > http://openmeetings.apache.org/js/site.js&quot</a>;>
> > > > 
> > > > 
> > > > Will try to check CHANGELOG for maven-site-plugin
> > > > 
> > > > 
> > > > On Thu, Apr 7, 2016 at 12:29 PM, Maxim Solodovnik <
> > 
> > solomax...@gmail.com>
> > 
> > > > wrote:
> > > >> Thanks for letting me know
> > > >> will test right now
> > > >> 
> > > >> 
> > > >> On Thu, Apr 7, 2016 at 12:26 PM, Hervé BOUTEMY <herve.bout...@free.fr
> > > >> 
> > > >> wrote:
> > > >>> Hi Maxim,
> > > >>> 
> > > >>> I just updated 18-SNAPSHOT to use Doxia Sitetools 1.7.1, which
> > 
> > contains
> > 
> > > >>> early
> > > >>> interpolation ${this.*} feature [1]
> > > >>> 
> > > >>> It would be great to have some tests from end users before I do the
> > > >>> maven-
> > > >>> site-plugin 3.5.1 release
> > > >>> 
> > > >>> Regards,
> > > >>> 
> > > >>> Hervé
> > > >>> 
> > > >>> 
> > > >>> [1]
> > 
> > http://maven.apache.org/doxia/doxia-sitetools/doxia-integration-tools/in
> > 
> > > >>> dex.html>>>
> > > >>> 
> > > >>> Le jeudi 3 mars 2016 22:11:59 Maxim Solodovnik a écrit :
> > > >>> > please let me know if you need any help in testing :)
> > > >>> > 
> > > >>> > On Thu, Mar 3, 2016 at 10:07 PM, <herve.bout...@free.fr> wrote:
> > > >>> > > 18-SNAPSHOT is ready
> > > >>> > > 
> > > >>> > > but there are a few feedbacks on edge case issues: I'm torn if
> > > >>> > > we
> > > >>> 
> > > >>> should
> > > >>> 
> > > >>> > > release now or wait for 3.5.1
> > > >>> > > 
> > > >>> > > Regards,
> > > >>> > > 
> > > >>> > > Hervé
> > > >>> > > 
> > > >>> > > - Mail original -
> > > >>> > > De: "Maxim Solodovnik" <solomax...@gmail.com>
> > > >>> > > À: "Maven Users List" <users@maven.apache.org>
> > > >>> > > Envoyé: Jeudi 3 Mars 2016 09:54:10
> > > >>> > > Objet: Re: maven-site-plugin 3.5 ClassNotFoundException
> > > >>> > > 
> > > >>> > > Is it time to re

Re: Why did the Maven Site Plugin 3.4.1 vanished

[Hervé BOUTEMY]

Hi,

3.4.1? This version never existed
http://svn.apache.org/viewvc/maven/plugins/tags/

Didn't you look for 3.5.1?

Regards,

Hervé

Le jeudi 21 avril 2016 23:52:25 Oliver B. Fischer a écrit :
> Hi,
> 
> I just recognized that version 3.4.1 of the Maven Site Plugin vanished
> from Maven Central. Does someone how why?
> 
> Oliver


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

[ANN] Apache Software Foundation Parent POM Version 18 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the 
Apache Software Foundation Parent POM Version 18.

https://maven.apache.org/pom/asf/

You should specify the version in your project as parent like the following:


   org.apache
   apache
   18

 
Release Notes - Maven POMs - Version ASF-18

** Improvement
* [MPOM-60] - Add DEPENDENCIES file to the exclude rule for apache-rat-
plugin
* [MPOM-78] - Updated maven-assembly-plugin to 2.5.5
* [MPOM-92] - Upgrade maven-clean-plugin to 2.6.1
* [MPOM-93] - Upgrade maven-gpg-plugin to 1.6
* [MPOM-94] - Upgrade maven-war-plugin to 2.6
* [MPOM-98] - Upgrade maven-compiler-plugin version to 3.3
* [MPOM-99] - Upgrade maven-dependency-plugin to 2.10
* [MPOM-100] - Upgrade maven.compiler.source/target to 1.6
* [MPOM-101] - Use HTTPS by default for snapshot repository
* [MPOM-103] - upgrade maven-site-plugin to 3.5.1
* [MPOM-108] - Upgrade all plugins to the latest versions
* [MPOM-116] - Use https wherever possible

** Task
* [MPOM-104] - Clean up src/site-docs/site.xml for MSITE 3.5.1
* [MPOM-106] - Update maven-assembly-plugin
* [MPOM-113] - Missing execution ids
* [MPOM-114] - Missing groupId

Changes since version 17:

https://svn.apache.org/viewvc/maven/pom/tags/apache-18/pom.xml?r1=HEAD=1675930_format=h

Enjoy,
 
-The Apache Maven team

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

Re: Preferred way to submit Doxia Patches

[Hervé BOUTEMY]

No, Jira is the good way to submit patches: thanks for your help.
But in addition to Jira, having some discussion here can help: as you can see, 
your request here got the intended effect = this issue is now being discussed 
in Jira

There are many Maven components, many Jiras, on so much different topics, with 
less active people than topics, and a lot of different priorities on every 
topic: some issues are overlooked, sorry
FYI, I reviewed personnally DOXIA before doing Doxia 1.7 a few months ago, I 
picked a few I didn't followed at the time they were submitted, but I didn't 
see yours...

Notice that we also have PR on github mirror, but that won't change anything 
regarding review: if it is overlooked because it happens at a time when nobody 
is actively monitoring the precise topic you're interested into at the exact 
same time, it can stay unnoticed for a long time

Then thank you for the initial work AND for the nice "ping" when your work 
remains unnoticed

Regards,

Hervé

Le dimanche 22 mai 2016 08:42:17 James Agnew a écrit :
> Hi there,
> 
> I submitted a patch to Doxia about two years ago, and it does not appear to
> have ever been looked at: https://issues.apache.org/jira/browse/DOXIA-522
> 
> This patch makes the snippet macro infinitely more usable on sites with
> lots of snippets because it causes malformed ones to be rejected instead of
> being silently ignored.
> 
> I'm just wondering if there is a better way to submit patches to this
> project?
> 
> Cheers,
> James


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

Re: maven-site-plugin 3.5 ClassNotFoundException

[Hervé Boutemy]

Hi,

I just started a vote for Apache Source Release Assembly Descriptor version 
1.0.6, which is a prerequisite. I'll do the vote for Apache parent pom version 
18 just after.

Regards,

Hervé

Le jeudi 28 avril 2016 10:16:46 Maxim Solodovnik a écrit :
> Hello Hervé,
> 
> sorry bothering do you have any roadmap for 18-SNAPSHOT release?
> It is always better to use release versions :)
> 
> On Sat, Apr 9, 2016 at 1:46 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> > I knew I did cleanup in some algorithms, but I didn't expect such an
> > improvement in performance: it's great to see!
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 7 avril 2016 12:49:37 Maxim Solodovnik a écrit :
> > > Great thing I can notice: build time was reduced from *5:30 min* to
> > 
> > *03:40*
> > 
> > > min !!
> > > great :)
> > > 
> > > On Thu, Apr 7, 2016 at 12:48 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > > 
> > > wrote:
> > > > great, thanks for the feedback
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le jeudi 7 avril 2016 12:45:53 Maxim Solodovnik a écrit :
> > > > > seems to work as expected with
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > site was generated as expected
> > > > > I can see no issues with content or layout
> > > > > 
> > > > > I would say: works for me :)
> > > > > 
> > > > > On Thu, Apr 7, 2016 at 12:39 PM, Maxim Solodovnik <
> > 
> > solomax...@gmail.com>
> > 
> > > > > wrote:
> > > > > > I have changed
> > > > > > parent version to be 18-SNAPSHOT
> > > > > > maven-site version to be 3.5
> > > > > > maven-fluido-skin version to be 1.5
> > > > > > 
> > > > > > it seems my site.xml is not valid anymore the error is
> > > > > > 
> > > > > > [ERROR] Failed to execute goal
> > > > > > org.apache.maven.plugins:maven-site-plugin:3.5:site
> > 
> > (generate-site) on
> > 
> > > > > > project openmeetings-parent: SiteToolException: Error parsing site
> > > > > > descriptor: TEXT must be immediately followed by END_TAG and not
> > > > 
> > > > START_TAG
> > > > 
> > > > > > (position: START_TAG seen ..."text/javascript" src="
> > > > > > http://openmeetings.apache.org/js/site.js;>... @40:83) -> [Help 1]
> > > > > > 
> > > > > > 
> > > > > > here:
> > > > > > 
> > > > > > http://openmeetings.apache.org/js/site.js&quot</a>;>
> > > > > > 
> > > > > > 
> > > > > > Will try to check CHANGELOG for maven-site-plugin
> > > > > > 
> > > > > > 
> > > > > > On Thu, Apr 7, 2016 at 12:29 PM, Maxim Solodovnik <
> > > > 
> > > > solomax...@gmail.com>
> > > > 
> > > > > > wrote:
> > > > > >> Thanks for letting me know
> > > > > >> will test right now
> > > > > >> 
> > > > > >> 
> > > > > >> On Thu, Apr 7, 2016 at 12:26 PM, Hervé BOUTEMY <
> > 
> > herve.bout...@free.fr
> > 
> > > > > >> wrote:
> > > > > >>> Hi Maxim,
> > > > > >>> 
> > > > > >>> I just updated 18-SNAPSHOT to use Doxia Sitetools 1.7.1, which
> > > > 
> > > > contains
> > > > 
> > > > > >>> early
> > > > > >>> interpolation ${this.*} feature [1]
> > > > > >>> 
> > > > > >>> It would be great to have some tests from end users before I do
> > 
> > the
> > 
> > > > > >>> maven-
> > > > > >>> site-plugin 3.5.1 release
> > > > > >>> 
> > > > > >>> Regards,
> > > > > >>> 
> > > > > >>> Hervé
> > > > > >>> 
> > > > > >>> 
> > > > > >>> [1]
> > 
> > http://maven.apache.org/doxia/doxia-sitetools/doxia-i

[ANN] Apache Maven Site Plugin 3.5.1 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Site 
Plugin, version 3.5.1

The Maven Site Plugin is a plugin that generates a site for the current 
project.

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

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-site-plugin
  3.5.1


You can download the appropriate sources etc. from the download page:
 
http://maven.apache.org/plugins/maven-site-plugin/download.cgi


Release Notes - Apache Maven Site Plugin - Version 3.5.1

Bug
* [MSITE-771] FAQ Entry for difference between mvn site and mvn site:site is 
incorrect
* [MSITE-769] Can't use property in breadcrumbs items in child module site 
descriptor

Improvement
* [MSITE-768] Support Velocity's #parse and #include
* [MSITE-700] All inclusion of resources up to ${basedir} when Velocity 1.7 is 
used


Enjoy,

-The Maven team


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

Re: Is there a guide on how to use Sisu within Maven plugins?

[Hervé BOUTEMY]

notice:@Component we're using in a Mojo is from Maven Plugin Tools 
org.apache.maven.plugins.annotations.Component [1]

it's different from @Component from Plexus, which is 
org.codehaus.plexus.component.annotations.Component [2]

Using the same class name in a different package is probably a bad idea, 
because it's really confusing, sorry: perhaps we should deprecate @Component 
in Maven Plugin Tools and create an annotation with another name.
Any idea on a new name?


Then Maven Plugin Tools uses its annotations (@Mojo, @Execute, @Parameter and 
@Component in org.apache.maven.plugins.annotations) to generate META-INF/
maven/plugin.xml plugin descriptor [3] . @Component annotation is more 
precisely at the source of
  

  
  
  

  
part

Perhaps creating a @Requirement annotation in Maven Plugin Tools to replace 
@Component would reduce confusion: it would still not make a very visible 
difference between @Requirement from Maven Plugin Tools and @Requirement from 
Plexus [2]: but at least, both @Requirement annotations would have the same 
meaning

WDYT?

Regards,

Hervé


[1] http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/
index.html#Supported_Annotations

[2] 
http://codehaus-plexus.github.io/plexus-containers/plexus-component-annotations/

[3] http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html

Le mercredi 1 février 2017, 20:01:10 CET Laird Nelson a écrit :
> Thanks; yeah, I understand--maybe I don't actually--that there are certain
> Maven plugin annotations that get converted into the XML descriptor.  But
> what about line 52 and following in the link you sent:
> 
> 
>1. @Component( role = MyComponentExtension.class,
>2. hint = "..." )
>3. private MyComponent component;
> 
> 
> Shouldn't that be replaced with JSR-330?  Very confused; sorry!
> 
> Best,
> Laird
> 
> On Wed, Feb 1, 2017 at 11:59 AM Robert Scholte  wrote:
> > No, plugin annotation are used to generate a plugin descriptor, i.e.
> > META-INF/maven/plugin.xml
> > At runtime this file is used to initialize the plugin, whereas the
> > specified components are injected with sisu/guice
> > 
> > Robert
> > 
> > On Wed, 01 Feb 2017 20:52:19 +0100, Laird Nelson 
> > 
> > wrote:
> > > Thanks.  But isn't _that_, in turn, replaced by JSR-330?  This is what
> > > I'm
> > > confused about.
> > > 
> > > On Wed, Feb 1, 2017 at 11:26 AM Robert Scholte 
> > > 
> > > wrote:
> > >> This is what is used nowadays:
> > https://maven.apache.org/components/plugin-tools/maven-plugin-tools-annota
> > tions/index.html> 
> > >> Robert
> > >> 
> > >> On Wed, 01 Feb 2017 19:21:09 +0100, Laird Nelson 
> > >> 
> > >> wrote:
> > >> > I apologize in advance for the inarticulate nature of this question.
> > >> > 
> > >> > I have this faint sense that Sisu and Guice are at the core of Maven
> > >> > these
> > >> > days, with a Plexus layer on top.
> > >> > 
> > >> > This makes me think that perhaps I should be using different
> > >> 
> > >> annotations
> > >> 
> > >> > in
> > >> > my maven plugins than @Component etc.
> > >> > 
> > >> > Is this (
> > 
> > https://maven.apache.org/guides/plugin/guide-java-plugin-development.html)
> > 
> > >> > still the official guide for writing Maven plugins?  If I wanted to
> > >> > inject
> > >> > some named Plexus component, is there some guide showing how to do
> > >> 
> > >> that?
> > >> 
> > >> > Thanks,
> > >> > Best,
> > >> > Laird
> > >> 
> > >> -
> > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > >> For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Generating xdoc content to be included into site

[Hervé BOUTEMY]

you're the first one I see who does that: I never imagined to support this 
scenario

Then I'd say: it's by design :)

I don't know if adding this feature would be hard or not

Regards,

Hervé

Le jeudi 2 février 2017, 01:02:33 CET Maxim Solodovnik a écrit :
> One additional question,
> 
> I'm generating site.xml during pre-site phase and storing it into
> target/generated-site/site.xml
> But it seems to be not used
> Is it by design? Or maybe I'm doing something wrong?
> 
> On Wed, Feb 1, 2017 at 8:16 PM, Maxim Solodovnik  
wrote:
> > Thanks a lot!
> > Works as expected!
> > 
> > On Wed, Feb 1, 2017 at 7:03 PM, Lukas Theussl  wrote:
> >> Heya,
> >> 
> >> Try ${project.build.directory}/generated-site or change the
> >> generatedSiteDirectory parameter, see
> >> 
> >> https://maven.apache.org/plugins/maven-site-plugin/site-mojo.html#generat
> >> edSiteDirectory
> >> 
> >> HTH,
> >> -Lukas
> >> 
> >> Am 01.02.2017 um 11:49 schrieb Maxim Solodovnik:
> >>> Hello Karl,
> >>> 
> >>> Thanks a lot for the quick response
> >>> pre-site phase is being called if I'm using "mvn site"
> >>> but XML files from target/generated-sources/site/xdoc/ are not being
> >>> used while site generation ...
> >>> Should it be generated to the different folder?
> >>> 
> >>> On Wed, Feb 1, 2017 at 3:52 PM, Karl Heinz Marbaise 
> >>> 
> >>> wrote:
>  Hi,
>  
>  On 01/02/17 06:52, Maxim Solodovnik wrote:
> > Hello All,
> > 
> > I wonder is it possible to generate content for maven site plugin?
> > We are using xdoc for our site. I would like to generate source using
> > xml-maven-plugin.
> > 
> > Right now I do it in generate-sources phase and polluting
> > src/site/xdoc/
> > folder
> > I tried to change the process as follows:
> > 1) generate site source in pre-site phase
> > 2) put generated content into
> > ${project.build.directory}/generated-sources/site/xdoc/
> > 
> > unfortunately it doesn't work this way :(
> > It seems pre-site phase is not being called during mvn site:site :(
> > What am I doing wrong?
>  
>  If you call site:site you call the goal of the plugin and NOT the life
>  cycle. You need to call mvn site instead than pre-site and site life
>  cycle
>  phases will run...
>  
>  
>  Kind regards
>  Karl Heinz Marbaise
>  
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> >> 
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > --
> > WBR
> > Maxim aka solomax



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

Re: Is there a guide on how to use Sisu within Maven plugins?

[Hervé BOUTEMY]

Le vendredi 3 février 2017, 10:43:42 CET Robert Scholte a écrit :
> What I expect to happen is that Plexus Component Annotations will be fully
> replaced with JSR330 annotations.
> In that case there will be only 1 @Component annotation, i.e.
> org.apache.maven.plugins.annotations.Component, which is fine by me.
We should document that

Notice that plexus @Component is not equivalent to @Inject: Plexus 
@Requirement is equivalent to @Inject

And for Maven Plugin Tools, since it is used to generate plugin.xml, having an 
annotation that matches the XML fragment will help.

The more I think at it, the more I think Maven Plugin Tools should promote 
@Requirement (and we don't care that it is the same name as the @Requirement 
from Plexus, that means @Inject with JSR330)

> Also, I expect the community to be more familiar with the maven plugin
> annotations than with plexus annotations.
I documented how to switch from Plexus javadoc to Plexus annotations: is there 
some doc on switching from Plexus annotations to JSR330?

> Keep in mind that the original question is actually: can I
> override/redefine the default implementation for a 'service'?
that's not this email thread: I suppose you're referring to an other 
discussion

Regards,

Hervé

> The
> discussion about the annotations caused extra confusion but in the end had
> nothing to do with the issue.
> 
> thanks,
> Robert
> 
> On Fri, 03 Feb 2017 10:15:05 +0100, Hervé BOUTEMY <herve.bout...@free.fr>
> 
> wrote:
> > notice:@Component we're using in a Mojo is from Maven Plugin Tools
> > org.apache.maven.plugins.annotations.Component [1]
> > 
> > it's different from @Component from Plexus, which is
> > org.codehaus.plexus.component.annotations.Component [2]
> > 
> > Using the same class name in a different package is probably a bad idea,
> > because it's really confusing, sorry: perhaps we should deprecate
> > @Component
> > in Maven Plugin Tools and create an annotation with another name.
> > Any idea on a new name?
> > 
> > 
> > Then Maven Plugin Tools uses its annotations (@Mojo, @Execute,
> > @Parameter and
> > @Component in org.apache.maven.plugins.annotations) to generate META-INF/
> > maven/plugin.xml plugin descriptor [3] . @Component annotation is more
> > precisely at the source of
> > 
> >   
> >   
> > 
> > 
> >   
> >   
> >   
> > 
> > 
> >   
> >   
> > 
> > part
> > 
> > Perhaps creating a @Requirement annotation in Maven Plugin Tools to
> > replace
> > @Component would reduce confusion: it would still not make a very visible
> > difference between @Requirement from Maven Plugin Tools and @Requirement
> > from
> > Plexus [2]: but at least, both @Requirement annotations would have the
> > same
> > meaning
> > 
> > WDYT?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > 
> > [1] http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/
> > index.html#Supported_Annotations
> > 
> > [2]
> > http://codehaus-plexus.github.io/plexus-containers/plexus-component-annota
> > tions/
> > 
> > [3] http://maven.apache.org/ref/3-LATEST/maven-plugin-api/plugin.html
> > 
> > Le mercredi 1 février 2017, 20:01:10 CET Laird Nelson a écrit :
> >> Thanks; yeah, I understand--maybe I don't actually--that there are
> >> certain
> >> Maven plugin annotations that get converted into the XML descriptor.
> >> But
> >> 
> >> what about line 52 and following in the link you sent:
> >>1. @Component( role = MyComponentExtension.class,
> >>2. hint = "..." )
> >>3. private MyComponent component;
> >> 
> >> Shouldn't that be replaced with JSR-330?  Very confused; sorry!
> >> 
> >> Best,
> >> Laird
> >> 
> >> On Wed, Feb 1, 2017 at 11:59 AM Robert Scholte <rfscho...@apache.org>
> >> 
> >> wrote:
> >> > No, plugin annotation are used to generate a plugin descriptor, i.e.
> >> > META-INF/maven/plugin.xml
> >> > At runtime this file is used to initialize the plugin, whereas the
> >> > specified components are injected with sisu/guice
> >> > 
> >> > Robert
> >> > 
> >> > On Wed, 01 Feb 2017 20:52:19 +0100, Laird Nelson <ljnel...@gmail.com>
> >> > 
> >> > wrote:
> >> > > Thanks.  But isn't _that_, in turn, replaced by JSR-330?  This is
> >> 

Re: Generating xdoc content to be included into site

[Hervé BOUTEMY]

in all the cases I know of , since there is site.xml inheritance for shared 
parts, site.xml for modules are not necessary.

Can you share the "standard" site.xml?

Regards,

Hervé

Le vendredi 3 février 2017, 16:31:14 CET Maxim Solodovnik a écrit :
> Actually I have multi-module project
> I have "main site" with some how-tos, announces etc.
> and "standard" sites for all sub-modules: info, rat-report, javadocs,
> dependencies etc.
> Currently I have exactly the same site.xml for all these "standard" sites,
> and I don't really like to have 7 copies of the same file :(
> 
> On Fri, Feb 3, 2017 at 4:20 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> > you're the first one I see who does that: I never imagined to support this
> > scenario
> > 
> > Then I'd say: it's by design :)
> > 
> > I don't know if adding this feature would be hard or not
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 2 février 2017, 01:02:33 CET Maxim Solodovnik a écrit :
> > > One additional question,
> > > 
> > > I'm generating site.xml during pre-site phase and storing it into
> > > target/generated-site/site.xml
> > > But it seems to be not used
> > > Is it by design? Or maybe I'm doing something wrong?
> > > 
> > > On Wed, Feb 1, 2017 at 8:16 PM, Maxim Solodovnik <solomax...@gmail.com>
> > 
> > wrote:
> > > > Thanks a lot!
> > > > Works as expected!
> > > > 
> > > > On Wed, Feb 1, 2017 at 7:03 PM, Lukas Theussl <ltheu...@gmail.com>
> > 
> > wrote:
> > > >> Heya,
> > > >> 
> > > >> Try ${project.build.directory}/generated-site or change the
> > > >> generatedSiteDirectory parameter, see
> > > >> 
> > > >> https://maven.apache.org/plugins/maven-site-plugin/
> > 
> > site-mojo.html#generat
> > 
> > > >> edSiteDirectory
> > > >> 
> > > >> HTH,
> > > >> -Lukas
> > > >> 
> > > >> Am 01.02.2017 um 11:49 schrieb Maxim Solodovnik:
> > > >>> Hello Karl,
> > > >>> 
> > > >>> Thanks a lot for the quick response
> > > >>> pre-site phase is being called if I'm using "mvn site"
> > > >>> but XML files from target/generated-sources/site/xdoc/ are not being
> > > >>> used while site generation ...
> > > >>> Should it be generated to the different folder?
> > > >>> 
> > > >>> On Wed, Feb 1, 2017 at 3:52 PM, Karl Heinz Marbaise <
> > 
> > khmarba...@gmx.de>
> > 
> > > >>> wrote:
> > > >>>> Hi,
> > > >>>> 
> > > >>>> On 01/02/17 06:52, Maxim Solodovnik wrote:
> > > >>>>> Hello All,
> > > >>>>> 
> > > >>>>> I wonder is it possible to generate content for maven site plugin?
> > > >>>>> We are using xdoc for our site. I would like to generate source
> > 
> > using
> > 
> > > >>>>> xml-maven-plugin.
> > > >>>>> 
> > > >>>>> Right now I do it in generate-sources phase and polluting
> > > >>>>> src/site/xdoc/
> > > >>>>> folder
> > > >>>>> I tried to change the process as follows:
> > > >>>>> 1) generate site source in pre-site phase
> > > >>>>> 2) put generated content into
> > > >>>>> ${project.build.directory}/generated-sources/site/xdoc/
> > > >>>>> 
> > > >>>>> unfortunately it doesn't work this way :(
> > > >>>>> It seems pre-site phase is not being called during mvn site:site
> > > >>>>> :(
> > > >>>>> What am I doing wrong?
> > > >>>> 
> > > >>>> If you call site:site you call the goal of the plugin and NOT the
> > 
> > life
> > 
> > > >>>> cycle. You need to call mvn site instead than pre-site and site
> > > >>>> life
> > > >>>> cycle
> > > >>>> phases will run...
> > > >>>> 
> > > >>>> 
> > > >>>> Kind regards
> > > >>>> Karl Heinz Marbaise
> > > >>>> 
> > > >>>> 
> > 
> > -
> > 
> > > >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > >>>> For additional commands, e-mail: users-h...@maven.apache.org
> > > >> 
> > > >> -
> > > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > >> For additional commands, e-mail: users-h...@maven.apache.org
> > > > 
> > > > --
> > > > WBR
> > > > Maxim aka solomax
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Finding another plugins configuration

[Hervé BOUTEMY]

b) is probably possible, but not recommended

When we want to share some configuration between plugins, the usual solution is 
to define a convention on a property name: see for example maven.test.skip that 
is supported both by maven-compiler-plugin [1], Surefire [2], nar-maven-plugin 
in multiple goals [3] [4] [5]

Regards,

Hervé

[1] 
http://maven.apache.org/plugins/maven-compiler-plugin/testCompile-mojo.html#skip

[2] http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skip

[3] http://maven-nar.github.io/nar-test-mojo.html#skipTests

[4] http://maven-nar.github.io/nar-test-unpack-mojo.html#skipTests

[5] http://maven-nar.github.io/nar-testCompile-mojo.html#skipTests

Le lundi 30 janvier 2017, 19:18:50 CET Jochen Wiedmann a écrit :
> Hi,
> 
> I'd like to create a plugin, which is intended to generate resources
> for a web application.
> 
> In other words, the target directory would be the value, which is
> typically configured as the webappDirectory property of the
> maven-war-plugin.
> 
> To get that value, I see two options:
> 
> a) I create a property webappDirectory in my own plugin, and force the
> user to configure that property.
> 
> b) I find the projects maven-war-plugin, and read that objects value.
> 
> Is b) possible? How?
> 
> Thanks,
> 
> Jochen



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

Re: Generating xdoc content to be included into site

[Hervé BOUTEMY]

Hi Maxim,

Sorry, was in vacations and lost the conversation... but let's continue

First, you gave great links to source code: do you have a published result 
somewhere? (= a demo of the result you want, even if currently the code to 
have such result is too complex and you're looking to make it simpler)

As first reaction from what I see in https://github.com/apache/openmeetings/
blob/3.2.x/openmeetings-util/src/site/site.xml, instead of:
  
you should use
  

see http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/
decoration.html#class_menu for reference documentation


Maven has a bunch of such multi-module component sites:
- Maven core:
  result = http://maven.apache.org/ref/3-LATEST/
  source = https://github.com/apache/maven

- Doxia Sitetools (which is a key component of maven-site-plugin to do the 
site menus...):
  result = http://maven.apache.org/doxia/doxia-sitetools/
  source = https://github.com/apache/maven-doxia-sitetools

I'm struggling for years to make easy doc do describe clearly relationship 
between maven-site-plugin, Doxia and Doxia Sitetools: any feedback on how to 
improve our documentation is welcome

Regards,

Hervé

Le lundi 6 février 2017, 10:20:55 CET Maxim Solodovnik a écrit :
> Hello Hervé,
> 
> Thanks for the quick reply,
> 
> Few words about project structure:
> project root: https://github.com/apache/openmeetings/tree/3.2.x
> 
> main site.xml
> https://github.com/apache/openmeetings/blob/3.2.x/src/site/site.xml
> contains skin definitions and links being displayed by all modules
> 
> "standard" site.xml
> https://github.com/apache/openmeetings/blob/3.2.x/openmeetings-util/src/site
> /site.xml
> 
> one of the modules:
> https://github.com/apache/openmeetings/tree/3.2.x/openmeetings-server
> performing final assembly, and contains main site with all xdocs etc.:
> https://github.com/apache/openmeetings/blob/3.2.x/openmeetings-server/src/si
> te/site.xml
> 
> I'm not advanced maven user and still learning, so would appreciate any
> suggestions :)
> 
> On Fri, Feb 3, 2017 at 6:41 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> > in all the cases I know of , since there is site.xml inheritance for
> > shared
> > parts, site.xml for modules are not necessary.
> > 
> > Can you share the "standard" site.xml?
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 3 février 2017, 16:31:14 CET Maxim Solodovnik a écrit :
> > > Actually I have multi-module project
> > > I have "main site" with some how-tos, announces etc.
> > > and "standard" sites for all sub-modules: info, rat-report, javadocs,
> > > dependencies etc.
> > > Currently I have exactly the same site.xml for all these "standard"
> > 
> > sites,
> > 
> > > and I don't really like to have 7 copies of the same file :(
> > > 
> > > On Fri, Feb 3, 2017 at 4:20 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > 
> > wrote:
> > > > you're the first one I see who does that: I never imagined to support
> > 
> > this
> > 
> > > > scenario
> > > > 
> > > > Then I'd say: it's by design :)
> > > > 
> > > > I don't know if adding this feature would be hard or not
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le jeudi 2 février 2017, 01:02:33 CET Maxim Solodovnik a écrit :
> > > > > One additional question,
> > > > > 
> > > > > I'm generating site.xml during pre-site phase and storing it into
> > > > > target/generated-site/site.xml
> > > > > But it seems to be not used
> > > > > Is it by design? Or maybe I'm doing something wrong?
> > > > > 
> > > > > On Wed, Feb 1, 2017 at 8:16 PM, Maxim Solodovnik <
> > 
> > solomax...@gmail.com>
> > 
> > > > wrote:
> > > > > > Thanks a lot!
> > > > > > Works as expected!
> > > > > > 
> > > > > > On Wed, Feb 1, 2017 at 7:03 PM, Lukas Theussl <ltheu...@gmail.com>
> > > > 
> > > > wrote:
> > > > > >> Heya,
> > > > > >> 
> > > > > >> Try ${project.build.directory}/generated-site or change the
> > > > > >> generatedSiteDirectory parameter, see
> > > > > >> 
> > > > > >> https://maven.apache.org/plugins/maven-site-plugin/
> > > > 
> > > > site-mojo.html#generat
> > > > 
> > 

Re: Single-page sites?

[Hervé BOUTEMY]

Hi,

No, this is not a current option of maven-site-plugin.

Pdf plugin does such equivalent one doc from every report.

but writing such a plugin for one unique html page is not an easy tasks: in 
addition to the whole reporting integration work, you'll need to work on 
inter-document links in this unique html file.

Regards,

Hervé

Le lundi 27 février 2017, 18:50:01 CET org.apache.maven.u...@io7m.com a 
écrit :
> Hello.
> 
> I realize this may be a long shot: Is there any way to get the site
> plugin to produce one large HTML file instead of one file per report?
> 
> If not, does anyone happen to know how much work would be involved in
> perhaps writing an alternative site plugin that can do this?
> 
> M



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

Re: [EXTERNAL] Re: help with version range

[Hervé BOUTEMY]

Le vendredi 23 septembre 2016 18:46:36 Manfred Moser a écrit :
> Fair enough. From the purely engineering/mathematical point of view it might
> not make sense. But I dont see a way to get that changed with breaking a
> TON of other stuff.
+1

> And I am not even sure if it would be more intuitive
> instead of just being different.
+1

> 
> Manfred
> 
> Robert Patrick wrote on 2016-09-23 09:38:
> > No, you are making an invalid assumption about what I understand!  I
> > completely understand the relationship of SNAPSHOTs and other pre-release
> > artifacts and released versions.
> > 
> > What I am questioning is the "engineer's approach" to version range
> > resolution without a valid use case for why Maven should consider
> > pre-released versions as within the "not including 2.0" version range
> > semantics.
> > 
> > 
> > -Original Message-
> > From: Manfred Moser [mailto:manf...@simpligility.com]
> > Sent: Friday, September 23, 2016 11:32 AM
> > To: users@maven.apache.org
> > Subject: Re: [EXTERNAL] Re: help with version range
> > 
> > What you are misunderstanding is how snapshots are meant to be used.
> > 2.0-SNAPSHOT means that it is a development version working towards the
> > release of 2.0 and as such the version 2.0-SNAPSHOT is smaller than 2.0.
> > 
> > If you mislike this you can change how you work with your own projects at
> > least. .. you can just call your snapshot version 1.99-SNAPSHOT or
> > whatever
> > while developing and at releas time switch to 2.0 ..
> > 
> > Manfred
> > 
> > Robert Patrick wrote on 2016-09-23 08:56:
> >> This does seem non-intuitive.If I say that I want versions  between
> >> 1.0
> >> and
> >> up to but NOT including 2.0 by saying [1.0,2.0), in what use case
> >> would I ever want this to resolve to 2.0-SNAPSHOT or any other
> >> pre-release 2.0 artifact?
> >> Personally, I cannot think of a single one.
> >> 
> >> Typically, what I mean when I say [1.0,2.0) is any 1.x version but
> >> nothing related to 2.0...
> >> 
> >> -Original Message-
> >> From: Justin Georgeson [mailto:jgeorge...@lgc.com]
> >> Sent: Friday, September 23, 2016 10:11 AM
> >> To: Maven Users List
> >> Subject: RE: [EXTERNAL] Re: help with version range
> >> 
> >> Yeah, I was hoping there was something more elegant like 1.1+ or
> >> something, so I can at least move forward with that.
> >> 
> >> Logically, does it make sense to resolve 1.2.0-alpha-1 when the user
> >> has excluded 1.2.0 from their range? If I explicitly don't want the
> >> release version why would I want the pre-release versions?
> >> 
> >> -Original Message-
> >> From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On
> >> Behalf Of Curtis Rueden
> >> Sent: Friday, September 23, 2016 9:01 AM
> >> To: Maven Users List
> >> Subject: [EXTERNAL] Re: help with version range
> >> 
> >> Hi Justin,
> >> 
> >> You could write "[1.1.0,1.1.9]", no? A bit hacky, but would match
> >> the versions you want in practice.
> >> 
> >> Regards,
> >> Curtis
> >> 
> >> On Sep 23, 2016 8:38 AM, "Justin Georgeson"  wrote:
> >>> I’m using the parent version range feature with “[1.1.0,1.2.0)” and
> >>> it had been going well. However I wanted to start working on 1.2.0 of
> >>> the parent, so I published a 1.2.0-alpha-1 version. And all the
> >>> projects with te “[1.1.0,1.2.0)” picked it up. I recognize that this
> >>> is in keeping with the implementation that x.y.z-(alpha|beta|…)
> >>> precedes x.y.z, but it is unintuitive to me. First in that I’ve
> >>> stated I don’t want 1.2.0, and second that once I do release 1.2.0
> >>> the projects which were receiving the alpha builds will not get
> >>> 1.2.0. I tried with both
> >>> 3.2.5 and 3.3.9. Can the version range syntax express the range I want?
> >>> 
> >>> 
> >>> 
> >>> *Justin Georgeson*
> >>> Landmark Cloud Platforms & DevOps - RM
> >>> 
> >>> Email: *jgeorge...@lgc.com* 
> >>> 
> >>> Follow Halliburton: *LinkedIn*
> >>>  >>> s
> >>> t.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatur
> >>> e
> >>> s-255d-26url-3Dhttp-3A__www.linkedin.com_company_halliburton=DQIFaQ
> >>> &
> >>> c=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_O
> >>> V
> >>> ZL1uyui4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8
> >>> = 9g208ksOttPVrCNlOx459-qzk0wWAei89_zhZnej5vM= >
> >>> 
> >>> | *Facebook*
> >>> 
> >>>  >>> o
> >>> st.net_gopc.url-3Fxts-3D553058-26xtor-3DEPR-2D25-2D-255bHAL-2Dsignatu
> >>> r
> >>> es-255d-26url-3Dhttps-3A__www.facebook.com_halliburton=DQIFaQ=Psk
> >>> v
> >>> ixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBhAqFnkH7uKz_OVZL1uy
> >>> u
> >>> i4QoEmBCjCmEiTk=y4-iycjs7jCDUAa82A-SQP4DqefDDZjCpFKXFWCrmu8=NgT-w
> >>> O jrb7gpKDJVcRDMmKUQqGfR-PSnXe3I98Lp1c4= >
> >>> 
> >>> | *Twitter*
> >>> 
> >>> 

Re: [EXTERNAL] Re: help with version range

[Hervé BOUTEMY]

I worked a lot on this in the past, and the range I found the easiest to write 
is:
[1.0,2.0-a-a)

= "alpha-alpha" trick

yes, this is still a trick, but at least this better shows the intent

Regards,

Hervé

Le vendredi 23 septembre 2016 13:41:37 Robert Patrick a écrit :
> Well...like I said, I understand the relationship but clearly, most people
> that use version ranges that use a non-inclusive top-end specification do
> not want prerelease versions included.  I have yet to hear you or anyone
> else give me a use case where you want this.
> 
> The fact that I have to fight Maven to achieve this is a pain--and I have
> been using Maven for many years now.  There should be a simple way to
> achieve this that does not require me to do something like this:
> 
> [1.0,1.9
> 99)
> 
> 
> -Original Message-
> From: Karl Heinz Marbaise [mailto:khmarba...@gmx.de]
> Sent: Friday, September 23, 2016 3:30 PM
> To: Maven Users List
> Subject: Re: [EXTERNAL] Re: help with version range
> 
> Hi,
> 
> On 23/09/16 18:38, Robert Patrick wrote:
> > What I am questioning is the "engineer's approach" to version range
> > resolution without
> > 
>  > a valid use case for why Maven should consider  > pre-released versions
>  > as within the "not including 2.0" version  > range semantics.
> The simple answer to this is the timeline of those releases...
> So a pre-release (2.0-alpha-1, 2.0-RC1 etc.) will be done before the final
> release (2.0) so must be defined as before...
> 
> Kind regards
> Karl Heinz Marbaise
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

Re: Inconsistent documentation

[Hervé BOUTEMY]

you're right: the mini guide explains Archetype 1.x, which had its descriptor 
as archetype.xml
But Archetype is now Archetype 2, with archetype-metadata.xml descriptor

If you can create a MNGSITE issue and attach a patch for 
http://svn.apache.org/repos/asf/maven/site/trunk/content/apt/guides/mini/guide-creating-archetypes.apt
 , I'll review and apply it

Regards,

Hervé

Le vendredi 23 septembre 2016 22:09:54 Markenson França a écrit :
> This page uses archetype.xml file as example:
> 
> https://maven.apache.org/guides/mini/guide-creating-archetypes.html
> 
> 
> These pages describe archetype-metadata.xml as specification:
> 
> https://maven.apache.org/archetype/maven-archetype-plugin/specification/arch
> etype-metadata.html
> 
> https://maven.apache.org/archetype/archetype-models/archetype-descriptor/arc
> hetype-descriptor.html
> 
> 
> The first one is causing confusion because it induces user start trying
> archetypes with  tags instead 
> 
> 
> Am I wrong about this? If no, who can correct this?Regards,
> Markenson


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

Re: Inconsistent documentation

[Hervé BOUTEMY]

page updated with a notice and a link to Jira issue

Regards,

Hervé

Le samedi 24 septembre 2016 23:40:41 Hervé BOUTEMY a écrit :
> you're right: the mini guide explains Archetype 1.x, which had its
> descriptor as archetype.xml
> But Archetype is now Archetype 2, with archetype-metadata.xml descriptor
> 
> If you can create a MNGSITE issue and attach a patch for
> http://svn.apache.org/repos/asf/maven/site/trunk/content/apt/guides/mini/gui
> de-creating-archetypes.apt , I'll review and apply it
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 23 septembre 2016 22:09:54 Markenson França a écrit :
> > This page uses archetype.xml file as example:
> > 
> > https://maven.apache.org/guides/mini/guide-creating-archetypes.html
> > 
> > 
> > These pages describe archetype-metadata.xml as specification:
> > 
> > https://maven.apache.org/archetype/maven-archetype-plugin/specification/ar
> > ch etype-metadata.html
> > 
> > https://maven.apache.org/archetype/archetype-models/archetype-descriptor/a
> > rc hetype-descriptor.html
> > 
> > 
> > The first one is causing confusion because it induces user start trying
> > archetypes with  tags instead 
> > 
> > 
> > Am I wrong about this? If no, who can correct this?Regards,
> > Markenson
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org


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

[ANN] Apache Maven Site Plugin 3.6 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Site Plugin, version 3.6
 
The Site Plugin is used to generate a site for the project. The generated site 
also includes the project's reports that were configured in the POM.

https://maven.apache.org/plugins/maven-site-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-site-plugin
  3.6


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-site-plugin/download.cgi

Release Notes - Maven Site Plugin - Version 3.6

** Bug
* [MSITE-654] - Appending a slash to the repository URL makes deploying to 
GitHub impossible
* [MSITE-782] - Support for custom Velocity tools has disappeared
* [MSITE-783] - Bad modules links when 'distributionManagement.site.url' 
comes from settings.xml
* [MSITE-786] - Migrating from 3.4 to 3.5.1, a mvn site run now ask me for  
'META-INF/maven/site.vm'

** Improvement
* [MSITE-775] - add info output to site:attach-descriptor
* [MSITE-776] - Upgrade maven-shared-components parent to version 30
* [MSITE-777] - Upgrade of 'plexus-archiver' to version 3.3.
* [MSITE-778] - Upgrade maven-archiver to 3.1.0
* [MSITE-784] - upgrade maven-reporting-exec
* [MSITE-785] - Documentation of saveProcessedContent parameter is empty

** New Feature
* [MSITE-779] - add color to report generation messages

** Task
* [MSITE-780] - Upgrade of plexus-archiver to 3.4.
* [MSITE-781] - Upgrade of maven-archiver to 3.1.1.

** Wish
* [MSITE-705] - Too much information in maven logs during site:deploy in 
sftp...
 
Enjoy,

-The Apache Maven team

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

Re: ${project.parent.parent.version} does not work

[Hervé BOUTEMY]

I confirm that it is not expected to work currently: here is the reference 
documentation for pom interpolation:
http://maven.apache.org/ref/3-LATEST/maven-model-builder/
index.html#Model_Interpolation

there is not parent element in parent

Was it expected to work with Maven 2, before the whole effective pom 
calculation was rewritten?
Did you try?

Regards,

Hervé

Le vendredi 2 décembre 2016, 11:31:31 CET Florian Schätz a écrit :
> Hello,
> 
> for a project I would like to resolve the "grandparent" version:
> 
> ${project.parent.parent.version}
> 
> Unfortunately, with Maven 3.3.9 this simply doesn't work, the effective
> pom shows it as unresolved:
> 
> ${project.parent.parent.version}
> 
> I can reproduce it with any new probject a simple way is, for example,
> using a spring boot project (which should have a parent
> (spring-boot-parent) and a grandparent (spring-boot-dependencies):
> 
> 
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;>
>   4.0.0
> 
>   com.example
>   demo
>   0.0.1-SNAPSHOT
>   jar
> 
>   
>   org.springframework.boot
>   spring-boot-starter-parent
>   1.4.2.RELEASE
>
>   
> 
>   
>   
> UTF-8
> 
> UTF-8
>   1.8
> 
> ${project.parent.parent.version}
> 
>   
> 
> 
> Any ideas how to access the parent.parent.version otherwise?
> Unfortunately, I only found closed issues where
> ${project.parent.parent.version} was given as a workaround...
> 



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

Re: Maven Indexer questions

[Hervé BOUTEMY]

Le mercredi 29 mars 2017, 16:31:10 CEST Laird Nelson a écrit :
> I am working with the maven-indexer componentry for the first time; please
> forgive my ignorance.
> 
> I normally wouldn't ask these questions here, but there is no documentation.
did you have a look at:
http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexer-core/index.html
?

I'm not a Lucene expert at all, and can't really give you better info, 
sorry...

Regards,

Hervé

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

Re: Maven Indexer questions

[Hervé BOUTEMY]

there is the documentation for component reference documentation publication:
http://maven.apache.org/developers/website/deploy-component-reference-documentation.html

but nothing for end-users: the developer doc is not easy to understand, but I 
managed to write one. For end-users, I don't know how to write it to have a 
chance someone will use it...

Regards,

Hervé

Le jeudi 30 mars 2017, 16:57:51 CEST Laird Nelson a écrit :
> On Thu, Mar 30, 2017 at 9:44 AM Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> > Le mercredi 29 mars 2017, 16:31:10 CEST Laird Nelson a écrit :
> > > I normally wouldn't ask these questions here, but there is no
> > 
> > documentation.
> > did you have a look at:
> > http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/
> > 
> > http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/indexe
> > r-core/index.html ?
> 
> No!  I was looking at http://maven.apache.org/maven-indexer/.
> 
> I've seen this pattern on the website before: sometimes there's something
> under foo-bar, and other times it's under
> foo-bar-archives/foo-bar-VERSION.  Is there a cheat sheet on when to look
> where?
> 
> Thanks for the pointers,
> Best,
> Laird



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

Re: Any way to change the color scheme in Maven 3.5.0?

[Hervé BOUTEMY]

there is no feature now to dump effective config as text: didn't think at this 
scenario

PRs welcome or at least ideas on where to add this feature to make it usable

Regards,

Hervé

Le lundi 10 avril 2017, 07:35:49 CEST Francesco Chicchiriccò a écrit :
> On 2017-04-10 09:16 (+0200), Karl Heinz Marbaise  wrote:
> > Hi,
> > 
> > On 10/04/17 09:11, Francesco Chicchiricc� wrote:
> > > On 2017-04-10 08:58 (+0200), Karl Heinz Marbaise  
wrote:
> > >> Hi,
> > >> 
> > >> On 10/04/17 08:45, Francesco Chicchiriccò wrote:
> > >>> Thanks Hervé,
> > >>> appending
> > >>> 
> > >>> -Dstyle.success=green
> > >>> 
> > >>> to my MAVEN_OPTS did the trick.
> > >>> 
> > >>> Is there any place where defaults for all styles (debug, info,
> > >>> warning, error, success, warning, failure, strong, mojo and project)
> > >>> are reported? Thanks!> >> 
> > >> Yes if you do a mvn -X clean:
> > >> ...
> > >> 
> > >> [DEBUG]   Imported: org.slf4j.helpers.* < plexus.core
> > >> [DEBUG]   Imported: org.slf4j.spi.* < plexus.core
> > >> [DEBUG] Populating class realm maven.api
> > >> [INFO] Error stacktraces are turned on.
> > >> [DEBUG] Message scheme: color
> > >> [DEBUG] Message styles: debug info warning error success failure strong
> > >> mojo project
> > >> [DEBUG] Reading global settings from /usr/local/maven/conf/settings.xml
> > >> [DEBUG] Reading user settings from /Users/kama/.m2/settings.xml
> > >> [DEBUG] Reading global toolchains from
> > >> /usr/local/maven/conf/toolchains.xml
> > >> [DEBUG] Reading user toolchains from /Users/kama/.m2/toolchains.xml
> > > 
> > > Sorry, I don't get it: where do I see, i.e., that style.info is blue by
> > > default?> 
> > The following line is colored by the appropriate colors which are
> > used...you should not do a redirect into a pipe via less/more etc..
> > 
> > >> [DEBUG] Message styles: debug info warning error success failure strong
> 
> I see:
> 
> http://pasteboard.co/2wnAdZx8P.png
> 
> but still do not have the equivalent color name (e.g. that info is 'blue': I
> can guess it, naturally...).
> 
> Regards.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Any way to change the color scheme in Maven 3.5.0?

[Hervé BOUTEMY]

the big question for me is: how to make that list available? A new CLI option? 
A new goal in a plugin? which one? help? other ideas?

Once we know where to put the feature, the content can be reworked adapted to 
the context

Regards,

Hervé

Le mardi 11 avril 2017, 21:35:19 CEST Robert Scholte a écrit :
> I still wonder if we want to have this.
> It is less interesting which colors are used, but instead more interesting
> the colors you want.
> So having a list with the available options would be good enough for me.
> 
> Robert
> 
> On Tue, 11 Apr 2017 00:42:15 +0200, Hervé BOUTEMY <herve.bout...@free.fr>
> 
> wrote:
> > there is no feature now to dump effective config as text: didn't think
> > at this
> > scenario
> > 
> > PRs welcome or at least ideas on where to add this feature to make it
> > usable
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le lundi 10 avril 2017, 07:35:49 CEST Francesco Chicchiriccò a écrit :
> >> On 2017-04-10 09:16 (+0200), Karl Heinz Marbaise <khmarba...@gmx.de>
> >> 
> >> wrote:
> >> > Hi,
> >> > 
> >> > On 10/04/17 09:11, Francesco Chicchiricc� wrote:
> >> > > On 2017-04-10 08:58 (+0200), Karl Heinz Marbaise <khmarba...@gmx.de>
> > 
> > wrote:
> >> > >> Hi,
> >> > >> 
> >> > >> On 10/04/17 08:45, Francesco Chicchiriccò wrote:
> >> > >>> Thanks Hervé,
> >> > >>> appending
> >> > >>> 
> >> > >>> -Dstyle.success=green
> >> > >>> 
> >> > >>> to my MAVEN_OPTS did the trick.
> >> > >>> 
> >> > >>> Is there any place where defaults for all styles (debug, info,
> >> > >>> warning, error, success, warning, failure, strong, mojo and
> >> 
> >> project)
> >> 
> >> > >>> are reported? Thanks!> >>
> >> > >> 
> >> > >> Yes if you do a mvn -X clean:
> >> > >> ...
> >> > >> 
> >> > >> [DEBUG]   Imported: org.slf4j.helpers.* < plexus.core
> >> > >> [DEBUG]   Imported: org.slf4j.spi.* < plexus.core
> >> > >> [DEBUG] Populating class realm maven.api
> >> > >> [INFO] Error stacktraces are turned on.
> >> > >> [DEBUG] Message scheme: color
> >> > >> [DEBUG] Message styles: debug info warning error success failure
> >> 
> >> strong
> >> 
> >> > >> mojo project
> >> > >> [DEBUG] Reading global settings from
> >> 
> >> /usr/local/maven/conf/settings.xml
> >> 
> >> > >> [DEBUG] Reading user settings from /Users/kama/.m2/settings.xml
> >> > >> [DEBUG] Reading global toolchains from
> >> > >> /usr/local/maven/conf/toolchains.xml
> >> > >> [DEBUG] Reading user toolchains from /Users/kama/.m2/toolchains.xml
> >> > > 
> >> > > Sorry, I don't get it: where do I see, i.e., that style.info is
> >> 
> >> blue by
> >> 
> >> > > default?>
> >> > 
> >> > The following line is colored by the appropriate colors which are
> >> > used...you should not do a redirect into a pipe via less/more etc..
> >> > 
> >> > >> [DEBUG] Message styles: debug info warning error success failure
> >> 
> >> strong
> >> 
> >> I see:
> >> 
> >> http://pasteboard.co/2wnAdZx8P.png
> >> 
> >> but still do not have the equivalent color name (e.g. that info is
> >> 'blue': I
> >> can guess it, naturally...).
> >> 
> >> Regards.
> >> 
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: [EXTERNAL] Re: Any way to change the color scheme in Maven 3.5.0?

[Hervé BOUTEMY]

looks natural

any taker for Jira issue and/or PR?

Regards,

Hervé

Le mercredi 12 avril 2017, 12:26:07 CEST Justin Georgeson a écrit :
> I vote for a help plugin goal, like help:color-style. It could show a brief
> summary and how to customize, list available settings, and print active
> settings.
> 
> -Original Message-
> From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> Sent: Tuesday, April 11, 2017 8:10 PM
> To: Maven Users List <users@maven.apache.org>
> Subject: [EXTERNAL] Re: Any way to change the color scheme in Maven 3.5.0?
> 
> External Sender: Use caution with links/attachments.
> 
> 
> 
> the big question for me is: how to make that list available? A new CLI
> option? A new goal in a plugin? which one? help? other ideas?
> 
> Once we know where to put the feature, the content can be reworked adapted
> to the context
> 
> Regards,
> 
> Hervé
> 
> Le mardi 11 avril 2017, 21:35:19 CEST Robert Scholte a écrit :
> > I still wonder if we want to have this.
> > It is less interesting which colors are used, but instead more
> > interesting the colors you want.
> > So having a list with the available options would be good enough for me.
> > 
> > Robert
> > 
> > On Tue, 11 Apr 2017 00:42:15 +0200, Hervé BOUTEMY
> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__herve.boutemy-40f
> > ree.fr=DwIFAw=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3
> > PBhAqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=2L1RhrmrIqeZgpxGINVHucet-6gs3s
> > qlQV0EAtYNCEw=nYBx902DpsALmMqWPOBqbilCAvKsThvCi1wMNZvOomE= >
> > 
> > wrote:
> > > there is no feature now to dump effective config as text: didn't
> > > think at this scenario
> > > 
> > > PRs welcome or at least ideas on where to add this feature to make
> > > it usable
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le lundi 10 avril 2017, 07:35:49 CEST Francesco Chicchiriccò a écrit :
> > >> On 2017-04-10 09:16 (+0200), Karl Heinz Marbaise
> > >> <khmarba...@gmx.de>
> > >> 
> > >> wrote:
> > >> > Hi,
> > >> > 
> > >> > On 10/04/17 09:11, Francesco Chicchiricc� wrote:
> > >> > > On 2017-04-10 08:58 (+0200), Karl Heinz Marbaise
> > >> > > <khmarba...@gmx.de>
> > > 
> > > wrote:
> > >> > >> Hi,
> > >> > >> 
> > >> > >> On 10/04/17 08:45, Francesco Chicchiriccò wrote:
> > >> > >>> Thanks Hervé,
> > >> > >>> appending
> > >> > >>> 
> > >> > >>> -Dstyle.success=green
> > >> > >>> 
> > >> > >>> to my MAVEN_OPTS did the trick.
> > >> > >>> 
> > >> > >>> Is there any place where defaults for all styles (debug,
> > >> > >>> info, warning, error, success, warning, failure, strong, mojo
> > >> > >>> and
> > >> 
> > >> project)
> > >> 
> > >> > >>> are reported? Thanks!> >>
> > >> > >> 
> > >> > >> Yes if you do a mvn -X clean:
> > >> > >> ...
> > >> > >> 
> > >> > >> [DEBUG]   Imported: org.slf4j.helpers.*
> > >> > >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__plexus.core;
> > >> > >> d=DwIFAw=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBh
> > >> > >> AqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=2L1RhrmrIqeZgpxGINVHucet-6gs3
> > >> > >> sqlQV0EAtYNCEw=_9tu6Cs8fwmFyem4zc2ihzD2rL1RHVNlTeWNS5-acLc= >
> > >> > >> >> > >> [DEBUG]   Imported: org.slf4j.spi.*
> > >> > >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__plexus.core;
> > >> > >> d=DwIFAw=PskvixtEUDK7wuWU-tIg6oKuGYBRbrMXk2FZvF0UfTo=dLxYM3PBh
> > >> > >> AqFnkH7uKz_OVZL1uyui4QoEmBCjCmEiTk=2L1RhrmrIqeZgpxGINVHucet-6gs3
> > >> > >> sqlQV0EAtYNCEw=_9tu6Cs8fwmFyem4zc2ihzD2rL1RHVNlTeWNS5-acLc= >
> > >> > >> >> > >> [DEBUG] Populating class realm maven.api [INFO] Error
> > >> > >> stacktraces are turned on.
> > >> > >> [DEBUG] Message scheme: color
> > >> > >> [DEBUG] Message styles: debug info warning error success
> > >> > >> failure
> > >> 
> > >> 

Re: Build using toolchains version, but run unit tests against various JDKs?

[Hervé BOUTEMY]

yes, using the JDK selected by the toolchain plugin was until recently the 
intent of toolchain-plugin: help being consistent in every plugin requiring to 
use a JDK that is different from the JRE used to launch Maven

now that it works as expected, there are new use cases arising where the 
toolchain mechanism is not seen any more as a way to easily *consistently* 
select a jdk, but to easily switch between multiple JDKs *differently in some 
plugins executions*

This is not the same use case: the toolchain definition mecanism 
(toolchain.xml) is the same, but selection algorithm is different.

There was already MNG-5755 [1] implemented in Maven 3.3.1 to prepare hooks in 
Maven core and explain some use cases.
Since then, I know some use cases have been implemented but others not yet: 
I'll try to link related issues in plugins that use the feature.

In your use case, there is one additional issue: you want to run unit tests 
multiple times, each time with a different JDK configuration.
This will require new feature in Surefire plugin, with extra care on usability 
issues to be sure the new configuration can be understood by normal people.

Currently, there is a lot of work ongoing on Surefire: this new feature 
probably won't be first priority, but in the future, why not.

Regards,

Hervé


[1] https://issues.apache.org/jira/browse/MNG-5755

Le vendredi 3 mars 2017, 07:42:45 CET Russell Gold a écrit :
> I am using the toolchains plugin to ensure that the jars are produced with
> the correct JDK version; however, I want to be able to unit test against
> both that version and later versions. Is there a way to do that? The
> surefire plugin just selects the same version as was used to build.
> 
> Thanks,
> Russ
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Maven central and indexing

[Hervé BOUTEMY]

FYI, Nexus Indexer was given to Apache Maven by Sonatype in 2010:
http://incubator.apache.org/ip-clearance/maven-indexer.html

Then became Maven Indexer
http://maven.apache.org/maven-indexer/

or for better documentation:
http://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/

Regards,

Hervé

Le vendredi 10 mars 2017, 20:23:07 CET Bernd Eckenfels a écrit :
> Hello,
> Related: http://blog.sonatype.com/2008/12/central-repository-downloading-the
> -nexus-index/ And especially the news of a public available dataset (by
> Google):http://takari.io/2015/10/28/google-maven-central.html
> 
> Gruss
> Bernd



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

Re: Enforcer requirePropertyDiverges not propagated to descendants?

[Hervé BOUTEMY]

first, you'll have to talk about rules, not only the plugin: there are many 
rules, some implemented by the plugin and some implemented by MojoHaus extra-
enforcer-rules

then: MojoHaus requirePropertyDiverges [1] requires that the property value is 
different, not that it is not empty

IIUC what you're trying to do, you'll need both Maven requireProperty [2] and 
MojoHaus requirePropertyDiverge [1]

Regards,

Hervé

[1] http://www.mojohaus.org/extra-enforcer-rules/requirePropertyDiverges.html

[2] http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html

Le samedi 4 mars 2017, 21:00:03 CET org.apache.maven.u...@io7m.com a écrit :
> Hello.
> 
> I'm trying to use the Enforcer plugin to ensure that projects set a
> ${project.description} that is different to their parent. I'm using
> an organization-wide POM, and the rule is specified here:
> 
>   https://github.com/io7m/primogenitor/blob/develop/pom.xml#L540
> 
> I have an example multi-module project that uses that root POM here:
> 
>   https://github.com/io7m/primogenitor-example-20170304
> 
> If I fail to set a description in the "root" POM of that project
> (in other words, if I remove
> https://github.com/io7m/primogenitor-example-20170304/blob/master/pom.xml#L2
> 0), the Enforcer rule fails the build correctly. However, if I leave
> that description intact but then fail to set a different
> (or indeed any) description in the mod-a POM
> (https://github.com/io7m/primogenitor-example-20170304/blob/master/mod-a/pom
> .xml), the Enforcer plugin doesn't catch it. I would expect the linked
> example project to fail to build, but it doesn't!
> 
> Am I doing something wrong? I thought the purpose of the
> requirePropertyDiverges rule was to check the current project against
> its immediate parent. If this is correct, then something appears to be
> wrong with the plugin...
> 
> M



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

Re: Any way to change the color scheme in Maven 3.5.0?

[Hervé BOUTEMY]

Hi,

Yes, you can customize colors (thanks to some help I got during a Paris 
HackerGarten Meetup [1]).
Here is the link in th ereference documentation:
http://maven.apache.org/ref/3.5.0/maven-embedder/

While reading now what I wrote, it should probably be enhanced to be more 
explicit that styled message API details are particularly useful for color 
customization => I'll improve immediately this doc for the next minor release 
:)

Regards,

Hervé

[1] https://www.meetup.com/Paris-Hackergarten/

Le vendredi 7 avril 2017, 12:47:35 CEST Francesco Chicchiriccò a écrit :
> Hi all,
> I am using since quite some time Maven 3.5.0-beta-1 and I am very satisfied,
> thanks for the good work!
> 
> I was wondering if there is any mean to change the predefined color scheme:
> could you please provide any pointer WRT this?
> 
> Thanks.
> Regards.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Is there any good way to write maven site document?

[Hervé BOUTEMY]

Hi,

You can use site:run to quickly test documentation rendering each time you 
want.
On IDE plugin to ease document writing, on Maven side, the Eclipse plugin that 
was written a few years ago needs some love to run on recent Eclipse 
versions...
Given the various wiki formats [1] supported by Doxia (inside maven-site-
plugin), finding a plugin really depends on the format you'll want to use.

Regards,

Hervé

[1] http://maven.apache.org/doxia/references/index.html

Le mardi 18 juillet 2017, 10:27:36 CEST Bruce Wen a écrit :
> Hi All,
> 
> Do you use maven site in your project to manage documents? How did you do
> that? Any good IDE plugin there?
> 
> Bruce Wen



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

Re: doxia-ide/eclipse

[Hervé BOUTEMY]

Hi,

I used this plugin a few years ago, then it started to misbehave when 
upgrading Eclipse version. And now, it even does not build any more: looks 
like something changed in Eclipse ecosystem

I'll update the page to tell that this plugin does not even build any more: 
help wanted...

Regards,

Hervé

Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit :
> Hi All,
> 
> I found the eclipse update sites provided in this page do not work:
> 
> https://maven.apache.org/doxia/doxia-ide/eclipse/
> 
> Bruce Wen



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

Re: doxia-ide/eclipse

[Hervé BOUTEMY]

I forgot this update site: thanks for the reminder

I'll update the page to make it more visible, and add a "help wanted" text...

Regards,

Hervé

Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit :
> Hi,
> 
> Perhaps this plugin doesn't build, but the Eclipse update site (
> https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK.
> This plugin works fine and does the job (on Eclipse Neon.3); even if is a
> little bugged (do not let opened an APT in workbench & delete file in //).
> Personally I didn't found (until now) a better plugin for Maven site APT
> edition.
> 
> Best regards.
> 
> 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > Hi,
> > 
> > I used this plugin a few years ago, then it started to misbehave when
> > upgrading Eclipse version. And now, it even does not build any more: looks
> > like something changed in Eclipse ecosystem
> > 
> > I'll update the page to tell that this plugin does not even build any
> > more:
> > help wanted...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit :
> > > Hi All,
> > > 
> > > I found the eclipse update sites provided in this page do not work:
> > > 
> > > https://maven.apache.org/doxia/doxia-ide/eclipse/
> > > 
> > > Bruce Wen
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Reuse/Share Content among document in Maven Site

[Hervé BOUTEMY]

in maven-site-plugin, you can use Velocity [1]  (with #parse directive to 
reuse some content)

Regards,

Hervé

[1] http://maven.apache.org/doxia/doxia-sitetools/doxia-site-renderer/
index.html

Le jeudi 20 juillet 2017, 17:49:59 CEST Bruce Wen a écrit :
> Hi All,
> 
> Is there any way to share/reuse content among documents in maven site? It's
> supported by template in wiki.
> 
> https://www.mediawiki.org/wiki/Help:Templates
> 
> Bruce Wen



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

Re: doxia-ide/eclipse

[Hervé BOUTEMY]

Hi Alix,

Ah, the Jenkins job workspace is not available to anonymous.

I changed the job configuration to publish the site:
https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/
and it's containing the Eclipse update site:
https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/eclipse

It should be visible to anonymous: can you check and report, please?

If it's ok, I'll republish the content with updated link to CI result...

Regards,

Hervé

Le dimanche 23 juillet 2017, 19:35:19 CEST Alix Lourme a écrit :
> Hello Hervé,
> 
> The Doxia Editor Plugins Eclipse (latest build) update site
> <https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/d
> oxia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse
> .feature/target/site/> seems not usable for an anonymous user :-(
> 
> Best regards
> 
> 2017-07-22 11:48 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > here it is: the site is updated
> > and I managed to have the build successful again
> > 
> > help is still wanted to improve the plugin: most notably Markdown support
> > is
> > missing, since it was added after Doxia 1.3
> > 
> > but all in all, the situation is better now
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le vendredi 21 juillet 2017, 08:58:27 CEST Hervé BOUTEMY a écrit :
> > > I forgot this update site: thanks for the reminder
> > > 
> > > I'll update the page to make it more visible, and add a "help wanted"
> > > text...
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit :
> > > > Hi,
> > > > 
> > > > Perhaps this plugin doesn't build, but the Eclipse update site (
> > > > https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK.
> > > > This plugin works fine and does the job (on Eclipse Neon.3); even if
> > 
> > is a
> > 
> > > > little bugged (do not let opened an APT in workbench & delete file in
> > 
> > //).
> > 
> > > > Personally I didn't found (until now) a better plugin for Maven site
> > 
> > APT
> > 
> > > > edition.
> > > > 
> > > > Best regards.
> > > > 
> > > > 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > > > Hi,
> > > > > 
> > > > > I used this plugin a few years ago, then it started to misbehave
> > > > > when
> > > > > upgrading Eclipse version. And now, it even does not build any more:
> > > > > looks
> > > > > like something changed in Eclipse ecosystem
> > > > > 
> > > > > I'll update the page to tell that this plugin does not even build
> > > > > any
> > > > > more:
> > > > > help wanted...
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit :
> > > > > > Hi All,
> > > > > > 
> > > > > > I found the eclipse update sites provided in this page do not
> > > > > > work:
> > > > > > 
> > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/
> > > > > > 
> > > > > > Bruce Wen
> > > > > 
> > > > > 
> > 
> > -
> > 
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > > > For additional commands, e-mail: users-h...@maven.apache.org
> > > 
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org



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

Re: doxia-ide/eclipse

[Hervé BOUTEMY]

404, yes, Jenkins does not create directory index, but the content is a valid 
Eclipse update site...
To avoid the surprise of this 404, I tweaked the Jenkins job to add a minimal 
index.html:
https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/eclipse/

The site is now updated...

Regards,

Hervé

Le mardi 25 juillet 2017, 11:12:57 CEST Alix Lourme a écrit :
> Hello,
> 
> I changed the job configuration to publish the site:
> > https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/Maven-generated_Site/
> 
> OK
> 
> and it's containing the Eclipse update site: https://builds.apache.org/
> 
> > view/M-R/view/Maven/job/doxia-eclipse-editor/Maven-generated_Site/eclipse
> 
> http 404 but no authent/redirection asked => would be OK.
> 
> Best regards
> 
> 2017-07-25 7:51 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > Hi Alix,
> > 
> > Ah, the Jenkins job workspace is not available to anonymous.
> > 
> > I changed the job configuration to publish the site:
> > https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/Maven-generated_Site/
> > and it's containing the Eclipse update site:
> > https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/Maven-generated_Site/eclipse
> > 
> > It should be visible to anonymous: can you check and report, please?
> > 
> > If it's ok, I'll republish the content with updated link to CI result...
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le dimanche 23 juillet 2017, 19:35:19 CEST Alix Lourme a écrit :
> > > Hello Hervé,
> > > 
> > > The Doxia Editor Plugins Eclipse (latest build) update site
> > > <https://builds.apache.org/view/M-R/view/Maven/job/doxia-> > 
> > eclipse-editor/ws/d
> > 
> > > oxia-ide-eclipse/eclipse-plugins/features/org.apache.
> > 
> > maven.doxia.ide.eclipse
> > 
> > > .feature/target/site/> seems not usable for an anonymous user :-(
> > > 
> > > Best regards
> > > 
> > > 2017-07-22 11:48 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > > here it is: the site is updated
> > > > and I managed to have the build successful again
> > > > 
> > > > help is still wanted to improve the plugin: most notably Markdown
> > 
> > support
> > 
> > > > is
> > > > missing, since it was added after Doxia 1.3
> > > > 
> > > > but all in all, the situation is better now
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le vendredi 21 juillet 2017, 08:58:27 CEST Hervé BOUTEMY a écrit :
> > > > > I forgot this update site: thanks for the reminder
> > > > > 
> > > > > I'll update the page to make it more visible, and add a "help
> > > > > wanted"
> > > > > text...
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit :
> > > > > > Hi,
> > > > > > 
> > > > > > Perhaps this plugin doesn't build, but the Eclipse update site (
> > > > > > https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK.
> > > > > > This plugin works fine and does the job (on Eclipse Neon.3); even
> > 
> > if
> > 
> > > > is a
> > > > 
> > > > > > little bugged (do not let opened an APT in workbench & delete file
> > 
> > in
> > 
> > > > //).
> > > > 
> > > > > > Personally I didn't found (until now) a better plugin for Maven
> > 
> > site
> > 
> > > > APT
> > > > 
> > > > > > edition.
> > > > > > 
> > > > > > Best regards.
> > > > > > 
> > > > > > 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I used this plugin a few years ago, then it started to misbehave
> > > > > > > when
> > > > > > > upgrading Eclipse version. And now, it even does not build any
> > 
> > more:
> > > > > &g

Re: doxia-ide/eclipse

[Hervé BOUTEMY]

here it is: the site is updated
and I managed to have the build successful again

help is still wanted to improve the plugin: most notably Markdown support is 
missing, since it was added after Doxia 1.3

but all in all, the situation is better now

Regards,

Hervé

Le vendredi 21 juillet 2017, 08:58:27 CEST Hervé BOUTEMY a écrit :
> I forgot this update site: thanks for the reminder
> 
> I'll update the page to make it more visible, and add a "help wanted"
> text...
> 
> Regards,
> 
> Hervé
> 
> Le mercredi 19 juillet 2017, 10:55:27 CEST Alix Lourme a écrit :
> > Hi,
> > 
> > Perhaps this plugin doesn't build, but the Eclipse update site (
> > https://maven.apache.org/doxia/doxia-ide/eclipse/eclipse/) is OK.
> > This plugin works fine and does the job (on Eclipse Neon.3); even if is a
> > little bugged (do not let opened an APT in workbench & delete file in //).
> > Personally I didn't found (until now) a better plugin for Maven site APT
> > edition.
> > 
> > Best regards.
> > 
> > 2017-07-19 9:41 GMT+02:00 Hervé BOUTEMY <herve.bout...@free.fr>:
> > > Hi,
> > > 
> > > I used this plugin a few years ago, then it started to misbehave when
> > > upgrading Eclipse version. And now, it even does not build any more:
> > > looks
> > > like something changed in Eclipse ecosystem
> > > 
> > > I'll update the page to tell that this plugin does not even build any
> > > more:
> > > help wanted...
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le lundi 17 juillet 2017, 18:18:10 CEST Bruce Wen a écrit :
> > > > Hi All,
> > > > 
> > > > I found the eclipse update sites provided in this page do not work:
> > > > 
> > > > https://maven.apache.org/doxia/doxia-ide/eclipse/
> > > > 
> > > > Bruce Wen
> > > 
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: users-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Building Maven 3.5.0 on GNURoot Debian

[Hervé BOUTEMY]

Maven is built basically like any Maven project.
We have additional instruction to run its [1], but the Maven build part is 
just completely classical

Regards,

Hervé

[1] http://maven.apache.org/guides/development/guide-building-maven.html

Le samedi 20 mai 2017, 11:10:05 CEST Rupinder Singh a écrit :
> Hi,
> 
> I'm using GNURoot Debian (fakeroot Linux distro) on Anroid phone. While I
> could get maven 3.0.5 from the repository with apt-get, any higher version
> is not available. I would like maven 3.5.0. So I guess I should build it.
> Could somebody enlist the steps for my quick reference?
> 
> Regards
> Rupinder



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

Re: Compiling from source with no previous Maven installed.

[Hervé BOUTEMY]

for Maven versions before 3.5, there is an Ant build

Regards,

Hervé

Le vendredi 19 mai 2017, 07:35:39 CEST Ray Sheppard a écrit :
> Hello,
>I have tried to find the proper directions in the documentation.
> However, all documentation seems to assume there is already a Maven
> installed or that I am simply installing binaries.  I am on an AMD/ XK-7
> Cray.  I can not just plug in generic binaries and hope they understand
> the CLE 5.2 operating system.  However, there is no previous Maven
> installed.  I have installed JAVA JDK 1.8.0 already. Any help appreciated.
> Thanks,
> Ray
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Overriding the site plugin

[Hervé BOUTEMY]

you found it

I'll just add a reference documentation on default lifecycles and plugins/
goals binding:
http://maven.apache.org/ref/current/maven-core/lifecycles.html

Regards,

Hervé

Le dimanche 15 octobre 2017, 18:08:31 CEST Mark Raynsford a écrit :
> On 2017-10-15T17:02:19 +
> 
> Mark Raynsford  wrote:
> > Er, to clarify, I mean that I'd like to execute a new plugin entirely,
> > not just a different version of the maven-site-plugin. I realized after
> > I sent the message that it could be interpreted more than one way...
> 
> Managed to answer my own question. It turns out that I want to disable
> an existing binding of a plugin to a lifecycle phase, and then run my
> own plugin after that. As an example:
> 
>   
> 
>   
> org.apache.maven.plugins
> maven-site-plugin
> 3.6
> 
>   
> default-site
> none
>   
> 
>   
> 
>   
> org.apache.maven.plugins
> maven-clean-plugin
> 3.0.0
> 
>   
> default-site
> 
>   clean
> 
> site
>   
> 
>   
> 
>   
> 
> This would disable the execution of the maven-site-plugin by setting
> phase to "none", and then run the maven-clean-plugin instead. I just
> use the maven-clean-plugin as an example, it'd obviously work with any
> other plugin.



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

[ANN] Apache Maven Reporting Executor 1.4 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven 
Reporting Executor, version 1.4

Classes to manage report plugin executions with Maven 3.

https://maven.apache.org/shared/maven-reporting-exec/

You should specify the version in your project's dependency configuration:


  org.apache.maven.shared
  maven-reporting-exec
  1.4



Release Notes - Apache Maven Reporting Executor - Version 1.4

Bug
* [MSHARED-616] Dependencies inside pluginManagement are not taken into 
account in reporting

Improvement
* [MSHARED-647] display what reports are added automatically when no reportSet 
is defined
* [MSHARED-628] support maven-model ReportPlugin in addition to local copy


Enjoy,

-The Maven team


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

Re: unable to generate site with module-info defined

[Hervé BOUTEMY]

Hi Russel,

Can you give more stacktrace lines, please, since I suppose it is a reporting 
plugin issue, but I cannot figure out *which* report plugin

(and I'll have to find a way to have more tiny stacktraces when there is an 
issue with a report plugin that is launched by maven-site-plugin, since 
everybody points finger at maven-site-plugin instead of the reporting plugin 
that failed... I know that currently, from a user perspective, that is the 
natural perception: I need to find a trick to change this, I don't know how 
yet)

Regards,

Hervé

Le vendredi 29 septembre 2017, 12:25:02 CEST Russell Gold a écrit :
> I have added a module-info to my project, and now when I run mvn site, it is 
failing:
> > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> > goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site)
> > on project simplestub: Error during page generation> 
> > at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.ja
> > va:213) at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.ja
> > va:154) at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.ja
> > va:146) at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> > LifecycleModuleBuilder.java:117) at
> > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
> > LifecycleModuleBuilder.java:81) at
> > org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreade
> > dBuilder.build(SingleThreadedBuilder.java:51) at
> > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleSt
> > arter.java:128) at
> > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> > at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> > at 
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method) at
> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet
> > hodAccessorImpl.java:62) at
> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Deleg
> > atingMethodAccessorImpl.java:43) at
> > java.base/java.lang.reflect.Method.invoke(Method.java:564)
> > at
> > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launche
> > r.java:289) at
> > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:2
> > 29) at
> > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launc
> > her.java:415) at
> > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356
> > )> 
> > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during
> > page generation> 
> > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:143)
> > at
> > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBui
> > ldPluginManager.java:134) at
> > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.ja
> > va:208) ... 20 more
> > 
> > Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> > rendering Maven report: Exit code: 1 -
> > /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.java
> > :3: error: module not found: org.objectweb.asm.commons> 
> > requires org.objectweb.asm.commons;
> > 
> >   ^
> > 
> > /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.java:
> > 4: error: module not found: javassist> 
> > requires javassist;
> > 
> >  ^
> 
> Note that this code compiles and runs just find with the module-info; it
> just doesn’t generate a site.



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

Re: How to enforce running my Maven Plugin with a certain Java version

[Hervé BOUTEMY]

I fully agree with the analysis

thinking at it, it seems we could provide a backward compatible option: 
instead of changing pom.xml model to add more prerequisite features [1], why 
don't we enhance META-INF/maven/plugin.xml [2] ?

Notice that, as I write that, I see that even maven version prerequisite would 
better be in META-INF/maven/plugin.xml than in pom.xml...

WDYT?

Regards,

Hervé

[1] http://maven.apache.org/ref/3.5.0/maven-model/
maven.html#class_prerequisites

[2] http://maven.apache.org/ref/3.5.0/maven-plugin-api/plugin.html

Le jeudi 28 septembre 2017, 22:22:02 CEST Robert Scholte a écrit :
> Hi,
> 
> AFAIK there's no solution for it out of the box.
> The pom model has no option to specify it, so it cannot be solved there.
> The plugin descriptor is a Maven-only file, so that might work, but
> requires Maven to understand it.
> The other possible solution it to write an extension for it, which would
> also work with older versions of Maven.
> 
> This is also one of the main reasons why we still use Java7 to develop, so
> users won't hit this issue.
> 
> Robert
> 
> On Thu, 28 Sep 2017 12:46:33 +0200, Konrad Windszus 
> 
> wrote:
> > How can I enforce that my custom Maven Plugin (or only a certain Mojo
> > within) is only executed with at least a certain Java version (i.e.
> > Java8 due to the use of class files being only compatible with Java8+).
> > The prerequisites section which seems like the natural way to define
> > that only allows me to require a minimum Maven version
> > (http://maven.apache.org/ref/3.5.0/maven-model/maven.html#class_prerequisi
> > tes). which is not what I want here.
> > 
> > The failure message is rather unintuitive whenever my Maven Mojo is used
> > in a project with an incompatible Java version (which cannot read my
> > Mojos class files).
> > 
> > I know that in all Projects using the Maven Plugin the
> > maven-enforcer-plugin could theoretically be used, but then each
> > consuming projects needs to manually figure out the minimum java version
> > based on the documentation of all Maven Plugins. Isn't there a
> > better/more automated way, which let's Maven check this requirement
> > prior to executing any Mojos from a plugin?
> > 
> > Thanks,
> > Konrad
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Specifying version range for dependency causes resolver error; maven-metadata.xml on central looks wrong - how do I make ranges work?

[Hervé BOUTEMY]

Hi Christian,

Le jeudi 28 septembre 2017, 11:05:10 CEST Christian Balzer a écrit :
> Hi Hervé,
> 
> Thanks for your help. I'm not sure I like the answer, to be honest,
looks you clearly understood the answer :)

> although I perfectly understand the reasoning.
I think that we need to better spread the word about that

> I'll get in touch with
> the library maintainers of those libraries my project uses (hoping
> they all still have maintainers).
this is where changing maven-metadata.xml without the explicit permission of 
original authors is necessary: I suppose this will happen, and ideally a 
process for community decision would be found

> 
> The list of inconsistencies looks rather daunting. It certainly does
> mean that version ranges aren't as useful as they could be, if they
> won't work properly in a lot of cases...
I'm personally a version range sceptical for a long time, and looking for 
constructive debate to find precisely why and where version ranges may be 
useful and where definitely it is a bad idea.
Your case leads me to an idea: when you're using version ranges on your 
internal  artifacts, where you master everything of the artifact lifecycle and 
want rapid changes but don't care so much about reproducibility, perhaps 
version ranges may be useful. On public artifacts published on central, yes, 
version ranges may not be as useful since artifact providers did often not 
really manage this use case (but even if metadata are ok, change is not so 
fast)

> 
> On a related matter, is there an element for the maven-metadata.xml
> file that's similar to the pom's relocation element? (Not sure what
> the automatic resolution would do when it finds out that version 3 of
> foo:bar is now called baz:bat (warning or loading the artefact), but I
> thought I'd ask anyway...)
here is the descriptor documentation for maven-metadata.xml
http://maven.apache.org/ref/3.5.0/maven-repository-metadata/repository-metadata.html
As you can see, no relocation info.
In fact, this metadata file is often managed automagically by tools without 
people knowing the content (and eventually that it's not consistent)
Adding new features to this format would require:
- discussion with the whole ecosystem consuming Maven repositories (central or 
other) to define the feature, check existing tools don't blow up, ...
- teaching to users, and perhaps tooling, to modify manually modify and 
publish the content
Feasible but not easy, given one feature of Maven repository format is its 
stability

Regards,

Hervé

> 
> Kind regards,
> Christian
> 
> On Thu, Sep 28, 2017 at 4:27 AM, Hervé BOUTEMY <herve.bout...@free.fr> 
wrote:
> > Hi,
> > 
> > Here is a list of inconsistencies (expected to be extensive) in central
> > between maven-metadata.xml and what is in the repo [1] (updated daily): in
> > this file, each "+" is about a version that is available in the repo but
> > not referenced in maven-metadata.xml, and each "-" is about a version
> > that is in maven-metadata.xml but not in the repo
> > 
> > The maven-metadata.xml content is provided by artifact authors: we don't
> > really know if they chose to not add some version to their metadata,
> > exactly to avoid range resolution, or if they have a tooling issue.
> > There are 2 options:
> > 1. if they have a tooling issue, whatever we do today to their metadata,
> > they will break consistency again next time they publish a new artifact
> > version. 2. if it was a voluntary removal from metadata, we'll go against
> > artifact owners' will
> > 
> > IMHO, we can't safely "fix" metadata in central, since:
> > - what we call a fix from some point of view can be a deliberate choice
> > - this will surely be "broken" back later
> > 
> > Artifact owners should check their metadata and fix them if they see that
> > the content was not what they wanted (and they just never saw how maven-
> > metadata.xml was useful to people using version ranges)
> > 
> > Notice I'd personally not advise to use version ranges: but that remark
> > won't help here (and I hope by saying so I won't open a new hot debate
> > about version range lovers vs haters: please open another email thread if
> > you want to open this debate)
> > 
> > To be direct on the few artifacts you cited, I don't think it's really a
> > good idea to change the metadata at our level: it's better to ask the
> > original project to check its metadata and fix them if appropriate.
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://github.com/hboutemy/mcmm-logs/blob/master/metadata-fixes.log
> > 
> > Le mercredi 27 septembre 2017, 11:03:11 CEST Christian Balzer a écrit :
> 

Re: unable to generate site with module-info defined

[Hervé BOUTEMY]

I just improved output in MSITE-797 for future maven-site-plugin 3.7 (not yet 
released)

But please upgrade to 3.4 minimum as the error message will give you much 
better insight on the cause of the failure: see https://issues.apache.org/
jira/browse/MSITE-713

Regards,

Hervé

Le samedi 30 septembre 2017, 13:15:36 CEST Hervé BOUTEMY a écrit :
> Hi Russel,
> 
> Can you give more stacktrace lines, please, since I suppose it is a
> reporting plugin issue, but I cannot figure out *which* report plugin
> 
> (and I'll have to find a way to have more tiny stacktraces when there is an
> issue with a report plugin that is launched by maven-site-plugin, since
> everybody points finger at maven-site-plugin instead of the reporting plugin
> that failed... I know that currently, from a user perspective, that is the
> natural perception: I need to find a trick to change this, I don't know how
> yet)
> 
> Regards,
> 
> Hervé
> 
> Le vendredi 29 septembre 2017, 12:25:02 CEST Russell Gold a écrit :
> > I have added a module-info to my project, and now when I run mvn site, it
> > is
> failing:
> > > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> > > execute
> > > goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site)
> > > on project simplestub: Error during page generation>
> > > 
> > >   at
> > >   
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.j
> > >   a
> > >   va:213) at
> > >   
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.j
> > >   a
> > >   va:154) at
> > >   
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.j
> > >   a
> > >   va:146) at
> > >   
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > >   (
> > >   LifecycleModuleBuilder.java:117) at
> > >   
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> > >   (
> > >   LifecycleModuleBuilder.java:81) at
> > >   
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThread
> > >   e
> > >   dBuilder.build(SingleThreadedBuilder.java:51) at
> > >   
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleS
> > >   t
> > >   arter.java:128) at
> > >   org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
> > >   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
> > >   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
> > >   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
> > >   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
> > >   at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
> > >   at
> > >   java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> > >   Method) at
> > >   java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMe
> > >   t
> > >   hodAccessorImpl.java:62) at
> > >   java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Dele
> > >   g
> > >   atingMethodAccessorImpl.java:43) at
> > >   java.base/java.lang.reflect.Method.invoke(Method.java:564)
> > >   at
> > >   
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launch
> > >   e
> > >   r.java:289) at
> > >   
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:
> > >   2
> > >   29) at
> > >   
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Laun
> > >   c
> > >   her.java:415) at
> > >   org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:
35
> > >   6
> > >   )>
> > > 
> > > Caused by: org.apache.maven.plugin.MojoExecutionException: Error during
> > > page generation>
> > > 
> > >   at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:143)
> > >   at
> > >   
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBu
> > >   i
> > >   ldPluginManager.java:134) at
> > >   
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.j
> > >   a
> > >   va:208) ... 20 more
> > > 
> > > Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> > > rendering Maven report: Exit code: 1 -
> > > /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.jav
> > > a
> > > 
> > > :3: error: module not found: org.objectweb.asm.commons>
> 

Re: unable to generate site with module-info defined

[Hervé BOUTEMY]

ldPluginManager.java:134) at
> >>org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.j
> >>ava:208) ... 20 more
> >> 
> >> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> >> generating maven-javadoc-plugin:3.0.0-M1:javadoc: Exit code: 1 -
> >> /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.jav
> >> a:3: error: module not found: org.objectweb.asm.commons>> 
> >>requires org.objectweb.asm.commons;
> >>
> >>  ^
> >> 
> >> /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.java
> >> :4: error: module not found: javassist>> 
> >>requires javassist;
> >>    
> >> ^
> >> 
> >> Command line was:
> >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/javadoc
> >> @options @packages @argfile
> >> 
> >> Refer to the generated Javadoc files in
> >> '/Users/rgold/projects/meterware/simplestub/target/site/apidocs' dir.>> 
> >>at
> >>org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocum
> >>ent(ReportDocumentRenderer.java:239) at
> >>org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(De
> >>faultSiteRenderer.java:311) at
> >>org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultS
> >>iteRenderer.java:129) at
> >>org.apache.maven.plugins.site.render.SiteMojo.renderLocale(SiteMojo.jav
> >>a:182) at
> >>org.apache.maven.plugins.site.render.SiteMojo.execute(SiteMojo.java:141
> >>) ... 22 more
> >> 
> >> Caused by: org.apache.maven.reporting.MavenReportException:
> >> Exit code: 1 -
> >> /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.jav
> >> a:3: error: module not found: org.objectweb.asm.commons>> 
> >>requires org.objectweb.asm.commons;
> >>
> >>  ^
> >> 
> >> /Users/rgold/projects/meterware/simplestub/src/main/java/module-info.java
> >> :4: error: module not found: javassist>> 
> >>requires javassist;
> >>
> >> ^
> >> 
> >> Command line was:
> >> /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/javadoc
> >> @options @packages @argfile
> >> 
> >> Refer to the generated Javadoc files in
> >> '/Users/rgold/projects/meterware/simplestub/target/site/apidocs' dir.>> 
> >>at
> >>org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeJavadocComm
> >>andLine(AbstractJavadocMojo.java:5075) at
> >>org.apache.maven.plugins.javadoc.AbstractJavadocMojo.executeReport(Abst
> >>ractJavadocMojo.java:2093) at
> >>org.apache.maven.plugins.javadoc.JavadocReport.generate(JavadocReport.j
> >>ava:130) at
> >>org.apache.maven.plugins.site.render.ReportDocumentRenderer.renderDocum
> >>ent(ReportDocumentRenderer.java:233) ... 26 more
> >> 
> >> [ERROR]
> >> [ERROR]
> >> [ERROR] For more information about the errors and possible solutions,
> >> please read the following articles: [ERROR] [Help 1]
> >> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException> 
> > I
> > 
> >> On Sep 30, 2017, at 6:29 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote:
> >> 
> >> I just improved output in MSITE-797 for future maven-site-plugin 3.7 (not
> >> yet released)
> >> 
> >> But please upgrade to 3.4 minimum as the error message will give you much
> >> better insight on the cause of the failure: see
> >> https://issues.apache.org/
> >> jira/browse/MSITE-713
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le samedi 30 septembre 2017, 13:15:36 CEST Hervé BOUTEMY a écrit :
> >>> Hi Russel,
> >>> 
> >>> Can you give more stacktrace lines, please, since I suppose it is a
> >>> reporting plugin issue, but I cannot figure out *which* report plugin
> >>> 
> >>> (and I'll have to find a way to have more tiny stacktraces when there is
> >>> an
> >>> issue with a report plugin that is launched by maven-site-plugin, since
> >>> everybody points finger at maven-site-plugin instead of the reporting
> >>> plugin that failed... I know that currently, from a user pe

Re: Specifying version range for dependency causes resolver error; maven-metadata.xml on central looks wrong - how do I make ranges work?

[Hervé BOUTEMY]

Hi,

Here is a list of inconsistencies (expected to be extensive) in central 
between maven-metadata.xml and what is in the repo [1] (updated daily): in 
this file, each "+" is about a version that is available in the repo but not 
referenced in maven-metadata.xml, and each "-" is about a version that is in 
maven-metadata.xml but not in the repo

The maven-metadata.xml content is provided by artifact authors: we don't 
really know if they chose to not add some version to their metadata, exactly 
to avoid range resolution, or if they have a tooling issue.
There are 2 options:
1. if they have a tooling issue, whatever we do today to their metadata, they 
will break consistency again next time they publish a new artifact version.
2. if it was a voluntary removal from metadata, we'll go against artifact 
owners' will

IMHO, we can't safely "fix" metadata in central, since:
- what we call a fix from some point of view can be a deliberate choice
- this will surely be "broken" back later

Artifact owners should check their metadata and fix them if they see that the 
content was not what they wanted (and they just never saw how maven-
metadata.xml was useful to people using version ranges)

Notice I'd personally not advise to use version ranges: but that remark won't 
help here (and I hope by saying so I won't open a new hot debate about version 
range lovers vs haters: please open another email thread if you want to open 
this debate)

To be direct on the few artifacts you cited, I don't think it's really a good 
idea to change the metadata at our level: it's better to ask the original 
project to check its metadata and fix them if appropriate.

Regards,

Hervé

[1] https://github.com/hboutemy/mcmm-logs/blob/master/metadata-fixes.log

Le mercredi 27 septembre 2017, 11:03:11 CEST Christian Balzer a écrit :
> Good morning all,
> 
> Here are the versions I found yesterday that are not listed in their
> respective maven-metadata.xml files:
> 
> 1.9.13:
> http://central.maven.org/maven2/org/codehaus/jackson/jackson-core-asl/maven
> -metadata.xml 1.9.13:
> https://mvnrepository.com/artifact/org.codehaus.jackson/jackson-mapper-asl/
> maven-metadata.xml 1.2:
> http://central.maven.org/maven2/javax/servlet/jstl/maven-metadata.xml
> 3.2.1:
> http://central.maven.org/maven2/org/openoffice/juh/maven-metadata.xml
> 3.2.1:
> http://central.maven.org/maven2/org/openoffice/jurt/maven-metadata.xml
> 3.2.1:
> http://central.maven.org/maven2/org/openoffice/ridl/maven-metadata.xml
> 3.2.1:
> http://central.maven.org/maven2/org/openoffice/unoil/maven-metadata.xml
> 1.1:
> http://central.maven.org/maven2/org/opensaml/opensaml/maven-metadata.xml
> 2.1.4-1.2-2.4:
> http://central.maven.org/maven2/strutstestcase/strutstestcase/maven-metadat
> a.xml
> 
> Note that this is the finding of a spot check; there might be more
> versions missing per artefact than just the ones listed above...
> 
> Karl Heinz, if you could please add them to the ticket you created,
> that would be much appreciated.
> 
> Kind regards,
> 
> Christian
> 
> On Tue, Sep 26, 2017 at 10:16 PM, Christian Balzer
> 
>  wrote:
> > Hi Karl Heinz,
> > 
> > Thanks for your help.
> > 
> > On Tue, Sep 26, 2017 at 4:23 PM, Karl Heinz Marbaise  
wrote:
> >> Hi,
> >> 
> >> based on the feedback I got here:
> >> https://issues.sonatype.org/browse/MVNCENTRAL-2721
> > 
> > When I try to open that ticket (even when being logged in on
> > 
> > Sonatype's Jira) I get an error message:
> >> This issue can't be viewed
> >> The issue you're trying to view can't be displayed.
> >> It may have been deleted or you don't have permission to view it right
> >> now.
> > 
> > Can you please summarise what it said? If it is still accessible, I'll
> > happily add the ids for the other artifacts I found with the same
> > problems to it.
> > 
> > Thanks,
> > Christian
> > 
> >> It could be only a little time to be fixed in Maven Central..
> >> 
> >> Kind regards
> >> Karl Heinz Marbaise
> >> 
> >> On 26/09/17 13:12, Karl Heinz Marbaise wrote:
> >>> Hi,
> >>> 
> >>> On 26/09/17 13:02, Christian Balzer wrote:
>  Hi all,
>  
>  I have a pom.xml file of a legacy program that declares a dependency
>  on an Apache Commons' xml-resolver:xml-resolver via dependency
>  management and a property. The pom file looks essentially like this:
>  
>  
>  
> 1.2
>  
>  
>  
>  
> 
> 
>   
>   
>   
> xml-resolver
> xml-resolver
> ${xml-resolver.version}
>   
>   
> 
> 
>  
>  
>  
>  
> 
> 
> 
>   xml-resolver
>   xml-resolver
>   ${xml-resolver.version}
> 
> 
>  
>  
>  
>  This works; version 1.2 does exist:
>  http://central.maven.org/maven2/xml-resolver/xml-resolver/1.2/
>  
>  We now wanted to move 

Re: 1;34mINFO[m] formatting on console output

[Hervé BOUTEMY]

can you give info on Maven version and OS used?
And if you are on Windows, which command line you're using?

there is no reason to stop working:
- any Unix supports these ANSI escape codes natively
- we use JAnsi to add support on Windows

Regards,

Hervé

Le jeudi 24 août 2017, 20:54:26 CEST Friedman, Jacob a écrit :
> Howdy,
> 
> Previously, maven output for my project yielded some slight colorization to
> easily see test run results, errors etc. The other day it started producing
> some funky formatting that looked similar to:
> 
> 1;34mINFO[m] on many lines.
> 
> I did some research and I see there was a recent maven release that actually
> added some more colorization. I learned via a google search i can use 'mvn
> test -B' to remove the aforementioned formatting, but the output is black
> and white. How do I configure it so that it runs in color per the samples
> videos I've seen online about the new release.
> 
> Here's my POM file text in case that helps troubleshoot:
> http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd;>
> 4.0.0
>   cloud
>   PINR
>   jar
>   1.0-SNAPSHOT
>   PINR
>   http://maven.apache.org
>
>UTF-8
>   
>   
>
>
> src/main/java/resources
> true
>   
>
> 
>   
>   
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.20
> 
> 
>
>  
>testng.xml
>  
>  true
>
> 
>   
> 
> 
> 
>   
> 
>   
> 
>   junit
>   junit
>   3.8.1
>   test
> 
> 
>  
> org.seleniumhq.selenium
> selenium-java
> 3.4.0
> 
> 
>
>   org.testng
>   testng
>   6.8
>   compile
>
> 
>   
> org.apache.logging.log4j
> log4j-api
> 2.8.2
>   
>   
> org.apache.logging.log4j
> log4j-core
> 2.8.2
>   
> 
> com.aventstack
> extentreports
> 3.0.6
> 
>
> com.relevantcodes
> extentreports
> 2.41.2
> 
> 
> 
> com.saucelabs
> sauce_testng
> 2.1.18
> test
> 
> 
>   
> 
> 
> 
> 
> 
> 
> 
> Jacob Friedman, PMP, PMI-ACP | Optum
> Scrum Master, Optum Technology
> 
> 131 Morristown Rd, Basking Ridge, NJ 07920
> T +1 973-348-1521
> jacob.fried...@optum.com
> www.optum.com
> 
> 
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the intended
> recipient or his or her authorized agent, the reader is hereby notified
> that any dissemination, distribution or copying of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender by replying to this message and delete this e-mail immediately.



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

Re: 1;34mINFO[m] formatting on console output

[Hervé BOUTEMY]

ok, let's adapt to your profile

First, let's see if the issue is related to your general Maven installation or 
to your project that uses Selenium and that could cause some sort of conflict.

Can you run "mvn -V -X" from a directory where there is no pom.xml, please, 
and report if color is ok or not?
If not ok, please send me in private the output: we'll dig more in details 
later.


If it is ok, that means that you pom.xml causes conflict with JAnsi at some 
level: I'll need your build file (in private) to investigate.

Regards,

Hervé

Le dimanche 27 août 2017, 03:07:28 CEST Friedman, Jacob a écrit :
> Hi Herve,
> 
> A little background about myself.  I am a Scrum Master on a team that does
> not have a QA resource for the product I'm working on.  I undertook
> regression testing manually and decided to teach myself how to code
> Automated Selenium Regression Tests in Java.  I'm VERY new to this, so
> doing a ton of learning.  I've set up a maven project that has a Base Test
> Class, page object classes, and Test Classes that reference base.  I can
> use a data.properties file to define if I want to run my tests locally or
> on a virtual machine called Sauce labs.
> 
> Given my limited knowledge, I do not fully understand what you'd like me to
> do in your below message.  Do I just need to add the jansi reference from
> the POM file on the github link you referenced to my project's POM file? 
> If more, can you guide a little bit?  Do I unzip the file from git hub and
> add those files to my project structure?
> 
> Thanks,
> Jake
> 
> 
> Jacob Friedman, PMP, PMI-ACP | Optum
> Scrum Master, Optum Technology
> 
> 131 Morristown Rd, Basking Ridge, NJ 07920
> T +1 973-348-1521
> jacob.fried...@optum.com
> www.optum.com
> 
> 
> -Original Message-
> From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> Sent: Friday, August 25, 2017 2:42 AM
> To: Maven Users List
> Subject: Re: 1;34mINFO[m] formatting on console output
> 
> then JAnsi http://fusesource.github.io/jansi/ should detect this OS and do
> the magic to interpret these ANSI escape codes
> 
> This is tested by many people on many Windows 7 machines: I don't know what
> is specific to yours
> 
> I opened a PR to JAnsi a few months ago https://github.com/fusesource/jansi/
> pull/88 to have a test utility built into JAnsi library to test its
> features independently of any integration (like Maven integrates it): but
> the PR is not yet merged. It's sad, since it's really to diagnose case like
> yours (when you report issues to Maven that are more probably tied to
> JAnsi)
> 
> Can you build this JAnsi snapshot with the PR and test, please?
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 24 août 2017, 18:21:01 CEST Stephen Cobb a écrit :
> > That's what I have. I got a GO ProBook 7. It's got an Intel I-5 and a
> > 250 STATA HD but 4 GB RAM is all but it's not that slow. Runs at about 2.3
> > GH. This is a PHO Utility right?
> > 
> > On Aug 24, 2017 6:11 PM, "Friedman, Jacob" <jacob.fried...@optum.com>
> > wrote:
> > 
> > Hi Herve,
> > 
> > I'm using Windows 7 64 Bit machine.
> > 
> > I'm using cmd to get to the console.
> > 
> > I'm using maven 3.5
> > 
> > Thanks,
> > Jake
> > 
> > 
> > 
> > Jacob Friedman, PMP, PMI-ACP | Optum
> > Scrum Master, Optum Technology
> > 
> > 131 Morristown Rd, Basking Ridge, NJ 07920
> > T   +1 973-348-1521
> > jacob.fried...@optum.com
> > www.optum.com
> > 
> > 
> > -Original Message-
> > From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> > Sent: Thursday, August 24, 2017 5:43 PM
> > To: Maven Users List
> > Subject: Re: 1;34mINFO[m] formatting on console output
> > 
> > can you give info on Maven version and OS used?
> > And if you are on Windows, which command line you're using?
> > 
> > there is no reason to stop working:
> > - any Unix supports these ANSI escape codes natively
> > - we use JAnsi to add support on Windows
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le jeudi 24 août 2017, 20:54:26 CEST Friedman, Jacob a écrit :
> > > Howdy,
> > > 
> > > Previously, maven output for my project yielded some slight
> > > colorization to easily see test run results, errors etc. The other
> > > day it started producing some funky formatting that looked similar to:
> > > 
> > > 1;34mINFO[m] on many lines.
> > > 
> > > I did some research and I see there was a recent maven release that
> > > actually

Re: 1;34mINFO[m] formatting on console output

[Hervé BOUTEMY]

then JAnsi http://fusesource.github.io/jansi/ should detect this OS and do the 
magic to interpret these ANSI escape codes

This is tested by many people on many Windows 7 machines: I don't know what is 
specific to yours

I opened a PR to JAnsi a few months ago https://github.com/fusesource/jansi/
pull/88 to have a test utility built into JAnsi library to test its features 
independently of any integration (like Maven integrates it): but the PR is not 
yet merged. It's sad, since it's really to diagnose case like yours (when you 
report issues to Maven that are more probably tied to JAnsi)

Can you build this JAnsi snapshot with the PR and test, please?

Regards,

Hervé

Le jeudi 24 août 2017, 18:21:01 CEST Stephen Cobb a écrit :
> That's what I have. I got a GO ProBook 7. It's got an Intel I-5 and a 250
> STATA HD but 4 GB RAM is all but it's not that slow. Runs at about 2.3 GH.
> This is a PHO Utility right?
> 
> On Aug 24, 2017 6:11 PM, "Friedman, Jacob" <jacob.fried...@optum.com> wrote:
> 
> Hi Herve,
> 
> I'm using Windows 7 64 Bit machine.
> 
> I'm using cmd to get to the console.
> 
> I'm using maven 3.5
> 
> Thanks,
> Jake
> 
> 
> 
> Jacob Friedman, PMP, PMI-ACP | Optum
> Scrum Master, Optum Technology
> 
> 131 Morristown Rd, Basking Ridge, NJ 07920
> T   +1 973-348-1521
> jacob.fried...@optum.com
> www.optum.com
> 
> 
> -Original Message-
> From: Hervé BOUTEMY [mailto:herve.bout...@free.fr]
> Sent: Thursday, August 24, 2017 5:43 PM
> To: Maven Users List
> Subject: Re: 1;34mINFO[m] formatting on console output
> 
> can you give info on Maven version and OS used?
> And if you are on Windows, which command line you're using?
> 
> there is no reason to stop working:
> - any Unix supports these ANSI escape codes natively
> - we use JAnsi to add support on Windows
> 
> Regards,
> 
> Hervé
> 
> Le jeudi 24 août 2017, 20:54:26 CEST Friedman, Jacob a écrit :
> > Howdy,
> > 
> > Previously, maven output for my project yielded some slight
> > colorization to easily see test run results, errors etc. The other day
> > it started producing some funky formatting that looked similar to:
> > 
> > 1;34mINFO[m] on many lines.
> > 
> > I did some research and I see there was a recent maven release that
> > actually added some more colorization. I learned via a google search i
> > can use 'mvn test -B' to remove the aforementioned formatting, but the
> > output is black and white. How do I configure it so that it runs in
> > color per the samples videos I've seen online about the new release.
> > 
> > Here's my POM file text in case that helps troubleshoot:
> > http://maven.apache.org/POM/4.0.0;
> > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> > http://maven.apache.org/maven-v4_0_0.xsd;>
> > 4.0.0
> > 
> >   cloud
> >   PINR
> >   jar
> >   1.0-SNAPSHOT
> >   PINR
> >   http://maven.apache.org
> >   
> >
> >
> >UTF-8
> >   
> >   
> >   
> >   
> >
> >
> >
> > src/main/java/resources
> > true
> >   
> >   
> >   
> >
> >   
> >   
> >   
> >   
> >   
> > org.apache.maven.plugins
> > maven-surefire-plugin
> > 2.20
> > 
> >
> >
> >  
> >  
> >testng.xml
> >  
> >  
> >  true
> >  
> >
> >   
> >   
> > 
> > 
> > 
> >   
> >   
> >   
> >   
> > 
> > 
> >   junit
> >   junit
> >   3.8.1
> >   test
> > 
> > 
> > 
> >  
> >  
> > org.seleniumhq.selenium
> > selenium-java
> > 3.4.0
> > 
> > 
> > 
> >
> >   
> >   org.testng
> >   testng
> >   6.8
> >   compile
> >   
> >
> >   
> >   
> >   
> > org.apache.logging.log4j
> > log4j-api
> > 2.8.2
> >   
> >   
> >   
> >   
> > org.apache.logging.log4j
> > log4j-core
> > 2.8.2
> >   
> >   
> > 
> > 
> >

Re: Any way to activate a profile based on a property substring?

[Hervé BOUTEMY]

the current PropertyProfileActivator [1] does not provide such feature

I imagine you can create an extension that will behave the way you want

Regards,

Hervé

[1] http://maven.apache.org/ref/3.5.2/maven-model-builder/xref/org/apache/
maven/model/profile/activation/PropertyProfileActivator.html

Le vendredi 10 novembre 2017, 12:58:42 CET Eric Benzacar a écrit :
> Is there any way to use a substring of a property for profile activation in
> Maven? I'm looking to use Jenkins to simply pass the branch name to my
> build, and have a profile activated if it is a release/* branch.
> 
> Is there any way I can do parameter manipulation/regex like this for
> profile activation? Ex:
> 
>   
> 
>   appserverConfig-dev
>   
> 
>   branch
> 
>release/.*
> 
>   
>   
> /path/to/dev/appserver
>   
> 
>
> 
> Or is there a different/better approach that I can use to only activate the
> profile if the build is coming from a release branch?
> 
> 
> Thanks
> 
> 
> Eric



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

Re: using includes in maven-source-plugin induces sources are not found anymore

[Hervé BOUTEMY]

yes, really ugly :)

usual with Maven when you're trying to do by configuration something that would 
best be served with a supported feature, that defines the associated convention

that's why I told at the beginning that perhaps it deserved a new feature in 
maven-source-plugin

something like "additionnalFiles" list that would add some files at root of the 
generated jar (like NOTICE and LICENSE)

I'm open to PRs :)

Regards,

Hervé

Le jeudi 2 novembre 2017, 22:25:49 CET MAISONOBE Luc a écrit :
> Hi,
> 
> MAISONOBE Luc <luc.maison...@c-s.fr> a écrit :
> > Hervé BOUTEMY <herve.bout...@free.fr> a écrit :
> >> Hi,
> > 
> > Hi Hervé,
> > 
> >> AFAIK, reading the plugin source code, there is no feature to add files
> >> that are not in compile source root: this will require a new feature.
> >> 
> >> Did you try adding a secondary source root, using
> >> build-helper:add-source?
> > 
> > I just tried it, thanks for the suggestion. It doesn't work.
> > The LICENSE.txt and NOTICE.txt files live in the root directory,
> > alongside the pom. So this implies adding the full project in the
> > source tree. It creates huge problems has there are java files
> > underneath (in src/main/java, and src/test/java).
> > 
> > I also tried maven-resource-plugin, but it also adds full directories,
> > not single files.
> > 
> > 
> > I did understood why my source disappeared. The default pattern **/*.java
> > is added only if combined includes is empty. I also understood the
> > pattern is eveluated with respect to the source tree, not the project
> > root.
> > 
> > So adding something like:
> >   
> >   
> >  **/*.java
> >  something-else
> >   
> >   
> > 
> > should probably work... as long as something else is in the sources tree.
> > 
> > I tried to use ../../../LICENSE.txt to go upward, but
> > it doesn't work either.
> 
> I finally managed to do what I wanted. The solution involved:
> 
>- using maven-antrun-plugin to:
> + create a directory
> ${project.build.outputDirectory}/license-and-notice-placeholder
> + copy LICENSE.txt from top directory to the created directory
> + copy NOTICE.txt from top directory to the created directory
>- using build-helper-maven-plugin to add this directory to the
> sources directories
>- use maven-source-plugin with includes set to:
> + **/*.java
> + LICENSE.txt
> + NOTICE.txt
> 
> All three plugins are run only in a profile and they are bound to
> package phase.
> 
> This works, but it is really ugly.
> 
> best regards,
> Luc
> 
> > best regards,
> > Luc
> > 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le jeudi 2 novembre 2017, 11:54:58 CET Luc Maisonobe a écrit :
> >>> Hi all,
> >>> 
> >>> I am using maven-souce-plugin in a profile, in order to generate the
> >>> sources jar. As this sources jar is in a sense a source distribution
> >>> (even if it is intended only for IDE completion use), it should
> >>> include the LICENSE.txt and NOTICE.txt files that are present at
> >>> the top level of the project.
> >>> 
> >>> So my pom looks as follows:
> >>> 
> >>> 
> >>> 
> >>>  release
> >>>  
> >>>
> >>>
> >>>
> >>>   
> >>>   
> >>>org.apache.maven.plugins
> >>>maven-source-plugin
> >>>3.0.1
> >>>
> >>>
> >>>  
> >>>  
> >>>LICENSE.txt
> >>>NOTICE.txt
> >>>  
> >>>  
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>>  
> >>>create-source-jar
> >>>
> >>>
> >>>  jar
> >>>
> >>>
> >>>package
> >>>  
> >>>  
> >>>
> >>>
> >>>  
> >>>  
> >>>
> >>>
> >>>  
> >>>  
> >>> 
> >>> 
> >>> 
> >>> When I run "mvn -Prelease package", I get the following error:
>

Re: using includes in maven-source-plugin induces sources are not found anymore

[Hervé BOUTEMY]

Hi,

AFAIK, reading the plugin source code, there is no feature to add files that 
are not in compile source root: this will require a new feature.

Did you try adding a secondary source root, using build-helper:add-source?

Regards,

Hervé

Le jeudi 2 novembre 2017, 11:54:58 CET Luc Maisonobe a écrit :
> Hi all,
> 
> I am using maven-souce-plugin in a profile, in order to generate the
> sources jar. As this sources jar is in a sense a source distribution
> (even if it is intended only for IDE completion use), it should
> include the LICENSE.txt and NOTICE.txt files that are present at
> the top level of the project.
> 
> So my pom looks as follows:
> 
> 
>   release
> 
> 
>
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.1
> 
>   
> LICENSE.txt
> NOTICE.txt
>   
> 
> 
>   
> create-source-jar
> 
>   jar
> 
> package
>   
> 
>   
> 
>   
> 
> 
> When I run "mvn -Prelease package", I get the following error:
> 
> [INFO] --- maven-source-plugin:3.0.1:jar (create-source-jar) @ orekit ---
> [INFO] No sources in project. Archive not created.
> 
> 
> If I remove the ... part, the source jar
> is created nominally, as the sources are in the standard src/main/java
> directory.
> 
> It seems to me that adding the ... somehow hides
> or clears the regular list of source files. I would have expected that
> includes adds to this list.
> 
> I have tried to add the path to the sources in a third ,
> alongside the LICENSE and NOTICE ones, using either
> {$project.buid.sourceDirectory} or hard-coded paths, but nothing works,
> or at least I did not find the correct include statement.
> 
> How can I put these two extra files into the source jar and still have
> the sources too?
> 
> best regards,
> Luc
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Excluding inherited developers

[Hervé BOUTEMY]

I fear there is no feature for that

this is an opportunity to explain the code:
1. everything is in maven-model-builder [1]
2. the step of interest here is inheritance assembly [2]
3. and if you look at source code [3], there is code to avoid emptying data 
during inheritance, but no merge facilities and even less merge with cleanup 
(= what you're looking for)

If you can imagine a clean way of configuring inheritance with merge and 
cleanup at pom XML level, the impementation of the merge feature will be coded 
at this place

Don't hesitate to discuss the feature both from a user point of view first and 
trying to code it: we're looking for contribution. This one should not be that 
hard to code, IMHO, but the important step is to ind a way to make is usable 
in pom.xml.

Regards,

Hervé

[1] http://maven.apache.org/ref/3.5.2/maven-model-builder/

[2] http://maven.apache.org/ref/3.5.2/maven-model-builder/
index.html#Inheritance_Assembly

[3] http://maven.apache.org/ref/3.5.2/maven-model-builder/xref/org/apache/
maven/model/merge/MavenModelMerger.html#L207

Le vendredi 8 décembre 2017, 15:27:11 CET James Hutton a écrit :
> I have a BOM that someone has added a developers and contributors section
> to.   I'd like to leverage some maven reports that include both those
> sections however I'd like do exclude the inherited values.  Does anyone
> have a suggestion to remove the inherited tag values?   I've tried adding a
> blank  and  in an intermediary BOM with no luck.
> 
> 
> Thanks,
> James



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

Re: Maven site filter properties with a period

[Hervé BOUTEMY]

on MSITE-799, I explained the common mistake

please review and help me improve the documentation, since you're not the first 
hit by Velocity vs Markdown conflict on ##

http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/examples/
creating-content.html#Filtering

I'll probably do a new maven-site-plugin release in a few weeks: this lets us 
time to improve the explanations before they appear on the current 
documentation

Regards,

Hervé

Le vendredi 20 octobre 2017, 18:28:33 CEST Alex O'Ree a écrit :
> Thanks, that confirms it. Now i can find out this why is failing, i'm be set
> 
> https://issues.apache.org/jira/projects/MSITE/issues/MSITE-799
> 
> On Thu, Oct 19, 2017 at 1:34 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> 
> wrote:
> > there is some doc about this:
> > http://maven.apache.org/plugins/maven-site-plugin/
> > examples/creating-content.html#Filtering
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le lundi 16 octobre 2017, 20:22:04 CEST Alex O'Ree a écrit :
> > > I have some pom defined properties that I'm trying to inject into a
> > > maven
> > > site markdown file. The file is named "test.md.vm" and it's referenced
> > > in
> > > the site descriptor.
> > > 
> > >  
> > >  
> > > > This property is used to test PDF .vm
> > > > 
> > > > project injection. If you can read this in the PDF output, it's
> > > > working.
> > > > 
> > > > This property is used to test PDF .vm
> > 
> > project
> > 
> > > > injection. If you can read this in the PDF output, it's
> > > > working.
> > > > 
> > > > 
> > > 
> > > And in the test markdown file has this
> > > 
> > > ### User defined properties in the parent pom
> > > 
> > > > testProject.property = ${testProject.property}
> > > > testProjectProperty = ${testProjectProperty}
> > > 
> > > I've noticed that pom defined properties containing a period do not
> > 
> > resolve
> > 
> > > for some reason. Properties without the dot work just fine.
> > > 
> > > 
> > > Output:
> > > 
> > > testProject.property = ${testProject.property}
> > > 
> > > > testProjectProperty = This property is used to test PDF .vm project
> > > > injection. If you can read this in the PDF output, it’s working.
> > > 
> > > Am I missing something or this is a plexus configuration injection
> > 
> > related
> > 
> > > thing? This also affects the pdf plugin too
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org



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

Re: Maven site filter properties with a period

[Hervé BOUTEMY]

good idea: done

thank you

Regards,

Hervé

Le samedi 21 octobre 2017, 15:45:02 CEST Alex O'Ree a écrit :
> I would say it's fine as is, but one possible suggestion would be add a h4
> under the "Filtering" section labeled "Common Problems". Under that you can
> put the parts related to properties with dots and the ## markdown issue
> 
> On Fri, Oct 20, 2017 at 10:50 PM, Alex O'Ree <spyhunte...@gmail.com> wrote:
> > Excellent, thanks Hervé
> > 
> > On Fri, Oct 20, 2017 at 10:33 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> > 
> > wrote:
> >> on MSITE-799, I explained the common mistake
> >> 
> >> please review and help me improve the documentation, since you're not the
> >> first
> >> hit by Velocity vs Markdown conflict on ##
> >> 
> >> http://maven.apache.org/plugins-archives/maven-site-plugin-> >> 
> >> LATEST/examples/
> >> creating-content.html#Filtering
> >> <http://maven.apache.org/plugins-archives/maven-site-plugin-LATEST/exampl
> >> es/creating-content.html#Filtering>
> >> 
> >> I'll probably do a new maven-site-plugin release in a few weeks: this
> >> lets us
> >> time to improve the explanations before they appear on the current
> >> documentation
> >> 
> >> Regards,
> >> 
> >> Hervé
> >> 
> >> Le vendredi 20 octobre 2017, 18:28:33 CEST Alex O'Ree a écrit :
> >> > Thanks, that confirms it. Now i can find out this why is failing, i'm
> >> 
> >> be set
> >> 
> >> > https://issues.apache.org/jira/projects/MSITE/issues/MSITE-799
> >> > 
> >> > On Thu, Oct 19, 2017 at 1:34 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> >> > 
> >> > wrote:
> >> > > there is some doc about this:
> >> > > http://maven.apache.org/plugins/maven-site-plugin/
> >> > > examples/creating-content.html#Filtering
> >> > > 
> >> > > Regards,
> >> > > 
> >> > > Hervé
> >> > > 
> >> > > Le lundi 16 octobre 2017, 20:22:04 CEST Alex O'Ree a écrit :
> >> > > > I have some pom defined properties that I'm trying to inject into a
> >> > > > maven
> >> > > > site markdown file. The file is named "test.md.vm" and it's
> >> 
> >> referenced
> >> 
> >> > > > in
> >> > > > the site descriptor.
> >> > > > 
> >> > > >  
> >> > > >  
> >> > > > > This property is used to test PDF
> >> 
> >> .vm
> >> 
> >> > > > > project injection. If you can read this in the PDF output, it's
> >> > > > > working.
> >> > > > > 
> >> > > > > This property is used to test PDF
> >> > > > > .vm
> >> > > 
> >> > > project
> >> > > 
> >> > > > > injection. If you can read this in the PDF output, it's
> >> > > > > working.
> >> > > > > 
> >> > > > > 
> >> > > > 
> >> > > > And in the test markdown file has this
> >> > > > 
> >> > > > ### User defined properties in the parent pom
> >> > > > 
> >> > > > > testProject.property = ${testProject.property}
> >> > > > > testProjectProperty = ${testProjectProperty}
> >> > > > 
> >> > > > I've noticed that pom defined properties containing a period do not
> >> > > 
> >> > > resolve
> >> > > 
> >> > > > for some reason. Properties without the dot work just fine.
> >> > > > 
> >> > > > 
> >> > > > Output:
> >> > > > 
> >> > > > testProject.property = ${testProject.property}
> >> > > > 
> >> > > > > testProjectProperty = This property is used to test PDF .vm
> >> 
> >> project
> >> 
> >> > > > > injection. If you can read this in the PDF output, it’s working.
> >> > > > 
> >> > > > Am I missing something or this is a plexus configuration injection
> >> > > 
> >> > > related
> >> > > 
> >> > > > thing? This also affects the pdf plugin too
> >> > > 
> >> > > -
> >> > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> > > For additional commands, e-mail: users-h...@maven.apache.org
> >> 
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org



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

[ANN] Apache Maven Site Plugin 3.7.1 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Site 
Plugin, version 3.7.1

The Maven Site Plugin is a plugin that generates a site for the current 
project.

https://maven.apache.org/plugins/maven-site-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-site-plugin
  3.7.1


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-site-plugin/download.cgi

Release Notes - Maven Site Plugin - Version 3.7.1

** Bug
* [MSITE-806] - Site generation does not work when no report configured nor 
Doxia document provided
* [MSITE-809] - Documentation: examples/configuring-reports.html includes 
invalid XML
* [MSITE-812] - Missing '/' in log when deploying documentation by 
site:stage
* [MSITE-817] - inherit edit value in site.xml
* [MSITE-818] - site:run fails to find locale when zh_CN is used

** Improvement
* [MSITE-811] - Upgrade parent to 31
* [MSITE-819] - improve display of site rendering with locale info

** Wish
* [MSITE-815] - highlight skin used to render site and documents 
statistics

** Task
* [MSITE-767] - Revert r1729902 caused by DOXIASITETOOLS-155 and fix ITs as 
soon as parent POMs and site.xml descriptors have been upgraded
* [MSITE-821] - add documentation on site plugin dependencies

Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven Plugin Tools 3.5.2 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache 
Maven Plugin Tools, version 3.5.2, including Apache Maven Plugin Plugin 3.5.2

The Maven Plugin Tools contains the necessary tools to generate 
rebarbative content like descriptor, help and documentation. In addition, 
it provides tools to write Maven Plugins in scripting languages like Ant 
or Beanshell.

The Maven Plugin Plugin is used to create a Maven plugin descriptor for 
any Mojo's found in the source tree, to include in the JAR. It is also 
used to generate report files for the Mojos as well as for updating the 
plugin registry, the artifact metadata and generating a generic help goal.

https://maven.apache.org/plugin-tools/
https://maven.apache.org/plugin-tools/maven-plugin-plugin/

You should specify the version in your project's plugin configuration:


   org.apache.maven.plugins
   maven-plugin-plugin
   3.5.2


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins-tools/download.cgi

Release Notes - Maven Plugin Tools - Version 3.5.2

** Dependency upgrade
* [MPLUGIN-333] - Upgrade parent to 31
* [MPLUGIN-334] - Upgrade mave-surefire/failsafe-plugin 2.21.0
* [MPLUGIN-335] - Support JDK 10 for plugin generation: upgrade asm
* [MPLUGIN-338] - Upgrade plexus-archiver to 3.6.0

Enjoy,

-The Apache Maven team



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

Re: [maven-scm-api] Looking to perform svn remote move

[Hervé BOUTEMY]

Le vendredi 18 mai 2018, 22:36:20 CEST Rob Tompkins a écrit :
> > On May 18, 2018, at 3:30 PM, Michael Osipov  wrote:
> > 
> > Am 2018-05-17 um 15:12 schrieb Rob Tompkins:
> > > Hello maven guys,
> > > 
> > > Over on commons we’ve been writing our own release-plugin
> > 
> > What is wrong with the current Maven Release Plugin and why are you
> > writing your own whereas we could improve the current one, can't we?
> We are trying to fit the Apache release paradigm where we are dealing with
> assemblies that we don’t want to deliver to Nexus. Further we are
> publishing the site up to our dev dist area for comparison with RC
> validation. We could contribute it back to the release plugin, but I’m not
> sure if it’s sufficiently general. Thoughts?

IIUC, the "release plugin" from Commons provides 3 mojos to prepare 3 
assemblies: it does not replace "release plugin" from Maven, which modifies 
pom.xml to switch from -SNAPSHOT to release version then to next SNAPSHOT

How is Commons release plugin used during a Commons release vs Maven release 
plugin? Do Commons use "mvn release:prepare" then "mvn release:perform", and 
the build in the release profile runs the 3 mojos to get the 3 assemblies?

Because what I see in this Commons release plugin look like custom steps to 
add to Maven release plugin, in addition to currently provided ones: as Robert 
wrote, there is a WIP in Maven release plugin to document how to add new 
steps. The Maven release plugin is already organized in steps, to be flexible, 
but just has not documented how to add new steps.

Regards,

Hervé

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





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

Re: Maven coordinates terminology

[Hervé BOUTEMY]

Le vendredi 8 juin 2018, 09:18:59 CEST Ross Goldberg a écrit :
> Is there any established terminology for the following Maven coordinates
> situations?
AFAIK, no

> 
> (I've included possible terms underneath each situation, in case no term
> currently exists for it)
> 
>  - have groupId, artifactId & version that might or might not actually
> resolve to an artifact in a specific repository
>  - resolvable coordinates
>  - versioned coordinates
+1 to "versioned coordinates"

> 
>  - have groupId, artifactId & version that resolves to an artifact in a
> specific repository
>  - valid coordinates
>  - resolved coordinates
+1 to "resolved coordinates"

> 
>  - have groupId, artifactId & version that does not resolve to an artifact
> in a specific repository
>  - unknown coordinates
>  - invalid coordinates
>  - unfound coordinates
unavailable-in-repository coordinates?

> 
>  - have groupId & artifactId, but no version
>  - unversioned coordinates
+1

> 
>  - have groupId & artifactId; might or might not have version
>  - identified coordinates (I'm not a huge fan of this, but haven't yet
> thought of anything better)
unversioned coordinates?

> 
>  - have groupId, artifactId & version, plus at least one of packaging or
> classifier
"packaging" is not part of coordinates: what you can have is "type"
see https://maven.apache.org/ref/3.5.3/maven-model/maven.html#class_dependency

>  - extended coordinates
"full coordinates"?
because "jar" type is a default value

> 
>  - each of the situations above that includes a version, but with a version
> range instead of an exact version
not every situation has a meaning
but something like "range coordinates" might do the job

Regards,

Hervé




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

Re: Maven coordinates terminology

[Hervé BOUTEMY]

Le vendredi 8 juin 2018, 22:53:17 CEST Ross Goldberg a écrit :
> Thanks for the insight, Hervé.
> 
> "packaging" is not part of coordinates: what you can have is "type"
> 
> 
> I got "packaging" from:
> 
> https://maven.apache.org/pom.html#Maven_Coordinates
> 
> Is that page out of date?  Or is "type" used in some circumstances /
> contexts, and "packaging" used in others?
thanks for the pointer: I knew there were some misunderstandings, but I didn't 
really find yet where they come from

packaging is used at build time (MavenProject in maven-artifact-transfert), to 
define what plugins have to be executed, then what artifacts will be generated
type is used in dependency and artifact contexts

> 
> For the category terms, if resolving an artifact means both finding &
> downloading it, instead of just finding it, then I should change some of
> the category descriptions & names:
> 
> have groupId, artifactId & version that identifies an artifact in a
> 
> > specific repository
> 
> This corresponds to the previously proposed "resolved".  I'd rename it
> either resolvable, or available.
available, yes

resolve is used in "resolve dependencies" context, which downloads 
dependencies
while we are at terms, "collect" calculates the dependencies but does not 
download them (just does download poms, which are necessary to calculate 
dependencies)

> 
> have groupId, artifactId & version that does not identify any artifact in a
> 
> > specific repository
> 
> This corresponds to the previously proposed "unavailable-in-repository".  
> I'd rename it either unresolvable, or unavailable.
> 
> I think the names should be chosen as a consistent pair: either resolvable
> & unresolvable, or available & unavailable.
I'm more with (un)available, since resolving is used when resolving 
dependencies

> 
> have groupId & artifactId; might or might not have version
> 
> 
> Instead of making a special term for this category, it's probably better to
> just require that all coordinates have both groupId & artifactId, and to
> term any "coordinates" that don't have both as "incomplete coordinates".





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

Re: How to create a site/doxia plugin?

[Hervé BOUTEMY]

Hi Peter,

What do you call a Doxia plugin?

I see misc interpretations:

- a Doxia module [1], to support a new output format = a new Sink, see the 
currfent modules that provide Sinks (and not only parsers) [2]

- a Skin [3], to have a web site that matches better your intent

- a new Maven plugin that integrates reports in another way than maven-site-
plugin and maven-pdf-plugin

Perhaps it's something else: you'll need to describe more precisely what parts 
you want to reuse and which part you want to extend

Regards,

Hervé

[1] https://maven.apache.org/doxia/overview.html

[2] https://maven.apache.org/doxia/references/index.html

[3] https://maven.apache.org/skins/index.html

Le mardi 3 juillet 2018, 07:30:19 CEST Peter Nabbefeld a écrit :
> Thank You, this is really an interesting plugin. But I don't want to
> break site generation, as I'm using it for other reports like JavaDoc, too.
> 
> I just want to write a doxia plugin, if possible, as all text-based
> documentation generators seem to be more or less broken or at least not
> able to generate the docs in the way I want.
> 
> Kind regards
> 
> Peter
> 
> Am 02.07.2018 um 14:48 schrieb Mark Raynsford:
> > On 2018-07-02T13:55:20 +0200
> > 
> > Peter Nabbefeld  wrote:
> >> Hello,
> >> 
> >> I haven't ever written a maven plugin. But, as I'm not satisfied with
> >> the doxia plugins available, I'd like to write my own. So, how would I
> >> have to write a doxia plugin?
> > 
> > Here's a plugin I wrote last year and still use to the present day:
> >https://github.com/io7m/minisite/
> > 
> > It produces sites that look like this:
> >https://www.io7m.com/software/junreachable/
> > 
> > The com.io7m.minisite.core module is independent of Maven, and the
> > com.io7m.minisite.maven_plugin module implements the actual plugin (by
> > taking data from the current Maven project and passing it to the core).
> > 
> > One thing you will need to do is unbind the existing Maven site plugin
> > from the lifecycle in any project that actually uses your plugin
> > (assuming that you bind your own site plugin to the "site" phase of the
> > 
> > build). Here's an example of how to do this:
> >https://github.com/io7m/primogenitor/blob/develop/pom.xml#L908
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org





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

Re: Maven Docker Images

[Hervé BOUTEMY]

great idea

ok, we need a git repo at ASF

what else?
Is there some sort of release process? some sort of source to release?

Regards,

Hervé

Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit :
> Thanks for the pointer, Carlos! I had searched the archives, but maybe I
> didn't go back far enough.
> 
> I think moving these Dockerfiles into an ASF repo would be great for their
> maintainability.
> 
> Thanks,
> 
> Mike
> 
> On 2017-10-19 03:50, Carlos Sanchez  wrote:
> > Arnaud is correct, I sent an email to users@ back on Fri, Nov 7, 2014,>
> > 00:23 when I created the image>
> > 
> > 
> > On Thu, Oct 19, 2017, 11:12 Arnaud H�ritier  wrote:>
> > 
> > > These images are kindly managed by a PMC member of our project (Carlos)
> 
> but>
> 
> > > yes they aren't managed directly by the project>
> > > 
> > > We can easily see with him to improve this IMO.>
> > > 
> > > When he started that (several years ago) Docker wasn't what it is
> 
> nowadays.>
> 
> > > With docker being mainstream I agree that we can reconsider this.>
> > > 
> > > The docker image build/distribution could perhaps be part of our
> 
> release>
> 
> > > process.>
> > > 
> > > WDYT Carlos ?>
> > > 
> > > On Thu, Oct 19, 2017 at 4:16 AM, Mike Drob  wrote:>
> > > 
> > > > I guess the natural follow-on question is whether the Maven
> 
> community>
> 
> > > > would consider publishing an official set of images? Or
> 
> alternatively>
> 
> > > > whether they should send a takedown notice to protect their brand
> 
> and>
> 
> > > > trademarks...>
> > > > 
> > > > On 2017-10-18 18:36, "Manfred Moser"  wrote:>
> > > > 
> > > > > No. As you can see from the github URL this is NOT an apache URL.>
> > > > > 
> > > > > https://github.com/carlossg/docker-maven>
> > > > > 
> > > > > 
> > > > > Mike Drob wrote on 2017-10-18 16:32:>
> > > > > 
> > > > > > Hello,>
> > > > > > 
> > > > > > Are the images at https://hub.docker.com/r/_/maven/ considered to
> 
> be>
> 
> > > > official>
> > > > 
> > > > > > maven docker images and blessed/published by the PMC?>
> > > > > > 
> > > > > > Thanks,>
> > > > > > Mike>
> 
> ->
> 
> > > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org>
> > > > > > For additional commands, e-mail: users-h...@maven.apache.org>
> 
> ->
> 
> > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org>
> > > > > For additional commands, e-mail: users-h...@maven.apache.org>
> 
> ->
> 
> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org>
> > > > For additional commands, e-mail: users-h...@maven.apache.org>
> > > 
> > > -->
> > > ->
> > > Arnaud H�ritier>
> > > http://aheritier.net>
> > > Mail/GTalk: aheritier AT gmail DOT com>
> > > Twitter/Skype : aheritier>



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

Re: Maven site filter properties with a period

[Hervé BOUTEMY]

there is some doc about this:
http://maven.apache.org/plugins/maven-site-plugin/examples/creating-content.html#Filtering

Regards,

Hervé

Le lundi 16 octobre 2017, 20:22:04 CEST Alex O'Ree a écrit :
> I have some pom defined properties that I'm trying to inject into a maven
> site markdown file. The file is named "test.md.vm" and it's referenced in
> the site descriptor.
> 
>  
> 
> > This property is used to test PDF .vm
> > 
> > project injection. If you can read this in the PDF output, it's
> > working.
> > 
> > This property is used to test PDF .vm project
> > 
> > injection. If you can read this in the PDF output, it's
> > working.
> > 
> > 
> 
> And in the test markdown file has this
> 
> ### User defined properties in the parent pom
> 
> > testProject.property = ${testProject.property}
> > testProjectProperty = ${testProjectProperty}
> 
> I've noticed that pom defined properties containing a period do not resolve
> for some reason. Properties without the dot work just fine.
> 
> 
> Output:
> 
> testProject.property = ${testProject.property}
> 
> > testProjectProperty = This property is used to test PDF .vm project
> > injection. If you can read this in the PDF output, it’s working.
> 
> Am I missing something or this is a plexus configuration injection related
> thing? This also affects the pdf plugin too



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

Re: Maven Docker Images

[Hervé BOUTEMY]

awesome: there is some common practice we should get into

do you know if there some docs somewhere?
I suppose there are some credentials associated to publishing to Dockerhub

Regards,

Hervé

Le vendredi 20 octobre 2017, 11:39:22 CEST Maxim Solodovnik a écrit :
> In this case dockerhub is preferable :)
> 
> On Fri, Oct 20, 2017 at 11:07 AM, Bindul Bhowmik <bindulbhow...@gmail.com>
> 
> wrote:
> > Maxim,
> > 
> > On Thu, Oct 19, 2017 at 7:54 PM, Maxim Solodovnik <solomax...@gmail.com>
> > 
> > wrote:
> > > Hello,
> > > 
> > > here is the place for Apache docker images managed by infra and Apache
> > > projects https://bintray.com/apache/ :)
> > 
> > From what I have seen, while there are 4 projects with docker
> > repositories on bintray, there seem to be a lot more at dockerhub [1].
> > I did a quick search on INFRA JIRA and found that infra has set a few
> > projects up on dockerhub recently [2], for example INFRA-14756 [3] for
> > bookkeeper.
> > 
> > Bindul
> > 
> > [1] https://hub.docker.com/r/apache/
> > [2] https://issues.apache.org/jira/issues/?jql=component%20%
> > 3D%20Docker%20AND%20project%20%3D%20INFRA
> > [3] https://issues.apache.org/jira/browse/INFRA-14756
> > 
> > > On Fri, Oct 20, 2017 at 12:30 AM, Hervé BOUTEMY <herve.bout...@free.fr>
> > > 
> > > wrote:
> > > > great idea
> > > > 
> > > > ok, we need a git repo at ASF
> > > > 
> > > > what else?
> > > > Is there some sort of release process? some sort of source to release?
> > > > 
> > > > Regards,
> > > > 
> > > > Hervé
> > > > 
> > > > Le jeudi 19 octobre 2017, 13:47:45 CEST Mike Drob a écrit :
> > > > > Thanks for the pointer, Carlos! I had searched the archives, but
> > 
> > maybe I
> > 
> > > > > didn't go back far enough.
> > > > > 
> > > > > I think moving these Dockerfiles into an ASF repo would be great for
> > > > 
> > > > their
> > > > 
> > > > > maintainability.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > > Mike
> > > > > 
> > > > > On 2017-10-19 03:50, Carlos Sanchez <c...@apache.org> wrote:
> > > > > > Arnaud is correct, I sent an email to users@ back on Fri, Nov 7,
> > > > 
> > > > 2014,>
> > > > 
> > > > > > 00:23 when I created the image>
> > > > > > 
> > > > > > 
> > > > > > On Thu, Oct 19, 2017, 11:12 Arnaud H�ritier <ah...@gmail.com>
> > 
> > wrote:>
> > 
> > > > > > > These images are kindly managed by a PMC member of our project
> > > > 
> > > > (Carlos)
> > > > 
> > > > > but>
> > > > > 
> > > > > > > yes they aren't managed directly by the project>
> > > > > > > 
> > > > > > > We can easily see with him to improve this IMO.>
> > > > > > > 
> > > > > > > When he started that (several years ago) Docker wasn't what it
> > > > > > > is
> > > > > 
> > > > > nowadays.>
> > > > > 
> > > > > > > With docker being mainstream I agree that we can reconsider
> > 
> > this.>
> > 
> > > > > > > The docker image build/distribution could perhaps be part of our
> > > > > 
> > > > > release>
> > > > > 
> > > > > > > process.>
> > > > > > > 
> > > > > > > WDYT Carlos ?>
> > > > > > > 
> > > > > > > On Thu, Oct 19, 2017 at 4:16 AM, Mike Drob <md...@apache.org>
> > > > 
> > > > wrote:>
> > > > 
> > > > > > > > I guess the natural follow-on question is whether the Maven
> > > > > 
> > > > > community>
> > > > > 
> > > > > > > > would consider publishing an official set of images? Or
> > > > > 
> > > > > alternatively>
> > > > > 
> > > > > > > > whether they should send a takedown notice to protect their
> > 
> > brand
> > 
> > > > > and>
> > > > > 
> > 

Re: How to create a site/doxia plugin?

[Hervé BOUTEMY]

Hi Peter,

IIUC, you want to create a JspWiki parser, to be able to write JspWiki markup 
by hand and let maven-site-plugin parse it to integrate into the html site.

That's it?

Then the sink part is not interesting to you: this would to output JspWiki 
format instead of html.

I fear I did not check this doc when I changed some bits over versions: there 
are probably a few glitches in this doc.
I'll have a look.
In the mean time, just have a look at modules in Doxia itself should help you.

And remember: Parser is what you want to parse JspWiki. Sink is what you don't 
need, to output JspWiki: would be useful only if you want to support JspWiki 
as output in Doxia converter, for example [1]

Regards,

Hervé

[1] https://maven.apache.org/doxia/doxia-tools/doxia-converter/index.html

Le mardi 3 juillet 2018, 10:20:06 CEST Peter Nabbefeld a écrit :
> Hi Hervé,
> 
> sorry for being unspecific - I want some basic support for JspWiki format.
> 
> So far, I found https://maven.apache.org/doxia/developers/modules.html,
> but it's incomplete and outdated ("SinkFactory" was changed into an
> interface, "AbstractSiteModule" seems to no more exist).
> 
> Kind regards
> 
> Peter
> 
> Am 03.07.2018 um 08:14 schrieb Hervé BOUTEMY:
> > Hi Peter,
> > 
> > What do you call a Doxia plugin?
> > 
> > I see misc interpretations:
> > 
> > - a Doxia module [1], to support a new output format = a new Sink, see the
> > currfent modules that provide Sinks (and not only parsers) [2]
> > 
> > - a Skin [3], to have a web site that matches better your intent
> > 
> > - a new Maven plugin that integrates reports in another way than
> > maven-site- plugin and maven-pdf-plugin
> > 
> > Perhaps it's something else: you'll need to describe more precisely what
> > parts you want to reuse and which part you want to extend
> > 
> > Regards,
> > 
> > Hervé
> > 
> > [1] https://maven.apache.org/doxia/overview.html
> > 
> > [2] https://maven.apache.org/doxia/references/index.html
> > 
> > [3] https://maven.apache.org/skins/index.html
> > 
> > Le mardi 3 juillet 2018, 07:30:19 CEST Peter Nabbefeld a écrit :
> >> Thank You, this is really an interesting plugin. But I don't want to
> >> break site generation, as I'm using it for other reports like JavaDoc,
> >> too.
> >> 
> >> I just want to write a doxia plugin, if possible, as all text-based
> >> documentation generators seem to be more or less broken or at least not
> >> able to generate the docs in the way I want.
> >> 
> >> Kind regards
> >> 
> >> Peter
> >> 
> >> Am 02.07.2018 um 14:48 schrieb Mark Raynsford:
> >>> On 2018-07-02T13:55:20 +0200
> >>> 
> >>> Peter Nabbefeld  wrote:
> >>>> Hello,
> >>>> 
> >>>> I haven't ever written a maven plugin. But, as I'm not satisfied with
> >>>> the doxia plugins available, I'd like to write my own. So, how would I
> >>>> have to write a doxia plugin?
> >>> 
> >>> Here's a plugin I wrote last year and still use to the present day:
> >>> https://github.com/io7m/minisite/
> >>> 
> >>> It produces sites that look like this:
> >>> https://www.io7m.com/software/junreachable/
> >>> 
> >>> The com.io7m.minisite.core module is independent of Maven, and the
> >>> com.io7m.minisite.maven_plugin module implements the actual plugin (by
> >>> taking data from the current Maven project and passing it to the core).
> >>> 
> >>> One thing you will need to do is unbind the existing Maven site plugin
> >>> from the lifecycle in any project that actually uses your plugin
> >>> (assuming that you bind your own site plugin to the "site" phase of the
> >>> 
> >>> build). Here's an example of how to do this:
> >>> https://github.com/io7m/primogenitor/blob/develop/pom.xml#L908
> >> 
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org





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

[ANN] Apache Maven Site Plugin 3.7 Released

[Hervé Boutemy]

The Maven team is pleased to announce the release of the Apache Maven Site 
Plugin, version 3.7

The Maven Site Plugin is a plugin that generates a site for the current 
project.

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

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-site-plugin
  3.7


You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/plugins/maven-site-plugin/download.cgi

Release Notes - Maven Site Plugin - Version 3.7

** Bug
* [MSITE-796] - Unable to generate site with JDK9 - 
java.lang.ExceptionInInitializerError / Caused by: 
java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 1

** Improvement
* [MSITE-787] - display what reports are added automatically when no 
reportSet is defined
* [MSITE-791] - upgrade Doxia to 1.8 to benefit from new Markdown parser 
(require Java 7)
* [MSITE-797] - simplify stacktrace in case of report plugin execution 
failure
* [MSITE-804] - update Doxia Site Renderer to 1.8

** Task
* [MSITE-792] - drop reportPlugins parameter ("new format")
* [MSITE-802] - Support more than one directory: improve target/generated-
site documentation
* [MSITE-805] - switch to Git

Enjoy,

-The Apache Maven team

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

Re: Make custom plugin executed only once in multimodule (inherited=false? aggregator?)

[Hervé BOUTEMY]

Hi François,

Happy New Year! 

Can you check in generated META-INF/maven/plugin.xml descriptor that your 
annotation in source was well detected?
Because it looks like a typo somewhere in your plugin: if you can share the 
code (eventually privately), perhaps new eyes can find it.

Regards,

Hervé

Le vendredi 5 janvier 2018, 14:36:07 CET Francois MAROT a écrit :
> [Sorry, re-posting with correct formatting]
> 
> Hi all & happy new year !
> I have a question regarding plugin development.
> 
> I have made a custom plugin and would like to make it's Mojo executed once
> *and only once* in my whole reactor build. If I include it in my parent pom
> (not in pluginManagement), then by default it is executed once at the root
> and once in child-modules.
> 
> Solutions I found out:
> 
> - false used in plugin declaration in pom => it sorta
> do what I want
> BUT my plugin is not executed once if I invoke the maven build directly
> inside a child-module.
> 
> - aggregator = true in the @Mojo annotation => I thought it was THE solution
> but I can't
> seem to understand what it does: despite declaring my mojo an aggregator, it
> is executed in all children.
> 
> -
> http://blog.sonatype.com/2009/05/how-to-make-a-plugin-run-once-during-a-buil
> d/ => the solution given there does not really satisfies me because it means
> Maven WILL call my execute() method more than once, simply my plugin will
> bypass it except at the execution root. We can do better than that can't we
> ?!
> 
> I really can't understand why the aggregator parameter does not work as I
> expected it to.
> Any idea ?
> 
> François
> 
> 
> 
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Users-f40176.html
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

[ANN] Apache Maven Doxia 1.8 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
Doxia, version 1.8 (which will be used in a future 3.7 version of maven-site-
plugin)
 
Doxia is a content generation framework that provides powerful techniques for 
generating static and dynamic content, supporting a variety of markup 
languages.
 
https://maven.apache.org/doxia/doxia/
 
You can download the appropriate sources etc. from the download page:
 
https://maven.apache.org/doxia/doxia/download.cgi

Release Notes - Maven Doxia - Version 1.8

** Bug
* [DOXIA-523] - Ampersands after hash in markdown link syntax are now 
throwing parse errors.
* [DOXIA-543] - maven-doxia-markdown fails in parallel builds
* [DOXIA-546] - DoxiaUtils#encodeId() produces invalid id
* [DOXIA-547] - Upgrade to Maven Parent 30
* [DOXIA-554] - Parsing Markdown documents can hang site generation: 
switch parser from Pegdown to Flexmark
* [DOXIA-559] - Doxia macro fails with markdown headers past level 4
* [DOXIA-564] - avoid numbering TOC entry and fix item numbering which has 
2 dots

** Dependency upgrade
* [DOXIA-566] - Update dependences to latest version

** Improvement
* [DOXIA-504] - Update to latest Plexus Container
* [DOXIA-522] - Make snippet macro less permissive of issues
* [DOXIA-544] - Set document tag on chapter header for FO format
* [DOXIA-550] - Change behavior of HtmlTools#encodeId()
* [DOXIA-553] - Replace pegdown due to deprecation and end of life notice
* [DOXIA-558] - Upgrade to Commons Lang 3
* [DOXIA-565] - improve Doxia document descriptor documentation

** Task
* [DOXIA-541] - Document date() API as *last modified* or *created* date
* [DOXIA-548] - Upgrade Plexus Utils to 3.0.24
* [DOXIA-549] - Deprecate and replace DoxiaUtils#byteToHex() with 
String#format()
* [DOXIA-563] - switch to Git

Enjoy,

-The Apache Maven team

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

Re: sorting versions for artifacts with hypen and / or dot in filename

[Hervé BOUTEMY]

Maven does not use the file name to try to guess artifactId: Maven has 
artifactId in a pom.xml (either as pom.xml coordinates, either as dependency 
coordinates) and when necessary generates a filename to find associated file.

Then there is never any ambiguity when files are in a Maven repository and 
accessed from their coordinates: 2 artifactId have their files in 2 separate 
directories, and 2 versions have also 2 separate directories.

In your case, IIUC, you're having a file outside a Maven repository and you're 
trying to guess its artifactId: that's not a scenario that is happening in 
Maven.

Regards,

Hervé

Le mardi 9 janvier 2018, 00:44:28 CET hanas...@gmail.com a écrit :
> How is the artifact name separated from the version number if the
> artifact has hypens and / or dots in it?  Are they sorted as Strings?
> 
> example:
>   jar1 and the war are two submodules of a parent project
> 
>   G:A:V = org.myorg.project
>   org.myorg.project.jar1 (and a org.myorg.project.war)
>   1.2.3
> 
>   OR
> 
>   G:A:V = org.myproject.project
>   org-myorg-project-jar1 (and a org-myorg-project-war)
>   1.2.3
> 
>   * have also had the discussion of reversing to war-project-myorg.org
>   * above of course would have -SNAPSHOT versions too
> 
> The idea remove ambiguity between artifacts that would otherwise have
> ambiguity in their names.   You might have seen many projects that have
> a core.jar or common.jar  Of course this also is havoc if there are two
> core.jar files, from two different dependent projects, in the web lib
> directory of a WAR file.  Need to be sure that maven and gradle will
> parse correctly and sort versions of x.y.z in the correct order and not
> revert to string ascii sort order.
> 
> Thanks.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

[ANN] Apache Software Foundation Parent POM Version 19 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the 
Apache Software Foundation Parent POM Version 19.

https://maven.apache.org/pom/asf/

You should specify the version in your project as parent like the following:


   org.apache
   apache
   19


You can download the appropriate sources etc. from the download page:

http://maven.apache.org/pom/asf/download.html


Release Notes - Maven POMs - Version ASF-19

** Improvement
* [MPOM-118] - Enforce strong GPG signatures by default
* [MPOM-124] - Text about for default compiler version giving 1.4 which is 
wrong
* [MPOM-129] - Upgrade apache-rat-plugin to 0.12
* [MPOM-130] - Upgrade maven-jar-plugin to version 3.0.2
* [MPOM-131] - Upgrade maven-source-plugin to 3.0.1
* [MPOM-136] - Upgrade maven-resources-plugin to 3.0.1
* [MPOM-137] - Upgrade maven-scm-plugin to 1.9.5
* [MPOM-164] - Require Maven 3.0 to build ASF projects
* [MPOM-169] - Update to latest RAT 0.12

** Task
* [MPOM-132] - assembly plugin should use posix, not gnu for tarLongFileMode
* [MPOM-141] - Upgrade maven-assembly-plugin to 3.0.0.
* [MPOM-142] - Upgrade maven-compiler-plugin to 3.6.0.
* [MPOM-144] - Upgrade maven-javadoc-plugin to 2.10.4.
* [MPOM-146] - Upgrade maven-resources-plugin to 3.0.2.
* [MPOM-147] - Upgrade maven-war-plugin to 3.0.0.
* [MPOM-148] - Upgrade clirr-maven-plugin to 2.8.
* [MPOM-165] - upgrade maven-invoker-plugin to 3.0.1
* [MPOM-166] - upgrade maven-plugin-plugin to 3.5
* [MPOM-170] - migrate to Git

** Dependency upgrade
* [MPOM-173] - Upgrade mave-surefire/failsafe-plugin 2.20.1

Changes since version 18:

https://gitbox.apache.org/repos/asf?p=maven-apache-parent.git;a=blobdiff;f=pom.xml;hb=apache-19;hpb=apache-18
https://github.com/apache/maven-apache-parent/compare/apache-18...apache-19

Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven SCM Publish Plugin 3.0.0 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
SCM Publish Plugin, version 3.0.0

The maven-scm-publish-plugin is a utility plugin to allow publishing Maven 
website to any supported SCM. The primary goal was to have an utility plugin 
to allow Apache projects to publish Maven websites via the ASF svnpubsub 
system.

https://maven.apache.org/plugins/maven-scm-publish-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-scm-publish-plugin
3.0.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-scm-publish-plugin/download.cgi

Release Notes - Maven SCM Publish Plugin - Version 3.0.0

** Bug
* [MSCMPUB-19] - Plugin fails to publish to SCMs whose working copies 
don't have any kind of private storage
* [MSCMPUB-29] - Website still points to jira.codehaus.org

** Improvement
* [MSCMPUB-16] - MavenProject/MavenSession Injection as a parameter 
instead as a component.
* [MSCMPUB-21] - Upgrade maven-scm to 1.9.4
* [MSCMPUB-22] - Upgrade maven-shared-components parent to version 30
* [MSCMPUB-23] - Bump version to 3.0.0-SNAPSHOT
* [MSCMPUB-24] - Upgrade maven-release-manager to 2.5.3
* [MSCMPUB-25] - Upgrade Maven SCM to 1.9.5
* [MSCMPUB-26] - Change scope of maven-plugin-annotations to provided
* [MSCMPUB-32] - improve doc for GitHub gh-pages use in orphan Git branch
* [MSCMPUB-33] - add color output to improve UX
* [MSCMPUB-35] - add support for symbolic links

** Task
* [MSCMPUB-34] - switch to Git

Enjoy,

-The Apache Maven team

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

Re: prevent automatic adaptation of scm connection url

[Hervé BOUTEMY]

see https://issues.apache.org/jira/browse/MNG-6059 for a new feature to avoid 
artifactId addition

the current behaviour is documented in
http://maven.apache.org/ref/3.5.2/maven-model-builder/index.html#Inheritance_Assembly

Regards,

Hervé

Le mardi 6 février 2018, 08:31:50 CET Basin Ilya a écrit :
> Hi list.
> I have a multi-module project. The parent pom has something like:
> 
>   
>   
> scm:git:http://0.0.0.0/dummy/for/buildnumber-maven-plugin.git<
> /connection> 
> 
> Strangely, in the effective pom of submodules the module directory name is
> appended to the urls:
> 
>   
>   
> scm:git:http://0.0.0.0/dummy/for/buildnumber-maven-plugin.git/
> submodule 
> 
> I know it makes sense for SVN, but git urls can't contain subdirs, do they?
> 
> And where is this documented?
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

Re: per-warm the maven cache for 2 stage Docker build

[Hervé BOUTEMY]

Le lundi 19 février 2018, 09:25:13 CET Adam Sandor a écrit :
> Hello Maven people,
> 
> Can someone at least give me some feedback on why this one is not
> getting any answers? Asked the question in a wrong way? Is it not
> clear? Not interesting?
I suppose this is a mix that not many people are fluent with
I'll try to help.

> 
> I think supporting Docker-based builds is very important today. I'm
> thinking of contributing code to solve this issue, but I first want to
> confirm I didn't miss some solution that is already available.
> 
> Adam
> 
> On Sun, Feb 4, 2018 at 12:57 PM, Adam Sandor
> 
>  wrote:
> > I’m trying to figure out how to create a two-stage Docker build using
> > Maven
> > that would properly utilise Docker layer caching. Containing the whole
> > build in a Docker container without external dependencies on volume
> > mounts (for .m2 cache) has a lot of advantages.
> > The only missing piece of the puzzle I can’t figure out is how to force
> > Maven to download ALL dependencies just by using the pom file and not
> > executing any compilation. The idea behind is to:
> > 1. copy the pom file into the image
> > 2. use maven to download all dependencies
> > 3. copy the sources to the image
> > 4. use maven to build the final artifact
> > This way Docker will reuse the layer containing the dependencies if the
> > pom
> > file didn’t change. So dependency caching would be implemented in a
> > Docker-ish way that works anywhere the Docker daemon is present as opposed
> > to relying on Maven being installed and artifacts getting stored in a
> > shared .m2/repository directory.
> > 
> > Now the problem - Maven’s lazy downloading of dependencies. Even if I try
> > to execute “mvn dependency:go-offline” Maven still doesn’t download
> > plugins and other dependencies, which would only be required during the
> > packaging phase.
Maven Dependency Plugin is supposed to download plugins: that's surprising you 
don't get one plugin downloaded.
There is one classical cause I imagine: did you define a version for every 
plugin used?
You should be able to have a diagnostic through "mvn versions:display-plugin-
updates"

Regards,

Hervé


> > So the following Docker file doesn’t work as intended:
> > 
> > FROM maven AS build
> > WORKDIR /build
> > ADD pom.xml /build
> > RUN mvn dependency:go-offline
> > ADD src /build/src
> > RUN mvn -o package
> > FROM openjdk:8-jdk
> > WORKDIR /app
> > COPY --from=build /build/target/app.jar /app
> > CMD java -jar /app/app.jar
> > 
> > Maven will still start downloading more dependencies on line 6.
> > 
> > I found a workaround for this - execute “mvn package” with a single fake
> > main class on line 4, but this is not a nice solution. Can anyone give me
> > some option I’m missing or confirm that this is the way things are? In
> > that
> > case I can go ahead write a blog post showing my workaround to help other
> > struggling with the same problem. Thank you!
> > 
> > Adam Sandor from Container Solutions
> > 
> > 
> > --
> > 
> > Ádám Sándor
> > 
> > Senior Engineer / Consultant
> > 
> > Container Solutions
> > 
> > 0680126174
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org



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

[ANN] Apache Maven PDF Plugin 1.4 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Maven 
PDF Plugin, version 1.4

This plugin allows you to generate a PDF version of your project's 
documentation.

https://maven.apache.org/plugins/maven-pdf-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-pdf-plugin
1.4


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-pdf-plugin/download.cgi

Release Notes - Maven PDF Plugin - Version 1.4

** Bug
* [MPDF-47] - docDescriptors of other locales than default are ignored for 
pdf generation
* [MPDF-59] - In "Table of Contents" the TOC itself is chapter 1, but not 
in the document
* [MPDF-62] - PDF plugin doesn't work with doxia-module-markdown

** Improvement
* [MPDF-48] - make PDF plugin run reports when used with Maven 3
* [MPDF-74] - upgrade Doxia from 1.2 to 1.8
* [MPDF-75] - Fluido Skin
* [MPDF-76] - Maven Parent Version 27
* [MPDF-77] - Remove limitations documentation for Maven 2.0.6
* [MPDF-78] - Compatibility with doxia-module-docbook-simple 1.7
* [MPDF-84] - display pdf generated file location

** Task
* [MPDF-79] - Upgrade of plexus-interpolation to 1.24.
* [MPDF-85] - switch to Git

Enjoy,

-The Apache Maven team

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

[ANN] Apache Maven Doxia Sitetools 1.8 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache  
Maven Doxia Sitetools, version 1.8

Doxia Sitetools is an extension of base Doxia component that generates  
either HTML sites, consisting of decoration and content that was generated  
by Doxia, or documents like RTF or PDF.

In addition, Doxia Sitetools processes files with extra .vm extension with  
Velocity.

https://maven.apache.org/doxia/doxia-sitetools/

You can download the appropriate sources etc. from the download page:

https://maven.apache.org/doxia/doxia-sitetools/download.cgi

Release Notes - Maven Doxia Sitetools - Version 1.8

** Improvement
* [DOXIASITETOOLS-181] - add docRenderingContext to template Velocity 
context
* [DOXIASITETOOLS-182] - create DocumentContent interface to model 
SiteRendererSink output
* [DOXIASITETOOLS-184] - add generator field to document RenderingContext 
to get info on report
* [DOXIASITETOOLS-185] - add helpers to traverse custom skin parameters

** New Feature
* [DOXIASITETOOLS-183] - add edit source feature to document model (base 
url)

** Task
* [DOXIASITETOOLS-180] - switch to Git
* [DOXIASITETOOLS-186] - improve generated html in default template: avoid 
unwanted space

Enjoy,

-The Apache Maven team

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

[ANN] Apache Software Foundation Parent POM Version 21 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Apache Software 
Foundation Parent POM Version 21.

https://maven.apache.org/pom/asf/

You should specify the version in your project as parent like the following:


   org.apache
   apache
   21


You can download the appropriate sources etc. from the download page:

http://maven.apache.org/pom/asf/download.html


Release Notes - Maven POMs - Version ASF-21

** New Feature
* [MPOM-205] - create SHA-512 checksum for source-release archive(s) in 
target/checkout/target/ during release


Changes since version 20:

https://gitbox.apache.org/repos/asf?p=maven-apache-parent.git;a=blobdiff;f=pom.xml;hb=apache-21;hpb=apache-20
https://github.com/apache/maven-apache-parent/compare/apache-20...apache-21

Enjoy,

-The Apache Maven team



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

[ANN] Apache Maven Parent POMs 32 Released

[Hervé Boutemy]

The Apache Maven team is pleased to announce the release of the Maven Parent 
POMs Version 32.
Maven Parent POMs include Maven Parent POM itself, but also Maven Plugins 
Parent POM, Maven Shared Components Parent POM, Maven Skins Parent POM and 
Maven Doxia Tools Parent POM.

https://maven.apache.org/pom/maven/

You should specify the version in your project as parent like the following:


   org.apache.maven
   maven-parent
   32


You can download the appropriate sources etc. from the download page:

http://maven.apache.org/pom/maven/download.html


Release Notes - Maven POMs - Version MAVEN-32

** Improvement
* [MPOM-187] - Add autoVersionSubmodules=true to maven-release-plugin 
configuration
* [MPOM-189] - Ensure that Jenkins will fail when maven-invoker-plugin has 
failures
* [MPOM-190] - Change to https instead of http

** Task
* [MPOM-183] - remove maven-archetype-bundles

** Dependency upgrade
* [MPOM-184] - Upgrade maven-surefire/failsafe to 2.21.0 based on JDK 10 
issues
* [MPOM-188] - maven-invoker-plugin should copy value of https.protocols 
system property during invocation
* [MPOM-193] - Upgrade extra-enforcer-rule to 1.0-beta-9


Changes since version 31:

https://gitbox.apache.org/repos/asf?p=maven-parent.git;a=blobdiff;f=pom.xml;hb=maven-parent-32;hpb=maven-parent-31


Enjoy,

-The Apache Maven team



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