Re: Maven JXR 2.4 site.
update done
Regards,
Hervé
Le mardi 30 septembre 2014 07:39:00 James Nord a écrit :
Sorry don’t know what happened with my mailer there - hadn't finished
writing and wasn't ready for sending.
The re-direct works - but shouldn't it redirect to the plugin page rather
than the top level jxr page?
ie. Would the redirect not be better as
http://maven.apache.org/plugins/maven-jxr-plugin/ -
http://maven.apache.org/jxr/maven-jxr-plugin/
Anyway - thanks for setting this up - will certainly help me in a few months
when I forget about it again :)
/James
I have created a redirect
http://maven.apache.org/plugins/maven-jxr-plugin/ to
http://maven.apache.org/jxr/which should solve the problem...
can you check this...
The redirect works - but it sredirect to the plugin page
(http://maven.apache.org/jxr/maven-jxr-plugin/) rather than the top level
jxr?
/James
B
KK
KKCB [ X ܚX KK[XZ[
\ \ ][ X ܚX PX] [ \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
\ \ Z[ X] [ \X K ܙ B
-
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:deploy hosting providers??
we have scm-publish plugin for that http://maven.apache.org/plugins/maven-scm-publish-plugin/ Regards, Hervé Le samedi 27 septembre 2014 10:09:35 Kevin Burton a écrit : I don't think github would work but would love to be wrong. Their static page hosting is acceptable but it's tricky to make sure all pages get added and removed properly. Their binary hosting uses their own proprietary api which isn't supported by wagon. On Sep 27, 2014 4:49 AM, Jason van Zyl ja...@takari.io wrote: I believe there are tools that will allow you to publish your static site to Github pages. On Sep 27, 2014, at 2:21 AM, Kevin Burton bur...@spinn3r.com wrote: This is such an obviously problem I’m amazed there isn’t an easier solution. Bintray looks cool. I just asked them how they feel about static site hosting? I want something that works with mvn site:deploy On Fri, Sep 26, 2014 at 10:49 PM, Manfred Moser manf...@mosabuam.com wrote: If you just want to have the sites hosted any hosting solution will do it. CDN will be more expensive but I would really wonder if you need that for a static site. You would have to get a LOT of traffic to make it worth it. Bintray focuses on binary distribution and not site hosting. If you want both you could even just run Nexus OSS on any server and host the binaries and the site using a Maven repository for the binaries and a site repository for the site.. manfred Bernd wrote on 26.09.2014 17:41: Have a look at bintray https://bintray.com/docs/uploads/uploads_uploads.html Greetings Bernd Am 26.09.2014 21:39 schrieb Kevin Burton bur...@spinn3r.com: I don’t want to necessarily host our own repositories. They’re just static file repositories. Are there any hosting providers out there that support dav, SCP or HTTP PUT that would work with wagon? Required features are: - SSL - redundant copies on multiple servers (CDN) - dav/scp/ftp/ upload.. anything supported by wagon. - HTTP auth - domain masking … I just want something easy to setup and then never worry about it again. -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - the course of true love never did run smooth ... -- Shakespeare - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: What does it mean when dependency:list and dependency:tree disagree on scope?
probably a bug in dependency:tree dependency:list just displays info directly taken from Maven core: you can trust it dependency:tree does a lot of logic to track resolution, with different implementations for Maven 2, 3.0.x and 3.1+: at the moment, I had a lot of work to be sure that conflicts were well detected, but I never checked scopes (checking conflicts was already a hard task) so please open a bug report for dependency:tree/shared/maven-dependency-tree and we'll need to work back on Maven 3.0.x and 3.1+ implementations Regards, Hervé Le mercredi 24 septembre 2014 10:47:47 Benson Margulies a écrit : I've got a project where (a) we went to a lot of trouble to make sure that log4j was scoped to test, (b) dependency:list shows it as scope=test, (c) dependency:tree shows it as scope=compile, using the most recent dependency plugin and maven 3.0.5. The path to log4j is through slf4j-log4j, which dependency:analyze thinks is 'unused'. here is the confusing output of :tree: +- org.slf4j:slf4j-log4j12:jar:1.6.3:test | \- log4j:log4j:jar:1.2.16:compile - 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 Shared Component: Maven Reporting Implementation version 2.3
The Apache Maven team is pleased to announce the release of the Apache Maven Shared Component: Maven Reporting Implementation, version 2.3 This component provides abstract classes to manage report generation, which can be run both: - as part of a site generation, as a maven-reporting-api's MavenReport, - or as a direct standalone goal invocation, as a maven-plugin-api's Mojo http://maven.apache.org/shared/maven-reporting-impl/ You should specify the dependency in your project's dependency configuration: dependency groupIdorg.apache.maven.shared/groupId artifactIdmaven-reporting-impl/artifactId version2.3/version /dependency Release Notes - Maven Shared Components - Version maven-reporting-impl-2.3 ** Sub-task * [MSHARED-240] - Port maven-reporting-impl to maven-shared-utils ** Bug * [MSHARED-328] - use @parameter default-value instead of @parameter expression in sample * [MSHARED-346] - missing properties usually set by m-site-p (outputEncoding, ...) ** Improvement * [MSHARED-348] - support reporting encoding configuration when used as goal ** New Feature * [MSHARED-347] - use plugin-tools java 5 annotations to avoid fields copy/paste when implementing 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 Checkstyle Plugin 2.13 Released
The Apache Maven team is pleased to announce the release of the Apache Maven
Checkstyle Plugin, version 2.13
This plugin generates a report regarding the code style used by the
developers.
http://maven.apache.org/plugins/maven-checkstyle-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
version2.13/version
/plugin
Release Notes - Maven Checkstyle Plugin - Version 2.13
** Bug
* [MCHECKSTYLE-126] - Generated HTML page contains
charset=${outputEncoding}
* [MCHECKSTYLE-214] - Resources retrieval ignores resources definition in
build
* [MCHECKSTYLE-225] - headerLocation no longer sets checkstyle.header.file
* [MCHECKSTYLE-230] - ConcurrentModificationException in
FileResourceLoader.getResource
* [MCHECKSTYLE-237] - Changeset 1608113 introduces Line 0 regression
* [MCHECKSTYLE-238] - ConcurrentModificationException
* [MCHECKSTYLE-244] - LicenseResourceManager component is not thread safe
and causes parallel build failures
** Improvement
* [MCHECKSTYLE-70] - Support for multiple source folders
* [MCHECKSTYLE-148] - Would be nice to see the name of CHECK together with
its output
* [MCHECKSTYLE-215] - Abandon sourceDirectory and testSourceDirectory for
MavenProject#getCompileSourceRoots
* [MCHECKSTYLE-217] - Add parameter which skips rule rows which do not
have any violations
* [MCHECKSTYLE-232] - add the version of Checkstyle to the generated
report
* [MCHECKSTYLE-233] - link to rules documentation
* [MCHECKSTYLE-234] - group rules by category
* [MCHECKSTYLE-235] - improve difference between rules with and without
violations
* [MCHECKSTYLE-236] - add Rule name to violation message
** New Feature
* [MCHECKSTYLE-242] - fine grained ignore of violations
** Task
* [MCHECKSTYLE-248] - Remove RegexBasedInterpolator and ValueSource
** Wish
* [MCHECKSTYLE-239] - remove Translation rule from Maven checks
* [MCHECKSTYLE-240] - add 17, 31 and 37 to ignored MagicNumber
* [MCHECKSTYLE-241] - add SuppressWarningsFilter (introduced in Checkstyle
5.7) to support @SuppressWarnings
* [MCHECKSTYLE-243] - log check violations to console by default
* [MCHECKSTYLE-246] - add UniqueProperties rule (introduced in Checkstyle
5.7)
* [MCHECKSTYLE-247] - add CHECKSTYLE_OFF/ON: regexp support
(SuppressionCommentFilter)
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: Unable to create markdown doxia… files just ignored.
yes, you should remove this explicit module FYI, you can't use Doxia Markdown 1.5 with m-site-p that uses Doxia 1.6 natively: there was a little refactoring in Doxia 1.6 that is backward compatible (you can use new parsers with old Doxia core) but not forward compatible (you cannot use old parsers with new Doxia core) see http://jira.codehaus.org/browse/DOXIA-510 if you're interested in internals (and this change is about helping new people understand the code, then contribute: yes, we need people's contribution) Regards, Hervé Le mardi 2 septembre 2014 19:44:44 Dan Tran a écrit : Remove doxia for markdown, it already included -D On Tuesday, September 2, 2014, Kevin Burton bur...@spinn3r.com wrote: I’m trying to create a static site using doxia and the markdown plugin and it seems to be failing. Basically, apt and xdocs works, but markdown doesn’t. I’m using the markdown plugin: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.4/version dependencies dependency groupIdorg.apache.maven.doxia/groupId artifactIddoxia-module-markdown/artifactId version1.5/version /dependency /dependencies /plugin … and then run mvn site … but no markdown files are picked up. If I use xdocs or apt they work just fine. I’m placing my files in src/site/markdown and they have .md extensions. … anything else I should try? is there a debug mode? -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Debugging duplicate phase executions ...
ok: it's good to have a workaround I'm interested in working on a real world scenario, without multi- module/aggregate, since aggregate will be a harder case do you have something public to show the problem? Regards, Hervé Le samedi 23 août 2014 07:38:47 Michael Norman a écrit : For now, I have solved our problem of duplicate phase execution by commenting-out the reporting stanza's of our pom file. Everything we need is produced by goals other than 'site' - except findbugs. For that, we are now making an explicit call to 'findbugs:check' (bound to 'verify') which doesn't seem to have the 'forked-duplication' problem. All of our reports are being generated post-build by Jenkins, so everything is working. Thanks, Mike On Fri, Aug 22, 2014 at 8:25 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: - use Maven 3.2.2 at least: MNG-5630 will really help you understand - if not possible, use m-site-p 3.4: MSHARED-333 does something quite equivalent and doesn't require a specific Maven version and you can read MJAVADOC-171, where I managed to analyze the problem (quite recently...) and explained it as much as possible in summary, there is a problem with forked lifecycles launched by plugins executed from m-site-p (which gets even bigger when run in aggregated mode): I now understand the problem, given previous analysis (which took me a few years of thinking/trying/...), but I still didn't have time to work on a fix If you're interested on working with me on this, I'll be happy to have someone with me Regards, Hervé Le jeudi 21 août 2014 22:53:03 Michael Norman a écrit : I have a simple Maven project (a web-app) that uses the ' frontend-maven-plugin' to handle various Javascript-related chores (installing node, running Grunt, Karma etc.) Unfortunately, the frontend stuff runs twice on a 'mvn clean site' command - when I turned on debug-output (in Eclipse) I can see the reactor list 2 calls to the frontend plugin. Is there any techniques or help anyone can suggest to try to figure out what is causing the extra execution? Thanks in advance, --- Mike Norman - 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: Debugging duplicate phase executions ...
- use Maven 3.2.2 at least: MNG-5630 will really help you understand - if not possible, use m-site-p 3.4: MSHARED-333 does something quite equivalent and doesn't require a specific Maven version and you can read MJAVADOC-171, where I managed to analyze the problem (quite recently...) and explained it as much as possible in summary, there is a problem with forked lifecycles launched by plugins executed from m-site-p (which gets even bigger when run in aggregated mode): I now understand the problem, given previous analysis (which took me a few years of thinking/trying/...), but I still didn't have time to work on a fix If you're interested on working with me on this, I'll be happy to have someone with me Regards, Hervé Le jeudi 21 août 2014 22:53:03 Michael Norman a écrit : I have a simple Maven project (a web-app) that uses the ' frontend-maven-plugin' to handle various Javascript-related chores (installing node, running Grunt, Karma etc.) Unfortunately, the frontend stuff runs twice on a 'mvn clean site' command - when I turned on debug-output (in Eclipse) I can see the reactor list 2 calls to the frontend plugin. Is there any techniques or help anyone can suggest to try to figure out what is causing the extra execution? Thanks in advance, --- Mike Norman - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: hi, I just want to get help about maven archetype,please help me
Le mercredi 20 août 2014 10:57:48 TOM a écrit :
yeah, it works! __artifactId__ and __rootArtifactId__ all works well
but this way bring a new little problem: my archetype is come from a
demo project using archetype:create-from-project,now i get a archetype
and change some directory's name to __artifactId__,later i want to make
some tuning on the demo project and call mvn
archetype:create-from-project again, then i have to rename those
directory's name again.
do you have any suggestions ? why not the archetype plugin put the java
sources into right path directly?
one generated with create-from-project, the result is supposed to be
maintained as primary source: that's the actual idea behind archetype
so there is no such magic mecanism to detect some parts that could be
generated in a more appropriate fashion
perhaps such a feature, to detect a directory corresponding to artifactId,
could be added: don't hesitate to open a Jira issue and work on a patch
Regards,
Hervé
在 2014-08-18 19:25, Hervé BOUTEMY 写道:
ah ok
so you don't need a custom plugin to add artifactId: just put content in a
directory named __artifactId__
see
http://stackoverflow.com/questions/6378589/how-to-rename-a-directory-with
-the-artifactid-when-using-a-maven-archetype
Regards,
Hervé
Le lundi 18 août 2014 17:00:36 TOM a écrit :
i think i got it,i debuged archetype:generate and found code like this
DefaultFilesetArchetypeGenerator.java
private File getOutputFile( String template, String directory, File
outputDirectoryFile, boolean packaged,
String packageName, String
moduleOffset, Context context )
{
String templateName = StringUtils.replaceOnce( template,
directory, );
String outputFileName =
directory + / + ( packaged ? getPackageAsDirectory(
packageName ) : ) + / + templateName.substring(
moduleOffset.length() );
if ( TOKEN_PATTERN.matcher( outputFileName ).matches() )
{
outputFileName = replaceFilenameTokens( outputFileName,
context );
}
return new File( outputDirectoryFile, outputFileName );
}
so maybe archetype plugin doesn't intend deal with the artifactId in the
path,am i right?
i wrote a plugin to adjust file path myself
在 2014-08-18 15:54, Hervé BOUTEMY 写道:
ok, need to investigate
can you create a Jira issue and attach an example project?
Regards,
Hervé
Le lundi 18 août 2014 10:01:16 TOM a écrit :
thank you ,but my descriptor already is packaged= true
fileSet filtered=true packaged=true encoding=UTF-8
directorysrc/main/java/directory
includes
include**/*.java/include
/includes
/fileSet
在 2014-08-18 0:10, Hervé BOUTEMY 写道:
use packaged=true [1]
Regards,
Hervé
[1]
http://maven.apache.org/archetype/archetype-models/archetype-descripto
r/
a
rchetype-descriptor.html
Le mardi 12 août 2014 16:58:53 TOM a écrit :
I use mvn archetype:create-from-project to generate a archetype
project.
and use it to generate a project
the content of archetype file UserDTO(generaged by
archetype:create-from-project)
package ${package}.${artifactId}.dto;
then i mvn archetype:generate -DarchetypeArtifactId=myapp
-DgroupId=test
-DartifactId=good
then the generated UserDTO with correct package(package
test.good.dto),
but it is in src/main/java/test/dto , not expected
src/main/java/test/good/dto
please help me and thank a lot
-
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
-
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 Eclipse Editor Plugin problem with snippet macro
Le mardi 19 août 2014 15:28:40 Robert Munteanu a écrit : On Sun, Aug 17, 2014 at 8:47 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: , at least for the eclipse+java+maven environment we're using. but you're right, I didn't find a good one as Eclipse plugin either and even not as native application on Linux Mylyn Docs should have a good markdown editor, I've used it occasionally. IIRC it's part of the main Mylyn update site. http://eclipse.org/mylyn Robert I just discovered that Eclipse Luna was able to open *.md files without me adding any plugin: and yes, it's WikiText, and the editor seems decent, even if help on markup syntax is missing (I'm not a markdown guru...). And yes, it's Mylyn Docs' WikiText [1] so my comment on Markdown editor on Eclipse is now outdated Thank you Robert for pointing this out Regards, Hervé [1] https://www.eclipse.org/mylyn/new/new-3.9.html#wikitext - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Not Generating JavaDoc
this is not reporting but reportPlugins
but in fact, you should not use this but use standard pom's reporting section
instead of m-site-p configuration: see
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Configuration_formats
Regards,
Hervé
Le mardi 19 août 2014 14:42:37 SEAN MCELROY a écrit :
Hello,
I am using maven 3.1.1 and I can get the maven-site-plugin to generate any
java doc. The javadoc plugin works fine on it's own. I've tried all sorts
of different configurations but haven't managed to generate and javadoc.
Here is my current configuration. All help appreciated.
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.4/version
configuration
reporting
excludeDefaultstrue/excludeDefaults
outputDirectory${project.build.directory}/site/outputDirectory
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
version2.7/version
configuration
dependencyDetailsEnabledfalse/dependencyDetailsEnabled
dependencyLocationsEnabledfalse/dependencyLocationsEnabled
/configuration
reportSets
reportSet
reports
reportdependencies/report
reportscm/report
/reports
/reportSet
/reportSets
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.9/version
configuration
outputDirectory${project.build.directory}/javadoc/outputDirectory
reportOutputDirectory${project.reporting.outputDirectory}/javadoc/report
OutputDirectory /configuration
/plugin
/plugins
/reporting
/configuration
/plugin
/plugins
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: hi, I just want to get help about maven archetype,please help me
ok, need to investigate
can you create a Jira issue and attach an example project?
Regards,
Hervé
Le lundi 18 août 2014 10:01:16 TOM a écrit :
thank you ,but my descriptor already is packaged= true
fileSet filtered=true packaged=true encoding=UTF-8
directorysrc/main/java/directory
includes
include**/*.java/include
/includes
/fileSet
在 2014-08-18 0:10, Hervé BOUTEMY 写道:
use packaged=true [1]
Regards,
Hervé
[1]
http://maven.apache.org/archetype/archetype-models/archetype-descriptor/a
rchetype-descriptor.html
Le mardi 12 août 2014 16:58:53 TOM a écrit :
I use mvn archetype:create-from-project to generate a archetype project.
and use it to generate a project
the content of archetype file UserDTO(generaged by
archetype:create-from-project)
package ${package}.${artifactId}.dto;
then i mvn archetype:generate -DarchetypeArtifactId=myapp -DgroupId=test
-DartifactId=good
then the generated UserDTO with correct package(package test.good.dto),
but it is in src/main/java/test/dto , not expected
src/main/java/test/good/dto
please help me and thank a lot
-
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: hi, I just want to get help about maven archetype,please help me
ah ok
so you don't need a custom plugin to add artifactId: just put content in a
directory named __artifactId__
see
http://stackoverflow.com/questions/6378589/how-to-rename-a-directory-with-the-artifactid-when-using-a-maven-archetype
Regards,
Hervé
Le lundi 18 août 2014 17:00:36 TOM a écrit :
i think i got it,i debuged archetype:generate and found code like this
DefaultFilesetArchetypeGenerator.java
private File getOutputFile( String template, String directory, File
outputDirectoryFile, boolean packaged,
String packageName, String
moduleOffset, Context context )
{
String templateName = StringUtils.replaceOnce( template,
directory, );
String outputFileName =
directory + / + ( packaged ? getPackageAsDirectory(
packageName ) : ) + / + templateName.substring(
moduleOffset.length() );
if ( TOKEN_PATTERN.matcher( outputFileName ).matches() )
{
outputFileName = replaceFilenameTokens( outputFileName,
context );
}
return new File( outputDirectoryFile, outputFileName );
}
so maybe archetype plugin doesn't intend deal with the artifactId in the
path,am i right?
i wrote a plugin to adjust file path myself
在 2014-08-18 15:54, Hervé BOUTEMY 写道:
ok, need to investigate
can you create a Jira issue and attach an example project?
Regards,
Hervé
Le lundi 18 août 2014 10:01:16 TOM a écrit :
thank you ,but my descriptor already is packaged= true
fileSet filtered=true packaged=true encoding=UTF-8
directorysrc/main/java/directory
includes
include**/*.java/include
/includes
/fileSet
在 2014-08-18 0:10, Hervé BOUTEMY 写道:
use packaged=true [1]
Regards,
Hervé
[1]
http://maven.apache.org/archetype/archetype-models/archetype-descriptor/
a
rchetype-descriptor.html
Le mardi 12 août 2014 16:58:53 TOM a écrit :
I use mvn archetype:create-from-project to generate a archetype
project.
and use it to generate a project
the content of archetype file UserDTO(generaged by
archetype:create-from-project)
package ${package}.${artifactId}.dto;
then i mvn archetype:generate -DarchetypeArtifactId=myapp
-DgroupId=test
-DartifactId=good
then the generated UserDTO with correct package(package test.good.dto),
but it is in src/main/java/test/dto , not expected
src/main/java/test/good/dto
please help me and thank a lot
-
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
-
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: Plugins to extend the APT format? (For use with the Maven Site plugin)
Le mercredi 13 août 2014 23:22:52 Nick Burch a écrit : Hi All For Apache Tika, we currently use the Maven Site plugin, along with the APT format for our site content. We are looking to automatically pull in snippets of code from svn into the published site, much as the ASF CMS supports https://blogs.apache.org/infra/entry/scaling_down_the_cms_to I'm fairly happy about how to do the snippet-fetching part, what's stumping me is finding an example plugin to allow the Maven Site plugin to process additional kinds of markup in the APT format. extending the markup, ie the syntax? Not possible: each supported markup language supported by Doxia is a done through a parser, and i don't know any parser that has such extension points (and I don't kow how this would be feasible) (Or failing that, any other simple-ish Maven Site plugin supported formats like Markdown) there is a external Doxia extension which support including a snippet in another markup language: see Doxia :: Include Macro, http://doxia-include.sourceforge.net/ Could anyone point me to an example for extending one of the formats like this? the only generic extension solution for Doxia is macros (and IIRC, not available in each markup language): see http://maven.apache.org/doxia/macros/index.html Regards, Hervé Thanks Nick - 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: hi, I just want to get help about maven archetype,please help me
use packaged=true [1]
Regards,
Hervé
[1]
http://maven.apache.org/archetype/archetype-models/archetype-descriptor/archetype-descriptor.html
Le mardi 12 août 2014 16:58:53 TOM a écrit :
I use mvn archetype:create-from-project to generate a archetype project.
and use it to generate a project
the content of archetype file UserDTO(generaged by
archetype:create-from-project)
package ${package}.${artifactId}.dto;
then i mvn archetype:generate -DarchetypeArtifactId=myapp -DgroupId=test
-DartifactId=good
then the generated UserDTO with correct package(package test.good.dto),
but it is in src/main/java/test/dto , not expected
src/main/java/test/good/dto
please help me and thank a lot
-
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 Eclipse Editor Plugin problem with snippet macro
notice this is referenced as DOXIA-373 [1] and used in DOXIATOOLS-15 [2]
notice that you should:
- avoid ${basedir} and prefer ${project.basedir}
- not need the property in pom
Regards,
Hervé
[1] http://jira.codehaus.org/browse/DOXIA-373
[2] http://jira.codehaus.org/browse/DOXIATOOLS-15
Le vendredi 15 août 2014 16:26:48 Pablo León a écrit :
Ouch, bad news! This plugin has saved us hundreds of hours in APT format
validation and also is a great memory saver. What are my alternatives
for APT editing?
Nevertheless, I've found a workaround for the problem I was facing, just
in case someone else is experiencing it too:
1.- Rename your APT file from file.apt to file.apt.vm, this seems to
activate the preprocessor on maven.
2.- Add this to the properties section of your pom file:
basedir${basedir}/basedir
3.- Use the snippet macro as follows:
%{snippet|file=$basedir/src/path/to/file.txt}
Now your macros are correctly recognized by maven and by the eclipse plugin!
Regards,
Pablo.
El 15/08/2014 14:30, Benson Margulies escribió:
I made an official release once, I think, but since I no longer use
Eclipse I am not in a position to maintain it further.
On Fri, Aug 15, 2014 at 2:56 AM, Dan Tran dant...@gmail.com wrote:
Unfortunately, I dont think Doxia for Eclipse is maintained, and it never
have an official release either
-D
On Thu, Aug 14, 2014 at 6:06 PM, Pablo León pablo.l...@horus.es wrote:
Hi,
I have been successfully using the Doxia Eclipse Editor Plugin for a few
months. But now I'm facing a compatibility problem related to the
snippet
macro. if I use the following macro:
%{snippet|file=${basedir}/src/path/to/file.txt}
then the mvn site issues the error:
Error during retrieving content skip as ignoreDownloadError
activated.
If I remove the ${basedir} variable from the macro, the mvn site works
as expected, but then I get this error in the eclipse IDE:
Doxia Converter Exception:
C:\eclipse\install\dir\src\path\to\file.txt
(path not found)
I'm unable to specify the path of the snippet file in a compatible
manner,
I have tried using $basedir, ${basedir} and ${project.basedir}, but I
always get the same results.
Anyone has any suggestion?
There are any plans to release an update of the Doxia Eclipse Editor
Plugin which uses the same default directory as the mvn site command?
Regards,
Pablo.
-
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 Eclipse Editor Plugin problem with snippet macro
Le samedi 16 août 2014 15:08:53 Pablo León a écrit : I've been messing around with markdown for a while, and I feel that APT tools are more mature if you know of other tools, please share: AFAIK, Doxia Eclipse Editor was written because we didn't find any tooling (ne it in Eclipse or not) than markdown's (or asciidoc's) if you search for Markdown editor in Google, you'll find a lot of tools , at least for the eclipse+java+maven environment we're using. but you're right, I didn't find a good one as Eclipse plugin either and even not as native application on Linux and notice that asciidoc isn't even supported by Doxia, and nobody seems interested in writing an asciidoc parser for Doxia Despite of some flaws, Benson's editor is more feature rich than the markdown counterpartner. We didn't have anybody work on Markdown extension for Doxia Eclipse plugin (which suports apt, xdoc, ...) And as Borrie noticed, APT is also better integrated with maven. Markdown is as much integrated with Maven than APT but not integrated with Eclipse... So, is there some definitive advantage of markdown over APT that I'm missing? definitely more people know Markdown and do tooling for that: I don't like it, but that's a fact I would like to help with the APT eclipse plugin, but unfortunately I don't have any experience with eclipse plugin development. that's our problem: nobody to continue the work (and even try), and since it's OSS, that means no progress Regards, Hervé Cheers, P. El 16/08/2014 8:52, Dan Tran escribió: Barrie, you are correct. I missed that totally On Fri, Aug 15, 2014 at 9:18 PM, Barrie Treloar baerr...@gmail.com wrote: On 16 August 2014 00:49, Dan Tran dant...@gmail.com wrote: Markdown is the way to go, there is a conversion as well [1] How do you use snippets in Markdown? http://daringfireball.net/projects/markdown/syntax doesn't have anything mentioned. Is it under different terminology? - 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: testing-harness plugin: LocalRepositoryManager is not set
Le jeudi 24 juillet 2014 12:05:37 Barrie Treloar a écrit : On 24 July 2014 01:08, Vincent Zurczak vincent.zurc...@linagora.com wrote: Hi, I am not sure this is the right mailing-list. Maybe I should have posted to the dev list. Anyway... I have started working on new Maven plug-in last week and I have set up unit tests using the testing-harness plugin. I have problems with Maven injected fields, such as the Maven project. Here will do, the devs are on both. (and you will have to wait for someone with more knowledge about using the testing harnesses) Back when I was trying to use them you had a choice of 3, I think its not down to one but I dont know if the documentation on how to set it up and use it is readily available. yes, the 3 are still available, even if 2 options have been removed from front page you can see the previous fonrt page in history [1], and the modules are still availabe (and can be seen from modules report, even if not written down in front page) Regards, Hervé [1] http://maven.apache.org/plugin-testing-archives/3.1.0/ When you get your answers, would you add to the knowledge base? It is always good to get fresh eyes on these things as the people who already know what's going on make assumptions that someone just starting out need to know about. - 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.4 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Site Plugin, version 3.4 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/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.4/version /plugin Release Notes - Maven Site Plugin - Version 3.4 ** Bug * [MSITE-121] - Generated html files contain inconsistent new lines * [MSITE-665] - Site plugin version 3.2 seems to modify a project's classpath. * [MSITE-716] - update doxia-integration-tools to 1.6 * [MSITE-718] - upgrade Doxia base to 1.6 * [MSITE-719] - upgrade Doxia Site Tools to 1.6 ** Improvement * [MSITE-454] - Don't use aggregator mojos for default report set * [MSITE-516] - reportPlugins should/could inherit more information from pluginManagement * [MSITE-711] - add report's goal name to output * [MSITE-713] - improve Error during page generation error message * [MSITE-714] - display statistics about Doxia documents rendered * [MSITE-720] - upgrade maven-reporting-exec to 1.2 * [MSITE-722] - align display info on executed reports ** Task * [MSITE-715] - refactor: split Mojos in sub-packages 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 Doxia base and Doxia Site Tools 1.6 Released
The Apache Maven team is pleased to announce the release of the Apache Doxia base and Doxia Site Tools 1.6, version 1.6 Doxia is a content generation framework that provides powerful techniques for generating static and dynamic content, supporting a variety of markup languages. Doxia Site Tools is an extension of base Doxia component that generates either sites, consisting of decoration and content that was generated by Doxia, or documents like RTF or PDF. http://maven.apache.org/doxia/doxia/ http://maven.apache.org/doxia/doxia-sitetools/ Release Notes - Maven Doxia base - Version 1.6 ** Bug * [DOXIA-386] - Snippet Macro: Reference file does not support UTF-8 file format to generate the page garbage * [DOXIA-503] - Plexus components cannot be abstract classes * [DOXIA-509] - Multi-markdown metadata is too greedy * [DOXIA-515] - div elements in markdown html block content are silently swallowed ** Improvement * [DOXIA-510] - create parser.module equivalent to module.site ** Task * [DOXIA-514] - Prepare unittests for JDK8 Release Notes - Maven Doxia Sitetools - Version 1.6 ** Bug * [DOXIASITETOOLS-76] - Missing inheritance of 'googleAdSenseClient', 'googleAdSenseSlot' and 'googleAnalyticsAccountId' elements. * [DOXIASITETOOLS-87] - inconsistent newlines between template content from skin and generated content * [DOXIASITETOOLS-91] - Section title anchors are not at a good place in generated HTML ** Improvement * [DOXIASITETOOLS-84] - move o.a.m.doxia.sink.render.RenderingContext from Doxia core to Doxia Site Renderer * [DOXIASITETOOLS-85] - move RenderingContext from o.a.m.doxia.sink.render package to o.a.m.doxia.siterenderer * [DOXIASITETOOLS-86] - Use a linguisticly proper separator between project name and doc title in HTML title ** New Feature * [DOXIASITETOOLS-90] - site inheritance controllable 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: Corrupted download mirror?
Le vendredi 27 juin 2014 07:25:08 Jason van Zyl a écrit : I've never seen those mirrors before. The Apache Maven PMC is a aware of and collaborate with Sonatype on the canonical Maven Central and collectively we would assert the content is valid. Anything else and you're on your own. I honestly wouldn't use those mirrors. Maven Central is currently served using a CDN which generally has edges not too far away from you. -1 apache.igor.onlinedirect.bg is an official Apache mirror [1] so this is an official source to download Maven I just tried and didn't have any problem: perhaps there was a synchronization issue in any case, you sould take time to check signature to verify nothing has been damaged Regards, Hervé [1] http://www.apache.org/mirrors/#bg On Jun 25, 2014, at 7:04 AM, Kristiyan Marinov kristiy...@gmail.com wrote: Hi all, I had to download a few different Maven versions today and noticed that each time I downloaded a binary distribution from the http://apache.igor.onlinedirect.bg/ mirror Google Chrome rejected it as a malicious file. Switching the mirror to http://apache.cbox.biz/ produced no such complaints from Chrome. Has anyone else noticed such issues? Could there be something wrong with the mirror? Cheers, Kristiyan Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Corrupted download mirror?
Le vendredi 27 juin 2014 17:36:17 Jason van Zyl a écrit : On Jun 27, 2014, at 4:11 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: Le vendredi 27 juin 2014 07:25:08 Jason van Zyl a écrit : I've never seen those mirrors before. The Apache Maven PMC is a aware of and collaborate with Sonatype on the canonical Maven Central and collectively we would assert the content is valid. Anything else and you're on your own. I honestly wouldn't use those mirrors. Maven Central is currently served using a CDN which generally has edges not too far away from you. -1 Really? Do you check the other mirrors? I don't think any of us do? We should but we don't as far as I know. If it's an official mirror then what's the standard? If someone goes Hey, I want to be a mirror and we call them an official mirror and they fill it with malicious artifacts we would be none the wiser. it's ASF mirror, with ASF policy, that works for more than Apache Maven I at least know what happens with the current Maven Central machines, and I'm reasonably assured of the security. Note I'm not affiliated with Sonatype anymore, I just know they have a good IT staff. notice I'm affiliated with ASF and I know they have a good IT staff too: that does not mean that other organization don't have good IT staff But since it's Apache Maven, as member of Maven PMC, I just need to remember users that Apache dist area (with its mirrors) is the official Apache distribution area for any Apache project I know we have another good distribution space with central So I stand by my claim that I would not use anything but the primary because there is no vetting process whatsoever. yes: primary = Apache dist (which contains signatures to check against to be sure that nothing wrong happened) Regards, Hervé apache.igor.onlinedirect.bg is an official Apache mirror [1] so this is an official source to download Maven I just tried and didn't have any problem: perhaps there was a synchronization issue in any case, you sould take time to check signature to verify nothing has been damaged Regards, Hervé [1] http://www.apache.org/mirrors/#bg On Jun 25, 2014, at 7:04 AM, Kristiyan Marinov kristiy...@gmail.com wrote: Hi all, I had to download a few different Maven versions today and noticed that each time I downloaded a binary distribution from the http://apache.igor.onlinedirect.bg/ mirror Google Chrome rejected it as a malicious file. Switching the mirror to http://apache.cbox.biz/ produced no such complaints from Chrome. Has anyone else noticed such issues? Could there be something wrong with the mirror? Cheers, Kristiyan Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Breadcrumb inheritance in site.xml
Benson, is it still a feature you need? Seems to be done in Doxia Integration Tools. Plase tell me: 1. if you need it: please open a Jira issue 2. if you want to code it or me to do it I want to release maven-site-plugin 3.4, which has a lot of dependencies to release, including Doxia integration Tools: so I need to know. notice inherit attribute name is perhaps not a good choice, since we have inherited in POM's plugin executions to tell that the actual config should not be propagated to childs, which is different from child deciding not to inherit from parent any idea on a good naming welcome Regards, Hervé Le samedi 14 juin 2014 21:19:53 Hervé BOUTEMY a écrit : yes, seems a good idea: project name=.. inherit=false http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decorat ion.html tell me if you need help Regards, Hervé Le samedi 14 juin 2014 14:52:12 Benson Margulies a écrit : What do you think of an element in site.xml that turns off all inheritance? The case I'm dealing with is a project that wants to inherit build stuff from a parent but not site stuff. I'll tackle this if you think it's reasonable. On Sat, Jun 14, 2014 at 12:58 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: you can't inherit nothing with what has beed coded in MSITE-582: the top breadcrumb will always be there if you really need to drop absolutely everything, we need a new feature notice there are a lot of new features in maven-site-plugin 3.4-SNAPSHOT, waiting for a release (with Doxia, Doxia Sitetool and reporting-exec) so that's a good time for a new feature: it could go in the release train Regards, Hervé Le samedi 14 juin 2014 10:21:36 Benson Margulies a écrit : I think it could go in the site plugin doc; I'm willing to do some writing. Even after reading the JIRA, I don't know how to express, I don't want to inherit any breadcrumbs at all all. On Fri, Jun 13, 2014 at 2:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: true that there isn't much doc on this any idea on how/where to document this site.xml inheritence is welcome Regards, Hervé Le jeudi 12 juin 2014 09:14:06 Andreas Sewe a écrit : Hi, that wasn't possible during my time of activity, not sure if anything changed since: http://mail-archives.apache.org/mod_mbox/maven-users/201104.mbox/% 3C 4DA 464 c8.2060...@apache.org%3E yes, https://jira.codehaus.org/browse/MSITE-582 got fixed and I have used the fix successfully in one of my projects. Best wishes, Andreas - 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 - 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: Forking based on skipped execution
Hello, Yes, it's expected behaviour: forking happens when preparing the plugin, before running report generation. Skip happens at the beginning of report generation, just to not do it. Notice the situation will get better with m-site-p 3.4, with http://jira.codehaus.org/browse/MSITE-454 fixed (and see related issues, particularly MJAVADOC-171 with precise figures about the problem across different versions of plugins): the count of forked execution caused by aggregated poms will reduce Regards, Hervé Le lundi 16 juin 2014 12:20:05 Maxim Solodovnik a écrit : Hello All, I'm currently observing weird behavior I'm executing javadoc plugin (goals: javadoc, aggregate) during my build which provokes forking. That is expected Now I'm skipping execution of javadoc (using skiptrue/skip but, surprisingly, Forking still happens :( Maybe anyone knows if it is expected behavior or not? Maybe there are workarounds for this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Forking based on skipped execution
Le lundi 16 juin 2014 13:19:59 Maxim Solodovnik a écrit : Thanks a lot! Maybe you know what time 3.4 will be released? I should be doing it if a few weeks: I have still a few improvements I want to do before releasing OFF maybe you know is there any way to get JIRA account to Vote/Watch issues? https://xircles.codehaus.org/signup Regards, Hervé On 16 June 2014 13:09, Hervé BOUTEMY herve.bout...@free.fr wrote: Hello, Yes, it's expected behaviour: forking happens when preparing the plugin, before running report generation. Skip happens at the beginning of report generation, just to not do it. Notice the situation will get better with m-site-p 3.4, with http://jira.codehaus.org/browse/MSITE-454 fixed (and see related issues, particularly MJAVADOC-171 with precise figures about the problem across different versions of plugins): the count of forked execution caused by aggregated poms will reduce Regards, Hervé Le lundi 16 juin 2014 12:20:05 Maxim Solodovnik a écrit : Hello All, I'm currently observing weird behavior I'm executing javadoc plugin (goals: javadoc, aggregate) during my build which provokes forking. That is expected Now I'm skipping execution of javadoc (using skiptrue/skip but, surprisingly, Forking still happens :( Maybe anyone knows if it is expected behavior or not? Maybe there are workarounds for this? - 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: Breadcrumb inheritance in site.xml
you can't inherit nothing with what has beed coded in MSITE-582: the top breadcrumb will always be there if you really need to drop absolutely everything, we need a new feature notice there are a lot of new features in maven-site-plugin 3.4-SNAPSHOT, waiting for a release (with Doxia, Doxia Sitetool and reporting-exec) so that's a good time for a new feature: it could go in the release train Regards, Hervé Le samedi 14 juin 2014 10:21:36 Benson Margulies a écrit : I think it could go in the site plugin doc; I'm willing to do some writing. Even after reading the JIRA, I don't know how to express, I don't want to inherit any breadcrumbs at all all. On Fri, Jun 13, 2014 at 2:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: true that there isn't much doc on this any idea on how/where to document this site.xml inheritence is welcome Regards, Hervé Le jeudi 12 juin 2014 09:14:06 Andreas Sewe a écrit : Hi, that wasn't possible during my time of activity, not sure if anything changed since: http://mail-archives.apache.org/mod_mbox/maven-users/201104.mbox/%3C4DA 464 c8.2060...@apache.org%3E yes, https://jira.codehaus.org/browse/MSITE-582 got fixed and I have used the fix successfully in one of my projects. Best wishes, Andreas - 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: Breadcrumb inheritance in site.xml
yes, seems a good idea: project name=.. inherit=false http://maven.apache.org/doxia/doxia-sitetools/doxia-decoration-model/decoration.html tell me if you need help Regards, Hervé Le samedi 14 juin 2014 14:52:12 Benson Margulies a écrit : What do you think of an element in site.xml that turns off all inheritance? The case I'm dealing with is a project that wants to inherit build stuff from a parent but not site stuff. I'll tackle this if you think it's reasonable. On Sat, Jun 14, 2014 at 12:58 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: you can't inherit nothing with what has beed coded in MSITE-582: the top breadcrumb will always be there if you really need to drop absolutely everything, we need a new feature notice there are a lot of new features in maven-site-plugin 3.4-SNAPSHOT, waiting for a release (with Doxia, Doxia Sitetool and reporting-exec) so that's a good time for a new feature: it could go in the release train Regards, Hervé Le samedi 14 juin 2014 10:21:36 Benson Margulies a écrit : I think it could go in the site plugin doc; I'm willing to do some writing. Even after reading the JIRA, I don't know how to express, I don't want to inherit any breadcrumbs at all all. On Fri, Jun 13, 2014 at 2:04 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: true that there isn't much doc on this any idea on how/where to document this site.xml inheritence is welcome Regards, Hervé Le jeudi 12 juin 2014 09:14:06 Andreas Sewe a écrit : Hi, that wasn't possible during my time of activity, not sure if anything changed since: http://mail-archives.apache.org/mod_mbox/maven-users/201104.mbox/%3C 4DA 464 c8.2060...@apache.org%3E yes, https://jira.codehaus.org/browse/MSITE-582 got fixed and I have used the fix successfully in one of my projects. Best wishes, Andreas - 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 - 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: Breadcrumb inheritance in site.xml
true that there isn't much doc on this any idea on how/where to document this site.xml inheritence is welcome Regards, Hervé Le jeudi 12 juin 2014 09:14:06 Andreas Sewe a écrit : Hi, that wasn't possible during my time of activity, not sure if anything changed since: http://mail-archives.apache.org/mod_mbox/maven-users/201104.mbox/%3C4DA464 c8.2060...@apache.org%3E yes, https://jira.codehaus.org/browse/MSITE-582 got fixed and I have used the fix successfully in one of my projects. Best wishes, Andreas - 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 SCM Publish Plugin 1.1 Released
The Apache Maven team is pleased to announce the release of the Apache Maven SCM Publish Plugin, version 1.1 This 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. The plugin has been tested with git scm too and by example can push content for github pages. http://maven.apache.org/plugins/maven-scm-publish-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId version1.1/version /plugin Release Notes - Maven SCM Publish Plugin - Version 1.1 ** Bug * [MSCMPUB-12] - scmBranch ignored when tryUpdate is specified ** Improvement * [MSCMPUB-15] - log files and directories added/deleted as INFO ** New Feature * [MSCMPUB-14] - add all directories in 1 command per default 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 unhappy with jdk 1.8?
AFAIK, the m-site-p itself doesn't have any problem with jdk 8, since it doesn't care about jdk but from the little trace you give, there seem to be a reporting plugin that is sensitive to jdk 8: yes, some plugins have problems, we track them here [1] just look at your error traces and you'll see which report is in cause Regards, Hervé [1] http://jira.codehaus.org/browse/MNG-5551 Le jeudi 15 mai 2014 15:35:31 Andy Abendschein a écrit : I have recently udated my jdk from 1.7 to 1.8. Now I am having problems with the maven-site-plugin which fails with the error: Error during page generation: Error rendering Maven report: Unsupported targetJdk value '1.8'. Is there a way to specify a different targetJdk value to the plugin? Is there a plan to update the plugin to accommodate jdk 1.8? Thanks, Andy - 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: How to include images in a site via a report
Hi Simo, The maven-shanges-plugin does such a thing [1] Now, let's talk about about the beers... Regards, Hervé [1] http://maven.apache.org/plugins/maven-changes-plugin/xref/org/apache/maven/plugin/changes/ChangesMojo.html#L461 Le mardi 13 mai 2014 00:29:04 Simone Tripodi a écrit : Hi all mates, I am developing a new set of reports for Apache Felix and I would like to include nice icons in order to improve the l'n'f of produced data, one thing I didn't catch is how to copy images included in my plugin artifact to the target site. Any suggestion will be paid back in beers :) TIA, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi - 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 Plugin Tools (including Maven Plugin Plugin) 3.3 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Plugin Tools, version 3.3 The Maven Plugin Tools contains the necessary tools to be able to produce Maven Plugins in scripting languages and to generate rebarbative content like descriptor, help and documentation. 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. http://maven.apache.org/plugin-tools/ http://maven.apache.org/plugin-tools/maven-plugin-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId version3.3/version /plugin Release Notes - Maven Plugin Tools - Version 3.3 ** Bug * [MPLUGIN-191] - plugin-info.html is not created * [MPLUGIN-234] - Extreme amounts of debug logging * [MPLUGIN-235] - Doc example incorrectly states that plexus-utils is needed as a dependency * [MPLUGIN-236] - Value for Mojo's 'defaultPhase' parameter is incorrectly a string in examples * [MPLUGIN-239] - Execute goal does not passes from mojos.xml pluginMetadata * [MPLUGIN-242] - NullPointerException in MojoClassVisitor.visit() * [MPLUGIN-244] - Help mojo generates Javadoc, which is not accepted by JDK 8 doclint * [MPLUGIN-245] - @Parameter property names are not written to the plugin- help.xml file * [MPLUGIN-248] - XML-Namespace in ITs for ant-based mojos are wrong. * [MPLUGIN-255] - Generated HelpMojo doesn't close resource stream * [MPLUGIN-258] - IT failures with Jdk 8 (EA) * [MPLUGIN-260] - Plugin that uses annotations in Java 8 source can't generate descriptor * [MPLUGIN-262] - Generated HelpMojo doesn't display default values and user properties. ** Improvement * [MPLUGIN-237] - JavaDoc WARNING on generated HelpMojo class. * [MPLUGIN-246] - Clarify that super class must also use annotations * [MPLUGIN-264] - Allow other packaging types ** New Feature * [MPLUGIN-259] - @Parameter name=xxx to set bean property name different from class' field ** Task * [MPLUGIN-233] - remove InstanciationStrategy enum from annotations * [MPLUGIN-265] - remove deprecated API since introduction of PluginToolsRequest ** Wish * [MPLUGIN-249] - give snippets to show use of expressions to get Maven objects * [MPLUGIN-250] - since element is not in version 1.0.0 of plugin- metadata: should create a new version of the descriptor * [MPLUGIN-257] - deprecate classical Maven objects as components * [MPLUGIN-261] - sort goals in generated plugin.xml 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: jdk8 break maven-plugin-plugin?
already reported and fixed http://jira.codehaus.org/browse/MPLUGIN-260 Regards, Hervé Le samedi 26 avril 2014 11:43:34 james northrup a écrit : i have created a maven plugin from the plugin archetype. i have a mojo which apparently does not matter to repeating this process, any mojo will do. the project is in a reactor. the reactor runs the module but the plugin does not use reactor pom as parent. the compilation succeeds out of the archetype. regardless of what code lives in execute(), the act of adding a jdk8 jar dependency to this plugin's pom will cause the gisted failure. the environment and reactor build version is jdk 1.8 the pom and output are at https://gist.github.com/jnorthrup/83621d3f3c3a14433470 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Javadoc plugin with Javadoc 8: error fetching URLs
we'll try to not be overly choosy but both as Maven developper and as Maven user, I prefer to have separate focused issues with focused bug descriptions, then separate patches thanks for your help Regards, Hervé Le vendredi 18 avril 2014 20:55:38 Laird Nelson a écrit : On Fri, Apr 18, 2014 at 9:33 AM, Laird Nelson ljnel...@gmail.com wrote: Found the issue, I think; filed http://jira.codehaus.org/browse/MJAVADOC-393 to track it. Hi; I'm fixing this bug locally and am intending to supply a patch to the bug report. I can add support for Javadoc version 8 while I'm at it (a new package-list needs to be stored in src/main/resources and a few monkey-work changes need to be made to AbstractJavadocMojo.java; that's about it—also, Java 7's and Java 8's default home location on the Mac are wrong). Should I blend these two patches, or open another issue? Best, Laird - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: DependencyTreeBuilder vs. DependencyGraphBuilder
the difference still exists, and will never be fixed: that's the reasoning behind deprecating DependencyTreeBuilder I you need additional info about version conflicts, you should use Aether API + Maven Aether Provider for Maven 3, which will give you everything But at this precise level, you don't have any single API working with every version of Maven Regards, Hervé Le mardi 1 avril 2014 08:29:20 Stefan Ferstl a écrit : I'm using the org.apache.maven.shared:dependency-tree library to gather dependency information on my projects. In order to get additional information about version conflicts, I prefer to use DependencyTreeBuilder instead of DependencyGraphBuilder. However, the Javadoc of DependencyTreeBuilder says: Notice that it doesn't fail with Maven 3, but when Maven 2 and Maven 3 don't calculate the same transitive dependency result, the tree calculated with this component is consistent with Maven 2 even if run with Maven 3 (see MSHARED-167) The issue MSHARED-167 [1] was closed in June 2012. So may DependencyTreeBuilder still produce different results than DependencyGraphBuilder or is this not an issue anymore? Cheers, Stefan [1] https://jira.codehaus.org/browse/MSHARED-167 - 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: More on releasing artifacts with and without debug info
I wish we could just do a post-release step to strip out debugging information and compress Javascript / CSS . . . post-release? I suppose you mean post-package see the complete phase list[1] there are a lot of phases after complie = the place where code with debug symbols are generated, so a lot of phases to create stripped content, either before packaging or after packaging Regards, Hervé [1] http://maven.apache.org/ref/3.2.1/maven-core/lifecycles.html Le jeudi 27 mars 2014 23:17:07 Mark Eggers a écrit : On 3/27/2014 5:12 PM, Wayne Fay wrote: Off the top of my head, I could imagine 2 other approaches: 1. set up 2 separate project trees - one that produces the debug output, and another that depends on the source of the first (use dependency:unpack), and merely produces the non-debug output 2. if tooling exists to strip debug information, set up a second tree of projects, each one depending on the primary artifact and running the strip debug tool Best of luck keeping the versions in sync etc. Wayne I'm thinking of a third alternative . . . Set up a separate repository that handles the -DEBUG classifier artifacts. Create a profile that generates the artifacts and overrides the deployment information. Create a Jenkins CI job that gets triggered after a release build. Pass in the appropriate scm tag, and do a debug release with the appropriate profile. Developers should then be able to pick it up with the appropriate classifier. I'll probably have to look at the enforcer plugin to see if I can prevent a classifier dependency from making it into a release . . . I wish we could just do a post-release step to strip out debugging information and compress Javascript / CSS . . . Thanks for the ideas. /mde/ On Thu, Mar 27, 2014 at 2:22 PM, Mark Eggers its_toas...@yahoo.com wrote: Recently I received a requirement much like that covered in the following thread: Releasing artifacts with and without debug info (December 04, 2013) I'm new to Maven, but I more or less followed the idea: 1. create a profile 2. in the profile, specify the plugins 3. in each plugin, specify multiple execution blocks a. one block is configured to generate debug info b. another block is configured to omit debug info c. add classifiers to the JAR or WAR plugin as needed 4. deploy plugin a. add a configuration section b. add a files section c. list additional artifacts to be attached (?!) Is this the gist of Dimitar Gospodinov's reply at the end of the thread? It seems both hackish and verbose. However, I'm not sure of any other way to provide both fully optimized (compressed CSS, Javascript) and non-optimized WAR and JAR artifacts. Any time I'm doing something like this, I feel that I'm not doing it the Maven way. Other approaches? /mde/ - 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-dependency-tree reactor resolution
you hit the problem I faced when doing magic for multi-Maven versions compatibility: I didn't figure out how to have tests inside the component itself or it would need ITs (through m-invoker-p), but requires to write a plugin that uses the API then a pom that uses the plugin: too much the way I did it is to use either ITs in maven-dependency-plugin to test modifications in maven-dependency-tree in fact, now that latest maven-dependency-plugin release uses latest maven- dependency-tree API, it could probably be used inside an IT in maven- dependency-tree: that would ease a lot maven-dependency-tree modifications (it was really a headache last time, checking for every Maven version...) tell me if you need more help Regards, Hervé Le mardi 25 mars 2014 09:53:24 William Ferguson a écrit : Herve, I'm looking at trying to add this functionality to maven-dependency-tree but I want to start with a unit test showing the failure. But there doesn't seem to be any unit tests for the DependencyGraphBuilder (for any environment). What's the best way to create a unit test that sets up the environment so that I can explicitly test the Maven3DependencyGraphBuilder and Maven31DependencyGraphBuilder? William On Thu, Mar 20, 2014 at 5:36 PM, Hervé BOUTEMY herve.bout...@free.frwrote: I don't really know: that's a precise feature that I didn't sudy dependency-tree is used in Maven plugins in contexts where components are already installed: so there is not much difference between reactor resolution and local repository resolution you're probably right: if reactor resolution is not done, it should be added, since that can be something generally expected from the component Regards, Hervé Le jeudi 20 mars 2014 17:30:38 William Ferguson a écrit : Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - 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
Re: The par packaging not working
I was surprised too, but lilyevsky is right: par packaging is defined in Maven default lifecycles [1] and it points to a non-existent org.apache.maven.plugins:maven-par-plugin plugin it was added in r332151 [2], for MNG-699 [3] in Maven 2.0.1, with a link to MOJO-98 [4] for corresponding plugin In this Jira entry, this plugin is called New Par plugin for packaging artifacts as .par files (EJB3 Persistence Archives) And it is effectively still available in Maven ASF sandbox [5] Now, I have a few questions: 1. is EJB3 Persistence Archives what you were expecting? 2. can you try the plugin from sandbox and check that it works for what you expect? This seems a work in progress that nobody ever tried to use: but perhaps it is only a matter of getting the plugin out from sandbox. The other solution is that is is some EJB feature that was lost during JEE evolution, and we simply should remove the lifecycle from Maven core (and the plugin from sandbox) Regards, Hervé [1] http://maven.apache.org/ref/3.2.1/maven-core/default-bindings.html#Plugin_bindings_for_par_packaging [2] http://svn.apache.org/viewvc?view=revisionrevision=332151 [3] http://jira.codehaus.org/browse/MNG-699 [4] http://jira.codehaus.org/browse/MOJO-98 [5] http://svn.apache.org/viewvc/maven/sandbox/trunk/plugins/maven-par-plugin/ Le jeudi 20 mars 2014 16:37:33 Wayne Fay a écrit : Google has more information on the par plugin if you look there. From what I can see, the Apache Maven dev team has nothing to do with this plugin. Instead I think you should look at the Codehaus Mojo project, specifically: http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html I also found some Github links. Most likely you are going to have to build it yourself and mvn install it locally to use. Wayne On Thu, Mar 20, 2014 at 8:30 AM, lilyevsky leonidilyev...@yahoo.com wrote: The par packaging is not working. It is dependent on the org.apache.maven.plugins:maven-par-plugin, but this plugin does not exist. Is it deprecated? I am using the latest maven 3.2.1. How should I make the par package these days? I know this thing is relatively simple: just a collection of jars plus manifest with a few special entries. But I don't want to re-invent the wheel. -- View this message in context: http://maven.40175.n5.nabble.com/The-par-packaging-not-working-tp5788937. html Sent from the Maven - Users mailing list archive at Nabble.com. - 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: maven-dependency-tree reactor resolution
maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-tree reactor resolution
I don't really know: that's a precise feature that I didn't sudy dependency-tree is used in Maven plugins in contexts where components are already installed: so there is not much difference between reactor resolution and local repository resolution you're probably right: if reactor resolution is not done, it should be added, since that can be something generally expected from the component Regards, Hervé Le jeudi 20 mars 2014 17:30:38 William Ferguson a écrit : Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.frwrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - 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: Deploying archetypes
befaore deploying, you'll have to package, which usually attaches the artifact for later automatic deployment by deploy plugin see http://maven.apache.org/archetype/maven-archetype-plugin/ and the maven-archetype packaging automating it http://maven.apache.org/archetype/archetype-packaging/ but IMHO, trying to both generate an archetype, package it and deploy it from the example project is a risky process, because your (example project) pom will mix configuration for archetype generation/deployment with the valuable configuration you intend to have in the archetype you really should use create-from-project once then maintain the generated archetype project (and in fact the generic example project in src/main/resources) Regards, Hervé Le mercredi 5 mars 2014 08:50:00 Jordan Zimmerman a écrit : Hello, I’d like to configure my project to auto-deploy my generated archetype as part of the deploy execution. Is there a way to do this? So, to create the archetype, I have this: plugin artifactIdmaven-archetype-plugin/artifactId configuration propertyFilearchetype.properties/propertyFile /configuration executions execution phasepackage/phase goals goalcreate-from-project/goal /goals /execution /executions /plugin Is there a way to configure the deploy plugin (or some other plugin) to run a “deploy” goal on the generated archetype (in target/generated-sources/archetype/target)? Thanks! -Jordan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to fix broken sub-module links in Maven Site for multi-module project?
looks like a bug in maven-project-info-reports-plugin, which is the plugin launched by maven-site-plugin to generate every Project information reports Notice: m-site-p launches plugins for each report, then a failure when generating a site is not always a m-site-p bug. But every bug in every report plugin launched by m-site-p is sometimes (often?) seen as m-site-p bug :) I see you defined maven.project.info.reports.plugin.version2.7/maven.project.info.reports.plugin.version but you don't use it: are you sure that the latest plugin version is used in your test? Regards, Hervé Le jeudi 20 février 2014 21:24:02 Justin Robbins a écrit : I am creating a Maven Site for a 3-level multi-module maven project which is structured like this: parent child-a child-b I am running mvn site site:stage The Maven site module link (from the About page) works for child-a but is broken for the nested module child-b. (The link to child-b does work if I first click the link to child-a.) See for yourself here: http://justinhrobbins.github.io/multi-module-site-report-test/site/0.0.1-SNA PSHOT/ I have the following in my parent pom: distributionManagement site idsite/id namesite/name urlscp://www.yourcompany.com/www/docs/project//url /site /distributionManagement What needs to be done in order for the links to work for all the project modules in this Maven site report? (i know the is not real, for the moment i want it to work in stage) I added a simple test case project to Github that demonstrates the issue: https://github.com/justinhrobbins/multi-module-site-report-test I am using the following plugin versions: maven.site.plugin.version3.3/maven.site.plugin.version maven.source.plugin.version2.2.1/maven.source.plugin.version I have also tried adding distributionManagement/site/url to each child module. That fixes the link to child-b from the main Site page, but then the link from child-a to child-b is broken. These changes can be found in this branch: https://github.com/justinhrobbins/multi-module-site-report-test/tree/Distrib utionMgtInEachModule I have read the following relevant pages in the docs: http://maven.apache.org/plugins/maven-site-plugin/examples/multimodule.html http://maven.apache.org/plugins/maven-site-plugin/faq.html#Use_of_url Any suggestions are appreciated. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Plugin and report plugins that need dependencies declared
I'll make it short: please don't use reportPlugins in m-site-p configuration see http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Configuration_formats use classic configuration and everything will work fine Regards, Hervé Le jeudi 13 février 2014 15:34:03 Alex Potsides a écrit : I'm sorry if this question has been asked already but I couldn't find much in the archives. I'm trying to convert some existing build plugins to instead be report plugins with v3.3 of maven-site-plugin. One of the plugins needs an extra dependency to be specified. When it lived as a direct child of build/plugins this was ok, but when I do this sort of thing: plugin artifactIdmaven-site-plugin/artifactId version3.3/version configuration reportPlugins plugin groupId../groupId artifactId../artifactId version../version dependencies dependency artifactId../artifactId groupId../groupId ... I get: Cannot find setter, adder nor field in org.apache.maven.reporting.exec.ReportPlugin for 'dependencies' Is this sort of configuration not possible? Thanks in advance. Alex Potsides - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Site Plugin and report plugins that need dependencies declared
yes :) it has taken a few maven-site-plugin releases to really understand we had make a mistake switching to something that was finally not ready, and document it to have a chance people understand the rationale Regards, Hervé Le jeudi 13 février 2014 21:28:11 Alex Potsides a écrit : Brevity appreciated. You sound like someone who has answered that question before. Thanks, Alex On Thu, Feb 13, 2014 at 5:50 PM, Hervé BOUTEMY herve.bout...@free.frwrote: I'll make it short: please don't use reportPlugins in m-site-p configuration see http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Configurati on_formats use classic configuration and everything will work fine Regards, Hervé Le jeudi 13 février 2014 15:34:03 Alex Potsides a écrit : I'm sorry if this question has been asked already but I couldn't find much in the archives. I'm trying to convert some existing build plugins to instead be report plugins with v3.3 of maven-site-plugin. One of the plugins needs an extra dependency to be specified. When it lived as a direct child of build/plugins this was ok, but when I do this sort of thing: plugin artifactIdmaven-site-plugin/artifactId version3.3/version configuration reportPlugins plugin groupId../groupId artifactId../artifactId version../version dependencies dependency artifactId../artifactId groupId../groupId ... I get: Cannot find setter, adder nor field in org.apache.maven.reporting.exec.ReportPlugin for 'dependencies' Is this sort of configuration not possible? Thanks in advance. Alex Potsides - 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 SCM Publish Plugin 1.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven SCM Publish Plugin, version 1.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. The plugin has been tested with git scm too and by example can push content for github pages. http://maven.apache.org/plugins/maven-scm-publish-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId version1.0/version /plugin Release Notes - maven-scm-publish-plugin - Version 1.0 ** Improvement * [MSCMPUB-6] - when creating a directory in svn, if checkout fails, wait a few seconds and retry * [MSCMPUB-7] - Add timestamp when commit starts (and ends) * [MSCMPUB-10] - Pick up SCM credentials from settings.xml server section * [MSCMPUB-11] - display content size (number of directories, files, and size) ** Story * [MSCMPUB-4] - Need a working example for GitHub/gh-pages, preferably naturally linked to natural site lifecycle, and multi-module ** Task * [MSCMPUB-3] - Upgrade to SCM-1.9 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: Renaming site.xml or using different top-level site.xml for site plugin
ok defining profiles to have 2 site runs without same reporting plugins is ok: the 2 site runs share the same site.xml what would be an issue would be to require 2 different site.xml files. But from your description, you don't need such thing, no? Regards, Hervé Le lundi 27 janvier 2014 20:35:00 Benjamin Damm a écrit : Thanks to you and Mr. Boutemy for your replies. Let me explain a little more about what I want to do. We have perhaps two dozen maven modules that together provide a collection of core services. Together these modules are an SDK of sorts for clients. I'm trying to create a structure for generated documentation; however JavaDoc alone is not enough since we have other artifacts that make up our SDK. Protobuf definitions, WSDL files, REST services, etc. So, if an effort to create reliable documentation is going to produce good results, we need a mechanism that can be shared across all these modules and a model for how to aggregate the resulting documentation back into one SDK. The maven site plugin seems like the perfect structure to base this effort. We can take advantage of the maven build cycle and the parent pom structure, we can use skins to create a consistent look and feel, and we can use existing and new plugins (e.g. JavaDoc and others) to produce site artifacts from source. Controlling the inherited site definition gives us a relatively easy way to cross-link module output. However, the site defaults and related plugins also are useful, so I want to retain the ability to generate classic site output (e.g. test reports, code coverage, javadoc, findbugs). This output is not appropriate for distribution, but it's very useful for us internally. Hence, my investigation of using profiles. I started by redefining the site plugin's configuration in the parent pom within two profiles, so that all the sub-modules got access to those profiles without defining them individually. If this is a maven anti-pattern, then I certainly hear that and respect that. I wonder what other options are available? Any ideas? Thanks, -Ben -- Benjamin Damm Silver Spring Networks +1-650-839-4201 From: Stephen Connolly [stephen.alan.conno...@gmail.com] Sent: Sunday, January 26, 2014 11:37 AM To: Maven Users List Subject: Re: Renaming site.xml or using different top-level site.xml for site plugin In a multimodule project you need to attach the site descriptor of parent poms to the reactor. Thus the site descriptor you attach will depend on your profile... Thus you are in a maven anti-pattern (ie artifacts attached to the reactor should not depend on the profiles active at the time) You will likely have to find a different way, as I believe the rest if the maven developers will agree with me that this is a bad plan, and hence there will not be support for trying to solve your actual problem with the technique that us giving you thus problem HTH Stephen On Friday, 24 January 2014, Benjamin Damm bd...@silverspringnet.com wrote: Hello Mavens, Is there a way to rename site.xml to something else? I want to use the site framework to produce two trees of sites, each quite distinct from each other because they are based on two different profiles, and I was hoping, two different site.xml from the superpom at the top. In other words, I'm trying to achieve two trees of sites, each with a different site.xml at the top, but otherwise retaining the same structure (in terms of modules). I also plan to use profiles to use different site.xml files at the module level; that part works fine already because I can repoint the entire site document structure by using siteDirectory. It's the site.xml at the very top that's giving me trouble. No matter what I seem to do, I can only have one site.xml at the top of the module hierarchy. Does anyone know if there's a way around this limitation? Scouring the source code of the site plugin has so far not revealed anything. Thank you, -Ben -- Benjamin Damm Silver Spring Networks - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; -- Sent from my phone - 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: Renaming site.xml or using different top-level site.xml for site plugin
I don't really understand what you want to do see http://svn.apache.org/viewvc/maven/pom/trunk/maven/ for something quite similar In our case, the change to use src/site-docs instead of src/site is done in a separate site-pom.xml instead of a profile in pom.xml, but it doesn't change the principle used: configure siteDirectory What I don't understand is In other words, I'm trying to achieve two trees of sites, each with a different site.xml at the top, but otherwise retaining the same structure (in terms of modules). Such siteDirectory configuration won't affect modules structure The fact is that configuring siteDirectory not only gives you another site.xml, but site content (apt, xdoc, fml, md,...) isn't shared: do you want to share content between your sites? That's the only reasong why I would understand your need of a different site.xml without changing siteDirectory (which isn't an actually supported feature) Regards, Hervé Le vendredi 24 janvier 2014 23:42:29 Benjamin Damm a écrit : Hello Mavens, Is there a way to rename site.xml to something else? I want to use the site framework to produce two trees of sites, each quite distinct from each other because they are based on two different profiles, and I was hoping, two different site.xml from the superpom at the top. In other words, I'm trying to achieve two trees of sites, each with a different site.xml at the top, but otherwise retaining the same structure (in terms of modules). I also plan to use profiles to use different site.xml files at the module level; that part works fine already because I can repoint the entire site document structure by using siteDirectory. It's the site.xml at the very top that's giving me trouble. No matter what I seem to do, I can only have one site.xml at the top of the module hierarchy. Does anyone know if there's a way around this limitation? Scouring the source code of the site plugin has so far not revealed anything. Thank you, -Ben -- Benjamin Damm Silver Spring Networks - 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: WhatWeSayWeDo != WhatWeDo
since the value is readonly, it doesn't go to the user-documentation because
user can't do anything: it's pure internal code
for yourself, you can change readonly to false and see user documentation
generated
Regards,
Hervé
Le dimanche 15 décembre 2013 21:15:32 Martin Gainty a écrit :
Folks-
org.apache.maven.compiler.plugin.compiler.CompilerMojo.java
/**
* The source directories containing the sources to be compiled.
*/
@Parameter( defaultValue = ${project.compileSourceRoots}, readonly =
true, required = true )
For some reason I cannot locate compileSourceRoots anywhere on
maven-compiler-plugin page
http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
do I need better glasses to read this page properly?
Martin --
__
.. place long-winded disclaimer here..
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: pluginManagement questions
not exactly: the question is not about parent and childs, but about pluginManagement injection into build plugins, which works exactly like dependencyManagement injection into dependencies if you define a precise version in the build plugins (or in a dependency), dependencyManagement does not change it: defining a version is a way to override pluginManagement. Then the problem here is that parent pom should not have defined a version in build/plugins: this is a good practice exactly because it causes the problem you're facing: you cannot upgrade the version in child pluginManagement. The parent pom should be fixed, so you can define a new version in pluginManagement Regards, Hervé notice: the reference documentation is here [1] http://maven.apache.org/ref/3.1.1/maven-model-builder/ Le jeudi 14 novembre 2013 16:20:19 Laird Nelson a écrit : Suppose I have a parent pom that makes use of the maven-enforcer-plugin. As a matter of fact I do, and it's public, so you can follow along at home: parent groupIdorg.sonatype.oss/groupId artifactIdoss-parent/artifactId version7/version /parent Looking at that pom, there is this snippet in it: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.0/version So it declares this as a plugin that it uses internally, and says it is going to use version 1.0. I understand that. I also understand that this plugin definition is inherited. If I do nothing else, and make use of the maven-enforcer-plugin, and do not specify a version, I'll get 1.0. Suppose now *my* pom--the first generation child--wants to enforce that throughout its world maven-enforcer-plugin version 1.3.1 should be used. My naive assumption was, oh, that's what pluginManagement is for. So I put this in: build pluginManagement plugins plugin artifactIdmaven-enforcer-plugin/artifactId version1.3.1/version And it's my understanding that second and greater generation children will be forced to use version 1.3.1 as a result of that. (If I have a child that inherits from THIS pom, then he'll use version 1.3.1.) However, I notice that while building THIS pom the oss-parent pom is still running maven-enforcer-plugin 1.0. It runs the maven-enforcer-plugin during the clean lifecycle, and so when I run mvn clean from my first generation child, I get version 1.0. This makes a certain amount of sense--my plugin management section probably shouldn't affect what versions my parent has chosen. On a whim, I *also* added a plugins section *in addition* to my pluginManagement section: build plugins plugin artifactIdmaven-enforcer-plugin/artifactId version1.3.1/version ...and ran again. This time maven-enforcer-plugin version 1.3.1 was run. I had to digest this for a while. Obviously my pluginManagement stanza is not in effect--we proved that already. So my first generation child pom can cause its parent pom to use a different version of the plugin by specifying a new version in the plugins stanza. Is that a good thing? An expected thing? On another whim I upped the version here to something enormous and nonsensical to really make sure I was seeing what I was seeing: version12/version ...and ran again. This time--with a pluginManagement section specifying version 1.3.1 and a parent pom specifying version 1.0 and my own pom specifying version 12--Maven tried to download version 12, which of course as of this writing does not exist. From all this I have gleaned the following information, and I'm hoping someone can tell me where I'm wrong (I'm sure I'm wrong somewhere): * pluginManagement constrains versions for children, should they happen to make use of the plugins mentioned therein. That's all it does. * Without children, there is no point in putting in a pluginManagement stanza. * pluginManagement doesn't constrain its sibling plugins stanza, nor does it constrain anything about its parent, nor does it constrain anything inherited from the parent. * Specifically, if you have a buildplugins stanza **and** a buildpluginManagement stanza, and they declare the same plugin but different versions, then the buildpluginsversion element will trump everything else *in that pom* (not in his children), including any plugin declarations from the parent. * The versions-maven-plugin's display-plugin-updates goal will tell you that everything is up to date and fine if you have a pluginManagement stanza and no plugins section--but as I've already written above your first-generation child pom may end up using an older version of a plugin anyway, because his parent might have defined it. Even though your pluginManagement stanza declares the proper, up-to-date version, that version may not be respected if your parent has a buildplugins stanza that
Re: scm publish instructions
why site:stage-deploy and not site:stage? I suppose we made a mistake in this doc Regards, Hervé Le samedi 16 novembre 2013 14:51:36 Benson Margulies a écrit : I can't get the github example to work with a multi-module site. I follow the instructions http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/multi-modu le-configuration.html In spite of the explicit skipDeploy=false in the post-site execution, I still get [INFO] --- maven-site-plugin:3.3:stage-deploy (default-cli) @ bf-sample-lucene-chinese --- [INFO] maven.site.deploy.skip = true: Skipping site deployment Note 'default-cli' and not 'stage-for-scm-publish'. - 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 Plugin 3.1
I suppose you're using Maven 3.1.x
you should read
https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound then
upgrade plugins versions accordingly
or use Maven 3.0.x
Regards,
Hervé
Le lundi 11 novembre 2013 09:38:40 Collins Solutions a écrit :
I am trying to use the maven site plugin 3.1 and I get this error:
Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.1:site (default-site) on
project acc-eao: Execution default-site of goal
org.apache.maven.plugins:maven-site-plugin:3.1:site failed: A required
class was missing while executing
org.apache.maven.plugins:maven-site-plugin:3.1:site:
org.sonatype.aether.graph.DependencyFilter
I am not trying to use sonatype at the moment. My site plugin
configuration looks like this:
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.1/version
executions
execution
idattach-descriptor/id
goals
goalattach-descriptor/goal
/goals
/execution
/executions
/plugin
...
...
profiles
profile
idfull/id
reporting
plugins
!-- Java Documentation --
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version${javadoc.version}/version
/plugin
/plugins
/reporting
/profile
/profiles
...
I have been having various other issues with the site plugin that I was
not having with version 2.x. One question that I have is, is it
required to have a site.xml file now? Before, i did not need to include
any site configuration to get a site generated however, that
configuration (or lack thereof) did not work with version 3.1.
-
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: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
thank you Curtis: all the pointers you gave are of great value! I perfectly understand your Githubs examples: pull requests + work to give pull requests most chances to be accepted In fact, in our case, for somebody having commit privileges, using such pull requests isn't the first thing I would have thought, but yes, it is a good Review Then Commit tooling For somebody with commit privileges, would you find any key difference with a branch on ASF Git + discussion on mailing list before merging into master? For gerrit, now I see what it looks like: seems really more complex than GitHubs pull requests. Don't know when such tooling starts to be really useful Thanks again for your pointers: today, I learned something useful, it's a good day Notice I'm having holidays and won't be on the ML for 2 weeks: I won't be able to continue the discussion, even if really instructive Regards, Hervé Le vendredi 2 août 2013 11:13:50 Curtis Rueden a écrit : Hi Herve, I didn't use gerrit nor have seen anybody using it. ... Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? Google uses it (of course). For example, for Chromium: https://gerrit.chromium.org/ Kitware uses it. ITK, VTK, etc.: http://review.source.kitware.com/ I'm sure there are many others. Personally my colleagues and I don't use it; we use GitHub's code review mechanism which is simple and effective. You can comment on any Pull Request, and on any line of any commit. I hear about it more and more often as an argument why it makes git better than svn It was not my goal to argue that Gerrit makes Git better than SVN but rather than good code review tools make code review *much* easier. Git is better than SVN for many, many reasons that have nothing to do with code review tools. :-P yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. As a programmer, revision control in one of your bread-and-butter tools. Shouldn't you be taking the time to become a VCS black belt? Doing so will save you loads of time in the long run, for the same reasons that becoming a command line master, or an IDE master, or a master of *any* effective productivity tool, will. Embrace Larry Wall's virtues of the programmer -- laziness, impatience and hubris -- and always seek the better, faster path! Computers are different than other skill sets: a professional sprinter may be able to sprint 2x or 3x or even 5x faster than you, but a professional programmer can accomplish a task on a computer thousands or even millions of times faster than a neophyte... *if* the programmer has a thirst for knowledge and self-improvement. /soapbox Anyway, yes, my colleagues and I *do* use Git in this way: work on topic branches, rewrite history to make review easier, and sometimes file Pull Requests on GitHub to specifically invite review for possibly disruptive changes. I'm not really sure what to point you at here, other than the Contribution Activity section of my GitHub page: https://github.com/ctrueden Of course, it is changing all the time... Regards, Curtis On Fri, Aug 2, 2013 at 10:47 AM, Hervé BOUTEMY herve.bout...@free.frwrote: Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé
Re: Any guideline on how to make plugin, aether dependence , compatible with both maven 3.0.x and 3.1
we didn't write specific documentation, neither on how to detect if your plugin will break nor how to fix it: we don't expect much problems if you need help, just ask: and if sufficient people need help, I'll try to sum up the different cases we found Regards, Hervé Le dimanche 14 juillet 2013 23:15:57 Dan Tran a écrit : Hi From 3.1 release notes, i am seeing a list of this type of plugins https://cwiki.apache.org/confluence/display/MAVEN/AetherClassNotFound Rather then browser thru the code, is there a quick guide line? Thanks -D - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Switching Lifecycles on other things than packaging
I think there are some little inconsistencies in vocabulary, causing wrong analysis there are 3 lifecycles: default, clean and site [1] and packaging selects default plugin bindings for default lifecycle [2] For the moment, I didn't dig sufficiently into everything to have every answers and really do what I will explain, but IIUC, if you define a new phase in a new lifecycle, you should be able to inject a new lifecycle completely independent from packaging then plugin bindings can either be defined in the lifecycle, like it is done in site and clean lifecycles, or by packaging, like it is done with default lifecycle this analysis is for the moment theoretical, based on conclusion I made while documenting lifecycles and plugin bindigs, but seems rather logical (and contrary to what we understand from historical ways of taliking of lifecycle when we talk about default plugin bindings, probably because clean and site lifecycles come directly with their plugin bindings) Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/lifecycles.html [2] http://maven.apache.org/ref/3-LATEST/maven-core/default-bindings.html Le samedi 6 juillet 2013 15:46:24 Barrie Treloar a écrit : On 6 July 2013 15:39, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, is there a way to switch to a different lifecycle depending on e.g. a path/file etc? Or is the agreed way to just have another packaging? The lifecycle for the pom comes from packaging. The plugins that pom declares then attach themselves to the lifecycle stages. You can always use a pom packaging to essentiallly do nothing, and have all the work done via plugins. - 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: Lifecycles and configuration of plugins
default plugin version can effectively be injected but that's *default* plugin versions since actual lifecycle definitions are done in Maven core, you can't count on it to upgrade version in your projects in your case, where you want to define a new lifecycle, perhaps it will be possible to change versions from your lifecycle definition the question will be: how is the new lifecycle injected? into projects pom through extension? or into Maven installation through lib/ext this is IMHO the crucial point that will make default versions usable or not but I tend to imagine this won't be ok: pluginManagement in your poms, like for other lifecycles and plugin bindings, should be the right approach Regards, Hervé Le samedi 6 juillet 2013 08:15:02 Mirko Friedenhagen a écrit : Hello, I see that versions of plugins are either manageable in the pom or in the lifecycle. Now what about configurations of plugins? May these be hidden as well in an extension/plugin? I want to hide this because a lot of application developers look at our company POM and shudder because of it's shere size :-) Regards Mirko - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Ant Project Convert To Maven
the approach i used in a company was in 2 steps: 1. continue to build with Ant, but with Maven Ant Tasks for dependency management 2. use Maven to try to build, in parallel with Ant, to check if you get the same result. A first result here was to get a reporting site working, even if the artifact built by Maven wasn't completely right Regards, Hervé Le jeudi 13 juin 2013 18:30:44 RajaPrlabu a écrit : Hi, all:Sorry for my entry-level question. Is it possible for me to convert from an Ant project to A Maven project from within NetBeans IDE or Eclipse IDE.which is the best IDE.Or, is there any method to convert from an Ant project to a Maven project using some command line method? Or, any standard method to do so?1.How to convert Spring MVC Project using Ant convert into Maven nexus.could u please provide me Following Steps.ThanksRaja k -- View this message in context: http://maven.40175.n5.nabble.com/Ant-Project-Convert-To-Maven-tp5759284.htm l Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin woes
yes, I worked recently on this exact issue: site *staging* on complex cases like yours, which is not as usual as you expect It took me a good number of hours with the issue reporter to understand what he was doing, what he was expecting that wasn't trivial, and I found a solution with this topSiteURL But you're right, the option is still under-documented: yes, it's done on my free time And your last comment on the issue is interesting : yes, adding a sanity check when the stage goal writes outside target/staging would help a lot Please open a new issue on this: I'll work on it, because such good ideas are the ones that help make things better, step by step, idea after idea Notice: don't blame Sonatype for everything about Maven, because Maven = Apache Maven (with its PMC to blame if you want), which contains more than what Sonatype really supports. And even if the line between what Sonatype supports or not is not always clear, AFAIK maven-site-plugin is exactly one part that is not supported by Sonatype I hope we'll continue good work and improvements thgough this Jira issue about sanity check, and other ideas that will happen after that Regards, Hervé Le samedi 1 juin 2013 00:32:25 Stephen Colebourne a écrit : On 31 May 2013 23:58, Stephen Colebourne scolebou...@joda.org wrote: It looks like separate aggregator and parent projects simply don't work with the site plugin. But it would be good for someone to accept that is the case. And apparently the two don't work well together: http://jira.codehaus.org/browse/MSITE-669?focusedCommentId=324876page=com.a tlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-324876 but recent work has perhaps improved matters (if you set the topSiteURL property, which is of course under-documented!) Stephen - 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: Guaranteeing JDK 5 compatibility?
http://mojo.codehaus.org/animal-sniffer-maven-plugin/ Le vendredi 24 mai 2013 13:29:03 Russell Gold a écrit : By default, as I understand it, Maven 3 compiles with the source and target options set to 1.5. This guarantees that later language features (such as diamond notation) will result in compile errors, and the generated classes will run in a JDK 1.5 JVM. But what about API calls? Does the compile plugin have a way to ensure that references to APIs created in later versions of the JDK will fail? I've seen a trick that uses the JDK 1.5 bootclasspath to do this; does Maven have a cleaner solution? Thanks, Russ - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Guaranteeing JDK 5 compatibility?
notice that there is another case to take care: if you use dependencies compiled in Java 6 (like guava, for example) the solution for this additional case is http://mojo.codehaus.org/extra-enforcer-rules/enforceBytecodeVersion.html Regards, Hervé Le vendredi 24 mai 2013 19:44:10 Hervé BOUTEMY a écrit : http://mojo.codehaus.org/animal-sniffer-maven-plugin/ Le vendredi 24 mai 2013 13:29:03 Russell Gold a écrit : By default, as I understand it, Maven 3 compiles with the source and target options set to 1.5. This guarantees that later language features (such as diamond notation) will result in compile errors, and the generated classes will run in a JDK 1.5 JVM. But what about API calls? Does the compile plugin have a way to ensure that references to APIs created in later versions of the JDK will fail? I've seen a trick that uses the JDK 1.5 bootclasspath to do this; does Maven have a cleaner solution? Thanks, Russ - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.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
Re: maven3 - getting error on mvn dependency:tree command
can you give us the result of mvn -version? Regards, Hervé Le vendredi 17 mai 2013 11:49:07 coolguy a écrit : I've a project that uses maven 3. I get the following error when I run mvn dependency:tree command. Could someone advise why would I get this error? [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.7:tree (default-cli) on project : Cannot build project dependency graph: org.apache.maven.project.MavenProject.getProjectBuildingRequest() - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.7:tree (default-cli) on project wesp-dgw: Cannot build project dependency graph at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:2 03) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 48) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 40) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life cycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(Life cycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(Lif ecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarte r.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.ja va:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher. java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Cannot build project dependency graph at org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:233) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPl uginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:1 95) ... 19 more Caused by: org.apache.maven.shared.dependency.graph.DependencyGraphBuilderException: org.apache.maven.project.MavenProject.getProjectBuildingRequest() at org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuild er.buildDependencyGraph(Maven3DependencyGraphBuilder.java:92) at org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuil der.buildDependencyGraph(DefaultDependencyGraphBuilder.java:63) at org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:216) ... 21 more Caused by: java.lang.NoSuchMethodException: org.apache.maven.project.MavenProject.getProjectBuildingRequest() at java.lang.Class.getMethod(Class.java:1605) at org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuild er.invoke(Maven3DependencyGraphBuilder.java:99) at org.apache.maven.shared.dependency.graph.internal.Maven3DependencyGraphBuild er.buildDependencyGraph(Maven3DependencyGraphBuilder.java:68) ... 23 more -- View this message in context: http://maven.40175.n5.nabble.com/maven3-getting-error-on-mvn-dependency-tre e-command-tp5756424.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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] Maven Dependency Plugin 2.8 Released
The Apache Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.8 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. http://maven.apache.org/plugins/maven-dependency-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.8/version /plugin Release Notes - Maven 2.x Dependency Plugin - Version 2.8 ** Bug * [MDEP-312] - copyPom with useRepositoryLayout copies pom to wrong location * [MDEP-374] - dependency:tree -Dverbose isn't verbose anymore * [MDEP-379] - useSubDirectoryPerArtifact creates folder with wrong format * [MDEP-395] - get doesn't copy transitive dependencies to output directory * [MDEP-407] - add support for Maven 3.1-A1/Eclipse Aether 0.9-M2 to dependency:tree * [MDEP-411] - copy-dependencies with useRepositoryLayout and copyPoms copies the poms twice * [MDEP-416] - dependency:copy-dependencies addParentPoms causes NPE with Maven 2 ** Improvement * [MDEP-128] - Support ability to specify multiple includeScope parameters * [MDEP-414] - Add option to sort output of dependency:resolve/list * [MDEP-415] - Add option to include parent poms in dependency:resolve output ** New Feature * [MDEP-412] - add an option to copy dependencies with their parent poms + parent poms of current project ** Wish * [MDEP-321] - Remove final declaration from class UnpackMojo 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] Maven Project Info Reports Plugin version 2.7 Released
The Apache Maven team is pleased to announce the release of the Maven *Project Info Reports Plugin, version 2.7* The Maven Project Info Reports plugin is used to generate reports information about the project. http://maven.apache.org/plugins/maven-project-info-reports-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.7/version /plugin Release Notes - Maven 2.x Project Info Reports Plugin - Version 2.7 ** Bug * [MPIR-229] - The 'modules' report does not support 'url' elements using properties. * [MPIR-257] - English localization properties misplaced (i18n) * [MPIR-261] - Wrong URL for some CI home pages in resource bundles * [MPIR-264] - JDK Rev not determined when Maven 2 is building the site * [MPIR-266] - Subsequent runs of the dependencies report should always produce the same output if the input hasn't changed * [MPIR-272] - add support for Maven 3.1-A1/Eclipse Aether 0.9-M2 to dependencies report * [MPIR-275] - NPE in DependenciesReport ** Improvement * [MPIR-182] - Make order of reports shown in Project Reports configurable * [MPIR-232] - when packaging is pom, index report (About) should contain modules report content * [MPIR-258] - Missing english localization property for dependency-info (i18n) * [MPIR-259] - Add french localization for dependency-info * [MPIR-262] - Add support for 'report.cim.bamboo.intro' resource property * [MPIR-271] - GIT support in project-info-reports:scm * [MPIR-274] - Added translations and corrections to spanish resource boundle ** Task * [MPIR-276] - Upgrade to Doxia 1.4 Enjoy, -The Apache Maven team
[ANN] Maven Site Plugin 3.3 Released
The Apache Maven team is pleased to announce the release of the Maven Site Plugin, version 3.3 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/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version3.3/version /plugin Release Notes - Maven 2.x and 3.x Site Plugin - Version 3.3 ** Bug * [MSITE-658] - 'relativizeDecorationLinks' not working using multiple 'locales'. * [MSITE-662] - jetty listens on port 0 * [MSITE-670] - Cannot use site.xml generated by effective-site goal and output parameter as is * [MSITE-677] - site:run's port cannot be set due to missing @Parameter annotation * [MSITE-678] - Configuring Site Run example contains dead link * [MSITE-680] - site:effective-site failure with Maven 2 * [MSITE-682] - Apostrophe's in Markdown are removed resulting in HTML full of spelling error * [MSITE-683] - reporting fails with Maven 3.1-A1/Eclipse Aether 0.9-M2 * [MSITE-686] - Report inheritance does not work as specified * [MSITE-687] - wrong site stage location when parent pom (not in reactor) has same site ** Improvement * [MSITE-661] - support markdown format per default * [MSITE-666] - Please mark SiteDescriptorAttachMojo as @threadSafe * [MSITE-667] - document reportSets usage ** Wish * [MSITE-684] - disable reportPlugins configuration in POM 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: Reopen MCHECKSTYLE-153?
looking at https://jira.codehaus.org/browse/MCHECKSTYLE-144 it seems fixed in 2.10, so 2.9.1 has the bug Regards, Hervé Le jeudi 18 avril 2013 10:02:22 Itai Frenkel a écrit : Hello, It seems like I've encountered Checkstyle doesn't run on projects containing only test classes bug in version 2.9.1 Can anyone else confirm it? Itai - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: JXR: any plans to fix some parsing related issues?
if anybody submits patches, I can review and commit Regards, Hervé Le lundi 15 avril 2013 06:03:19 davide.cavestro a écrit : Hi all, I've sketched a rough plugin https://github.com/davidecavestro/gradle-jxr-plugin to spread JXR even to gradle users. It just works, but it is limited by some parsing issues. I've filed JXR-101 https://jira.codehaus.org/browse/JXR-101 and JXR-100 https://jira.codehaus.org/browse/JXR-100 more than a month ago but I still got no response at all. Is there any roadmap for jxr? Is there any chance to get them (and other issues) fixed? I hope the project is not going to be discontinued. Cheers Davide PS: Please also let me know if I've written to the wrong mailing list. -- View this message in context: http://maven.40175.n5.nabble.com/JXR-any-plans-to-fix-some-parsing-related- issues-tp5753771.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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: How to disable “Test Source Xref” report generation
yes, see Selecting Reports from a Plugin: Configuring Report Sets in [1]
notice you're using the new configuration format (ie reportPlugins inside
maven-site-plugin), which is not recommended at the moment [2]
Regards,
Hervé
[1] http://maven.apache.org/plugins/maven-site-plugin/examples/configuring-
reports.html
[2] http://maven.apache.org/plugins/maven-site-
plugin/maven-3.html#Configuration_formats
Le mardi 9 avril 2013 17:10:01 Aliaksei Lahachou a écrit :
I think per default Maven simply executes all reports, in your case jxr and
test-jxr. But you may configure specific reports:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version${plugins.jxr.version}/version
reportSets
reportSet
reports
reportjxr/report
/reports
/reportSet
/reportSets
/plugin
Regards,
htfv (Aliaksei Lahachou)
On Tue, Apr 2, 2013 at 2:44 PM, Aleksandra Nowak lot...@gmail.com wrote:
Hi all!
I'm using Maven Site Plugin to generate my project page and the JXR Plugin
to publish the source code. But I don't want to publish sources of test
classes. Does anybody know if it is possible to disable Test Source Xref
report. I've only found this pagehttp://jira.codehaus.org/browse/JXR-47but
this parameter doesn't seem to work. My configuration in POM looks like
this:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.2/version
configuration
reportPlugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jxr-plugin/artifactId
version2.3/version
configuration
suppressTestXreftrue/suppressTestXref
/configuration
/plugin
/reportPlugins
/configuration
/plugin
Kind regards,
Alex
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.5: site plugin or documentation broken?
1. warning if you don't define plugin version
you can believe Maven 3 doc, version is taken from pluginManagement: coded
here [1]
But I must confess I never tried with CLI, since we use to continue defining
plugin version directly to keep Maven 2.x compatibility
I just tried and confirm this warning happens, but it is wrong: please open a
Jira issue
2. report inheritence
I just tried the corresponding inheritedReports IT from m-site-p, which I
had to skip with Maven 3 in MSITE-595 [2] /r1148517 [3]
and you're right: now, m-site-p with Maven 3 seems to behave like Maven 2,
then the doc is now wrong
I don't know when/how it has changed: m-site-p or Maven?
Please open another Jira issue
BTW, thanks for these precise reports: this really helps us keep Maven as good
as possible
Regards,
Hervé
[1] http://maven.apache.org/shared/maven-reporting-
exec/apidocs/org/apache/maven/reporting/exec/DefaultMavenReportExecutor.html#getPluginVersion(org.apache.maven.reporting.exec.ReportPlugin,
org.apache.maven.artifact.repository.RepositoryRequest,
org.apache.maven.reporting.exec.MavenReportExecutorRequest)
[2] http://jira.codehaus.org/browse/MSITE-595
[3] http://svn.apache.org/viewvc?view=revisionrevision=r1148517
Le mardi 9 avril 2013 18:38:41 Wolf Geldmacher a écrit :
I'm trying to get the maven site plugin to do my bidding but have gotten
lost...
Given the following simple POM's
pom.xml:
project
modelVersion4.0.0/modelVersion
groupIdch.pecunifex/groupId
artifactIdparent/artifactId
version1.0-SNAPSHOT/version
packagingpom/packaging
urlhttp://localhost/parent/url
modules
modulechild/module
/modules
properties
version.site.plugin3.2/version.site.plugin
version.info.plugin2.6/version.info.plugin
/properties
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version${version.site.plugin}/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
version${version.info.plugin}/version
/plugin
/plugins
/pluginManagement
/build
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
reportSets
reportSet
reports
reportindex/report
reportsummary/report
reportproject-team/report
reportmodules/report
reportplugins/report
reportplugin-management/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
/project
and child/pom.xml:
project
modelVersion4.0.0/modelVersion
parent
groupIdch.pecunifex/groupId
artifactIdparent/artifactId
version1.0-SNAPSHOT/version
/parent
groupIdch.pecunifex/groupId
artifactIdchild/artifactId
urlhttp://localhost/child/url
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
reportSets
reportSet
reports
reportindex/report
/reports
/reportSet
/reportSets
/plugin
/plugins
/reporting
/project
and the documentation on:
http://maven.apache.org/plugins/maven-site-plugin/maven-3.html
I get the following when I call mvn site:
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model
for ch.pecunifex:child:jar:1.0-SNAPSHOT [WARNING]
'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-project-info-reports-plugin is missing. @
line 16, column 21 [WARNING]
[WARNING] Some problems were encountered while building the effective model
for ch.pecunifex:parent:pom:1.0-SNAPSHOT [WARNING]
'reporting.plugins.plugin.version' for
org.apache.maven.plugins:maven-project-info-reports-plugin is missing. @
line 38, column 21 [WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build. [WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
Re: Finding Maven properties?
a reference list does not exist per-se, because the structure is extensible: it's not really properties but more pseudo-properties with multiple sources one reference source of information is the structure documentation: http://maven.apache.org/ref/3-LATEST/maven-model-builder/ Regards, Hervé Le mercredi 13 mars 2013 10:35:21 Russell Gold a écrit : Hi, How does one get a complete list of available Maven properties? I found a sonatype doc which suggested looking at the Javadoc for the Model class in Maven http://maven.apache.org/ref/3.0.3/maven-model/apidocs/ but I cannot find any mention there of methods which would define project.build.sourceEncoding, which is clearly a real property. That suggests that there must be other properties available that somehow are not part of the model. - thanks Russ Gold - Come read my webnovel, Take a Lemon http://www.takealemon.com, and listen to the Misfile radio play http://www.gold-family.us/audio/misfile.html! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Doxia markdown module: em-dash?
I suppose you're hitting https://jira.codehaus.org/browse/DOXIA-480 It is fixed in trunk, but we didn't release Doxia 1.4 yet regards, Hervé Le samedi 16 février 2013 14:21:27 Laird Nelson a écrit : Hello; how do I render an em dash using the Doxia Markdown module? The following source code results in an empty string in the final HTML output. Each of the following non-whitespace lines represents an attempt: mdash; -- --- amp;mdash; I can make it render an em dash using #8212; but I'd like to understand why the other options don't work. Thanks, Laird - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Site plugin to document properties in the pom?
I wrote some documentation about properties available during Velocity
processing in Doxia [1]
project (type MavenProject) should be available, which has getProperties()
method: this should be what you are looking for
this documentation can probably be enhanced: any feedback appreciated
Regards,
Hervé
[1] http://maven.apache.org/doxia/doxia-sitetools/doxia-site-renderer/
Le mardi 15 janvier 2013 15:45:18 Mark H. Wood a écrit :
On Mon, Jan 14, 2013 at 10:26:56PM +0200, Graham Leggett wrote:
On 14 Jan 2013, at 10:02 PM, Mirko Friedenhagen mfriedenha...@gmail.com
wrote:
I once was successful with referencing injected properties in velocity
by using the get method. Maybe something like:
${project.properties.get(tomcat.port.http.confluence43.live)}
will work?
Alas, no.
The idea is that the properties in the pom and the properties published to
the site are always in sync, even after the current crop of architects
have moved on from the project. If you have to add a property in two
steps, there is no way the project will stay in sync.
Yeah, he's asking for a way to get the site plugin to ask the POM for
a list of all defined properties, whatever they may be today, so that
the plugin can enumerate them (with their values I suppose) in its
report *without knowing their names in advance*.
The value of project.properties seems to be a java.util.Properties, so
there may be some way to get at its propertyNames() method, or the
keys() keySet() etc. methods it inherits from Hashtable, but you will
probably have to write your own report plugin to make use of any of
them.
org.codehaus.mojo:properties-maven-plugin seems to know how to
enumerate properties, but it doesn't do reporting. It could perhaps
be studied as a model.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: 1.0.0-SNAPSHOT considered older than 1.0.0?
the Maven core reference doc is http://maven.apache.org/ref/3.1- SNAPSHOT/maven- artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html Le jeudi 20 décembre 2012 14:02:02 org.apache.maven.u...@io7m.com a écrit : Hi. I can't find any documentation on the Maven site about snapshots. I'm trying to determine whether a snapshot is considered to be older or newer than the version number prefix. Is 1.0.0-SNAPSHOT considered to be the current HEAD, having a theoretical 1.0.0 at some point in the past, or is 1.0.0-SNAPSHOT considered to be a precursor to some future 1.0.0 release? The only information I can find seems to be off-site at: https://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Re solution#DependencyMediationandConflictResolution-IncorporatingSNAPSHOTversi onsintothespecification The Maven user guide mentions that snapshots will be described later in the guide - but they aren't. - 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 build errors
if you run with mvn -X and give us the full stack trace, perhaps we can see what's going wrong Le jeudi 6 décembre 2012 06:34:52 David Hoffer a écrit : Note that the copy-dependencies goal in the stand-alone module is not really relevant/useful in the site build. Rather it's a key part of the regular...clean, install, release phases...that module just copies artifacts and builds an aggregate artifact (i.e. it does not have source code). But I'm not aware of how to 'turn-off' things like this just for the site build. On Thu, Dec 6, 2012 at 6:22 AM, David Hoffer dhoff...@gmail.com wrote: This happens if I build locally and when built with our CI build server. When I build locally it will use disk C and the disk is not full. These folders are just the normal maven build folders so if there is something using the file...it's a Maven process. We are using Maven3...perhaps the site build spawns other processes and there is a conflict between them? On Thu, Dec 6, 2012 at 5:53 AM, Adrien Rivard adrien.riv...@gmail.com wrote: Most probably, it means that one of the file is used by another application, thus cannot be deleted. On Thu, Dec 6, 2012 at 1:47 PM, David Hoffer dhoff...@gmail.com wrote: Those last two lines make no sense to me as this happens on systems with Admin/root permissions. There doesn't seem to be any way this can be a permissions issue, so I assume that's an incorrect/misleading message. -Dave On Wed, Dec 5, 2012 at 11:23 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: please read the last two lines F:\work\7832e3bc4d2f257b\dashboard-core\target\classes (Access is denied) Le mercredi 5 décembre 2012 15:00:24 David Hoffer a écrit : I have a multi-module maven build and can't get the site build to work. It's currently failing with this error. The module its failing on, stand-alone, doesn't have any code just packages assemblies, etc. Any ideas what is causing this? Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.2:site (default-site) on project stand-alone: failed to get report for org.apache.maven.plugins:maven-surefire-report-plugin [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.2:site (default-site) on project stand-alone: failed to get report for org.apache.maven.plugins:maven-surefire-report-plugin: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.4:copy-dependencie s (copy-dependencies) on project stand-alone: Error copying artifact from F:\work\7832e3bc4d2f257b\dashboard-core\target\classes to F:\work\7832e3bc4d2f257b\stand-alone\target\stand-alone-4.4-SNAPSHOT\pac kage s\dashboard-core-4.4-SNAPSHOT.jar: F:\work\7832e3bc4d2f257b\dashboard-core\target\classes (Access is denied) - [Help 1] [13:52:12] - 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 -- Adrien Rivard 06 63 08 79 74 - 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 build errors
at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.copyFile(Abstract
DependencyMojo.java:197) at
org.apache.maven.plugin.dependency.CopyDependenciesMojo.copyArtifact(CopyDe
pendenciesMojo.java:197) at
org.apache.maven.plugin.dependency.CopyDependenciesMojo.execute(CopyDepende
nciesMojo.java:89) at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildP
luginManager.java:101) at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:
209) ... 29 more
Caused by: java.io.FileNotFoundException:
C:\svn\chat-dashboard\trunk\dashboard-core\target\classes (Access is
denied)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:138)
at
org.codehaus.plexus.util.io.FileInputStreamFacade.getInputStream(FileInputS
treamFacade.java:36) at
org.codehaus.plexus.util.FileUtils.copyStreamToFile(FileUtils.java:1141) at
org.codehaus.plexus.util.FileUtils.copyFile(FileUtils.java:1048) at
org.apache.maven.plugin.dependency.AbstractDependencyMojo.copyFile(Abstract
DependencyMojo.java:192) ... 33 more
[ERROR]
I see several lines in here that seem wrong to me.
1. Caused by: org.apache.maven.lifecycle.LifecycleExecutionException:
Failed to execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.4:copy-dependencies
(copy-dependencies) on project stand-alone: Error copying artifact
from C:\svn\chat-dashboard\trunk\dashboard-core\target\classes to
C:\svn\chat-dashboard\trunk\stand-alone\target\stand-alone-4.4-SNAPSHOT\pack
ages\dashboard-core-4.4-SNAPSHOT.jar
Why is copying from classes? And why is it copying to jar (or is that
just one of the files it is copying to the packages folder)? My pom
for this part is defined as:
execution
idcopy-dependencies/id
phasegenerate-resources/phase
goals
goalcopy-dependencies/goal
/goals
configuration
includeScoperuntime/includeScope
outputDirectory${project.build.directory}/${project.build.finalName}/packa
ges/outputDirectory overWriteReleasestrue/overWriteReleases
overWriteSnapshotstrue/overWriteSnapshots
overWriteIfNewertrue/overWriteIfNewer /configuration
/execution
2. Caused by: java.io.FileNotFoundException:
C:\svn\chat-dashboard\trunk\dashboard-core\target\classes (Access is
denied)
It looks like its trying to find a file in this folder so it can copy
it. This folder does exist. It contains a folder structure of class
files, so at that top folder it just contains a folder. But why is it
copying from here? This folder does not contain the application's
dependencies. That module's artifact is at
C:\svn\chat-dashboard\trunk\dashboard-core\target\dashboard-core-4.4-SNAPSHO
T.jar so it should copy that and all others to
${project.build.directory}/${project.build.finalName}/packages which
it does seem to do. This error seems to be after it does the right
thing with this goal.
3. [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.2:site (default-cli) on
project stand-alone: failed to get report for
org.apache.maven.plugins:maven-surefire-report-plugin: Failed to
execute goal
org.apache.maven.plugins:maven-dependency-plugin:2.4:copy-dependencies
(copy-dependencies) on project stand-alone:
That first line in the log indicates that the error is caused by the
maven-surefire-report-plugin. Failed to get report. So is it
possible that...that plugin is re-executing the copy-dependencies goal
and is doing so in an invalid manor?
-Dave
On Thu, Dec 6, 2012 at 11:06 AM, Hervé BOUTEMY herve.bout...@free.fr
wrote:
if you run with mvn -X and give us the full stack trace, perhaps we can
see
what's going wrong
Le jeudi 6 décembre 2012 06:34:52 David Hoffer a écrit :
Note that the copy-dependencies goal in the stand-alone module is not
really relevant/useful in the site build. Rather it's a key part of
the regular...clean, install, release phases...that module just copies
artifacts and builds an aggregate artifact (i.e. it does not have
source code). But I'm not aware of how to 'turn-off' things like this
just for the site build.
On Thu, Dec 6, 2012 at 6:22 AM, David Hoffer dhoff...@gmail.com wrote:
This happens if I build locally and when built with our CI build
server. When I build locally it will use disk C and the disk is not
full. These folders are just the normal maven build folders so if
there is something using the file...it's a Maven process.
We are using Maven3...perhaps the site build spawns other processes
and there is a conflict between them?
On Thu, Dec 6, 2012 at 5:53 AM, Adrien Rivard adrien.riv...@gmail.com
wrote:
Most probably, it means that one of the file is used by another
application, thus cannot be deleted
Re: Maven site build errors
please read the last two lines F:\work\7832e3bc4d2f257b\dashboard-core\target\classes (Access is denied) Le mercredi 5 décembre 2012 15:00:24 David Hoffer a écrit : I have a multi-module maven build and can't get the site build to work. It's currently failing with this error. The module its failing on, stand-alone, doesn't have any code just packages assemblies, etc. Any ideas what is causing this? Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.2:site (default-site) on project stand-alone: failed to get report for org.apache.maven.plugins:maven-surefire-report-plugin [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.2:site (default-site) on project stand-alone: failed to get report for org.apache.maven.plugins:maven-surefire-report-plugin: Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.4:copy-dependencies (copy-dependencies) on project stand-alone: Error copying artifact from F:\work\7832e3bc4d2f257b\dashboard-core\target\classes to F:\work\7832e3bc4d2f257b\stand-alone\target\stand-alone-4.4-SNAPSHOT\package s\dashboard-core-4.4-SNAPSHOT.jar: F:\work\7832e3bc4d2f257b\dashboard-core\target\classes (Access is denied) - [Help 1] [13:52:12] - 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: Mojo Java 1.5 @Component MavenProject (returns null) vs JavaDoc @parameter expression=${project} works
magic has been done: see http://maven.apache.org/plugin-tools/apidocs/src- html/org/apache/maven/tools/plugin/util/PluginUtils.html#line.40 Le mercredi 28 novembre 2012 18:54:11 Jason van Zyl a écrit : Internally the way @component works is to take the role of component supplied or figure it out. With that role a lookup against the container is executed. The MavenProject is not something that is available from the container because it is not a component. So I doubt it works, unless some magic was done to just make the @Component act on MavenProject's which itself doesn't make sense. It is meant to be a parameter, and that's what it has always been. On Nov 28, 2012, at 6:03 PM, Barrie Treloar baerr...@gmail.com wrote: On Thu, Nov 29, 2012 at 8:49 AM, Jason van Zyl ja...@tesla.io wrote: The MavenProject is not a component that is injected by the container. It's handled by the PluginParameterExpressionEvaluator[1] which looks at all the non-@component things and sets their values once the Mojo instance is constructed. [1]: https://github.com/apache/maven-3/blob/trunk/maven-core/src/main/java/or g/apache/maven/plugin/PluginParameterExpressionEvaluator.java Does that mean our docs are wrong? Do you have an example? I've not used annotations before and I was trying to help someone else's user list question. And unfortunately google returns javadoc matches as well so wading through examples was time consuming and not very enlightening. And the link Olivier sent is using /** * The Maven project. */ @Component private MavenProject project; and is working, but when I tried that it didn't. I'm going to try looking at the pom to see if there are some incorrect versions of dependencies might be causing an issue. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -- Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Mojo Java 1.5 @Component MavenProject (returns null) vs JavaDoc @parameter expression=${project} works
it's confusing for people mastering a lot of things
for normal people, it was really not easy to understand, and not really
documented, neither PluginParameterExpressionEvaluator (which I documented
after I uderstood) nor the '@parameter default-value=${project}
readonly=true' pattern (lots of plugins had expression=${project})
we had a long discussion on the dev list and found that, even if a little
magic, it would be really easier to use:
http://jira.codehaus.org/browse/MPLUGIN-204
the doc of the annotations show these special cases
Regards,
Hervé
Le mercredi 28 novembre 2012 19:00:03 Jason van Zyl a écrit :
That's not right, and confusing. It's not a component.
jvz
On 2012-11-28, at 6:57 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
magic has been done:
see http://maven.apache.org/plugin-tools/apidocs/src-
html/org/apache/maven/tools/plugin/util/PluginUtils.html#line.40
Le mercredi 28 novembre 2012 18:54:11 Jason van Zyl a écrit :
Internally the way @component works is to take the role of component
supplied or figure it out. With that role a lookup against the container
is
executed. The MavenProject is not something that is available from the
container because it is not a component. So I doubt it works, unless some
magic was done to just make the @Component act on MavenProject's which
itself doesn't make sense. It is meant to be a parameter, and that's what
it has always been.
On Nov 28, 2012, at 6:03 PM, Barrie Treloar baerr...@gmail.com wrote:
On Thu, Nov 29, 2012 at 8:49 AM, Jason van Zyl ja...@tesla.io wrote:
The MavenProject is not a component that is injected by the container.
It's handled by the PluginParameterExpressionEvaluator[1] which looks
at
all the non-@component things and sets their values once the Mojo
instance is constructed.
[1]:
https://github.com/apache/maven-3/blob/trunk/maven-core/src/main/java/o
r
g/apache/maven/plugin/PluginParameterExpressionEvaluator.java
Does that mean our docs are wrong?
Do you have an example?
I've not used annotations before and I was trying to help someone
else's user list question.
And unfortunately google returns javadoc matches as well so wading
through examples was time consuming and not very enlightening.
And the link Olivier sent is using
/**
* The Maven project.
*/
@Component
private MavenProject project;
and is working, but when I tried that it didn't.
I'm going to try looking at the pom to see if there are some incorrect
versions of dependencies might be causing an issue.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
To do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
-
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: Mojo Java 1.5 @Component MavenProject (returns null) vs JavaDoc @parameter expression=${project} works
no, we choose to do that for ease of use for the average plugin developer
we had a long discussion on how to ease plugin development, find a better name
than expression, understand that such Maven object injection case is best
written as default-value than expression, and so on...
and actual plugins using @Component for injecting classical MavenProject is
easier than @Parameter( defaultValue=${project} ) even if the former is a
trick
Le mercredi 28 novembre 2012 19:05:10 Jason van Zyl a écrit :
I would remove that from the doco. I assume the @Parameter method still
works and just keep that method.
jvz
On 2012-11-28, at 6:57 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
magic has been done:
see http://maven.apache.org/plugin-tools/apidocs/src-
html/org/apache/maven/tools/plugin/util/PluginUtils.html#line.40
Le mercredi 28 novembre 2012 18:54:11 Jason van Zyl a écrit :
Internally the way @component works is to take the role of component
supplied or figure it out. With that role a lookup against the container
is
executed. The MavenProject is not something that is available from the
container because it is not a component. So I doubt it works, unless some
magic was done to just make the @Component act on MavenProject's which
itself doesn't make sense. It is meant to be a parameter, and that's what
it has always been.
On Nov 28, 2012, at 6:03 PM, Barrie Treloar baerr...@gmail.com wrote:
On Thu, Nov 29, 2012 at 8:49 AM, Jason van Zyl ja...@tesla.io wrote:
The MavenProject is not a component that is injected by the container.
It's handled by the PluginParameterExpressionEvaluator[1] which looks
at
all the non-@component things and sets their values once the Mojo
instance is constructed.
[1]:
https://github.com/apache/maven-3/blob/trunk/maven-core/src/main/java/o
r
g/apache/maven/plugin/PluginParameterExpressionEvaluator.java
Does that mean our docs are wrong?
Do you have an example?
I've not used annotations before and I was trying to help someone
else's user list question.
And unfortunately google returns javadoc matches as well so wading
through examples was time consuming and not very enlightening.
And the link Olivier sent is using
/**
* The Maven project.
*/
@Component
private MavenProject project;
and is working, but when I tried that it didn't.
I'm going to try looking at the pom to see if there are some incorrect
versions of dependencies might be causing an issue.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
To do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
-
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: Mojo Java 1.5 @Component MavenProject (returns null) vs JavaDoc @parameter expression=${project} works
I wish we had this good discussion in may, when we wroked on plugin-tools ease
of use enhancements
I understand your point
And in fact, when I write that the feature was added partly because parameter
default-value=${project} read-only=true, I see I didn't document it
either, now that I'm able to do it because it is absolutely clear in my head
(and wasn't before the work in may)
let's go ahead:
- now that the expressions will be well documented in future Maven versions
(see [1] instead of [2])
- given that I'll add a documentation on the default-value pattern to get
Maven objects, whatever we decide here
I'm ok to deprecate the @component trick in favour of the documentation
written, because the trick can be confusing
tell me if you open a Jira issue, I'll be glad to work on it
Regards,
Hervé
[1] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-
core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html
[2] http://maven.apache.org/ref/3.1-SNAPSHOT/maven-
core/apidocs/org/apache/maven/plugin/PluginParameterExpressionEvaluator.html
Le mercredi 28 novembre 2012 20:19:44 Jason van Zyl a écrit :
How does it help by telling them something factually incorrect? A component
has a specific definition of being an instance created by the container.
On Nov 28, 2012, at 7:23 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
no, we choose to do that for ease of use for the average plugin developer
we had a long discussion on how to ease plugin development, find a better
name than expression, understand that such Maven object injection case
is best written as default-value than expression, and so on...
and actual plugins using @Component for injecting classical MavenProject
is
easier than @Parameter( defaultValue=${project} ) even if the former is
a
trick
Le mercredi 28 novembre 2012 19:05:10 Jason van Zyl a écrit :
I would remove that from the doco. I assume the @Parameter method still
works and just keep that method.
jvz
On 2012-11-28, at 6:57 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
magic has been done:
see http://maven.apache.org/plugin-tools/apidocs/src-
html/org/apache/maven/tools/plugin/util/PluginUtils.html#line.40
Le mercredi 28 novembre 2012 18:54:11 Jason van Zyl a écrit :
Internally the way @component works is to take the role of component
supplied or figure it out. With that role a lookup against the
container
is
executed. The MavenProject is not something that is available from the
container because it is not a component. So I doubt it works, unless
some
magic was done to just make the @Component act on MavenProject's which
itself doesn't make sense. It is meant to be a parameter, and that's
what
it has always been.
On Nov 28, 2012, at 6:03 PM, Barrie Treloar baerr...@gmail.com wrote:
On Thu, Nov 29, 2012 at 8:49 AM, Jason van Zyl ja...@tesla.io wrote:
The MavenProject is not a component that is injected by the
container.
It's handled by the PluginParameterExpressionEvaluator[1] which looks
at
all the non-@component things and sets their values once the Mojo
instance is constructed.
[1]:
https://github.com/apache/maven-3/blob/trunk/maven-core/src/main/java
/o
r
g/apache/maven/plugin/PluginParameterExpressionEvaluator.java
Does that mean our docs are wrong?
Do you have an example?
I've not used annotations before and I was trying to help someone
else's user list question.
And unfortunately google returns javadoc matches as well so wading
through examples was time consuming and not very enlightening.
And the link Olivier sent is using
/**
* The Maven project.
*/
@Component
private MavenProject project;
and is working, but when I tried that it didn't.
I'm going to try looking at the pom to see if there are some incorrect
versions of dependencies might be causing an issue.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Thanks,
Jason
--
Jason van Zyl
Founder CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
To do two things at once is to do neither.
-- Publilius Syrus, Roman slave, first century B.C.
-
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
Re: Maven Dependency Type
uyou can have a look at http://maven.apache.org/ref/3.1-SNAPSHOT/maven- core/artifact-handlers.html for a reference of default types and classifiers Regards, Hervé Le jeudi 25 octobre 2012 20:09:58 John Kramer a écrit : Hey guys, I have a question regarding the maven dependencies section. In order to put a dependency on a test jar, is it correct to specify typetest-jar/type or typetest/type? I specified a dependency on project bar from project foo using typetesttest in a dependency section and the maven eclipse plugin ran successfully and eclipse set up my projects so that the module recognizes, but mvn package gives the following error: [ERROR] Failed to execute goal on project statistics: Could not resolve dependencies for project com.mojiva:foo:jar:1.9.0-SNAPSHOT: Could not find artifact com.mojiva:bar:test:1.9.0-SNAPSHOT in mojiva If I change it, to test-jar, the error goes away. I know I have used typetest/type in the past and not had an issue. Did it change? Also, I can't find the documentation on this. A pointer to the docs would be helpful. Thanks to all! John Kramer email: jkra...@mojiva.commailto:jkra...@mojiva.com mobile: 314.435.2370 skype: kramer.mojiva twitter: @KramerKnowsTechhttps://twitter.com/KramerKnowsTech 0xCAFEBABE0032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven archetype for creating dynamic multi module project
schema on http://maven.apache.org/archetype/maven-archetype-plugin/ explains the full cycle what are you trying to create: an archetype project by hand (instead of from a sample project)? or a project from an existing archetype? Regards, Hervé Le mardi 2 octobre 2012 08:34:55 Nisha a écrit : Hi, Could anyone please help me with maven archetype. I am new to maven and I am trying to create a new dynamic multi module project using maven archetype api. Everywhere they have just mentioned about creating from an existing project but I need create a project structure from command line. Thanks tonn Nisha -- View this message in context: http://maven.40175.n5.nabble.com/maven-archetype-for-creating-dynamic-multi -module-project-tp5724691.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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: Version ranges not working
yes, please share experience about ranges: when it is useful, how, and so on we really need to write this Guide to using version ranges https://jira.codehaus.org/browse/MNG-1368 so we stop telling ranges are a bad practice but tell what they are useful for Regards, Hervé Le samedi 29 septembre 2012 12:16:43 Michael McCallum a écrit : I agree with Richard, as they exist now in maven version ranges can be used very effectively. I'm happy to post example projects if you want to know how to do it. If you want 'repeatability' then ranges might not be for you but if you want determinism and releasability then ranges are for you. Its just a matter of having good process and leveraging the tools to there greatest effect, rather than trying to make the tool perfect. On Sat, Sep 29, 2012 at 11:16 AM, Richard Vowles rich...@bluetrainsoftware.com wrote: You may then be surprised to know that there are many of us for whom version ranges in Maven work perfectly. Ideally Maven could be more clever and understand that [1.6.2] is already on the local system and the metadata checking for ranges doesn't need to be re-fetched, but that is merely an optimisation. SNAPSHOTS work perfectly, ranges work perfectly, and SemVer is a silly waste of space. Richard On Sat, Sep 29, 2012 at 2:07 AM, David Hoffer dhoff...@gmail.com wrote: I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. -- --- Richard Vowles, Grails, Groovy, Java Consistency is the last refuge of the unimaginative - Oscar Wilde ph: +64275467747, linkedin, twitter:richardvowles get 2Gb shared disk space in the cloud - Dropbox, its incredibly useful! - http://tinyurl.com/cmcceh podcast: http://www.illegalargument.com
Re: Version ranges not working
Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit : I have created a ticket - http://jira.codehaus.org/browse/MNG-5353 thank you I changed it from Bug to Wish: no, nobody ever asked for such a behaviour, it's really a new idea AFAIK which BTW seems a good enhancement IMHO now we need to check with people using ranges that it is ok for them: if anybody can think of a problem, please share Regards, Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges not working
Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven. You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. a range tells about a constraint then choosing a precise version between the multiple choices that match constraints is not about the range but about what is usually called conflict resolution This term is ok when it's about changing preferred version (ie when versions are not defined as range but as simple version, which means preferred version) but that term doesn't show that when it's about ranges, it's not about conflict but about choosing one version between the multiple valid choices: do you prefer the most recent? even if it is a snapshot or an alpha? or if the most recent is an alpha, you prefer to stick with stable version? IMHO, during development, you can want to test latest alpha SNAPSHOT, but when doing a release, you'll prefer stable versions What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... sure, there is something to create here, but IMHO not into version ranges: into conflict resolution specification and switch (with CLI or IDE) LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Users List users@maven.apache.org Cc: Sent: Saturday, September 29, 2012 5:06 AM Subject: Re: Version ranges not working yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online if I don't want to accept new updates since it will be changing on a regular basis. Using version ranges would have been a more elegant solution as it would give me more control over what versions I depend on during development. Because it wasn't fixed and we had to do the workaround I have not been close to this issue anymore...its been like 5 years or more. But the short answer is it should be fixed and it can/could be useful as some have indicated in this discussion. -Dave On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 28/09/2012 3:17 AM, Jesse Long wrote: Without version ranges, how do I write a library that works with SLF4J version 1.5.*, but does not work with SLF4J 1.6.*? Do I depend on, say, version 1.5.11? Then when a user depends on my library, and on slf4j-api directly, specifying slf4j-api version 1.6.0 in his pom, Maven will link in 1.6.0. So that is pretty useless
Re: Version ranges not working
yes, that's my point: ranges are the same, but version to choose are different the solution won't come from ranges tweak but conflict resolution improvements Le samedi 29 septembre 2012 17:31:29 Stephen Connolly a écrit : The issue I see is that there is a difference with ranges between build time and run time. In general at build time you want the lowest version in the range (assuming the api is versions correctly) to ensure you are compatible with the smallest set of api method signatures. At run time you want the highest as it has the most big fixes in theory. At test time you ideally want every version. But that matrixes out to an impossible combinatorial. On Saturday, 29 September 2012, Hervé BOUTEMY wrote: Le samedi 29 septembre 2012 09:46:28 Mark Struberg a écrit : I thought about mathematical ranges as well, and the outcome for me personally that a strict mathematical time vector interpretation makes no sense for maven. You have a library in version 1.7.0 which fits your project. Somewhen in the development of 1.8.0-SNAPSHOT they introduce a binary incompatible change. But 1.7.2, 1.7.3 1.7.4, ... might wirk fine still. Also: for most dependencies you only like to get released versions via your version range. But as I read here some use this internally as well and like to get SNAPSHOTS resolved. a range tells about a constraint then choosing a precise version between the multiple choices that match constraints is not about the range but about what is usually called conflict resolution This term is ok when it's about changing preferred version (ie when versions are not defined as range but as simple version, which means preferred version) but that term doesn't show that when it's about ranges, it's not about conflict but about choosing one version between the multiple valid choices: do you prefer the most recent? even if it is a snapshot or an alpha? or if the most recent is an alpha, you prefer to stick with stable version? IMHO, during development, you can want to test latest alpha SNAPSHOT, but when doing a release, you'll prefer stable versions What about simply writing up what people like to have and then implement a new mechanism? I could even think about regexp based versioning... sure, there is something to create here, but IMHO not into version ranges: into conflict resolution specification and switch (with CLI or IDE) LieGrue, strub - Original Message - From: Hervé BOUTEMY herve.bout...@free.fr To: Maven Users List users@maven.apache.org Cc: Sent: Saturday, September 29, 2012 5:06 AM Subject: Re: Version ranges not working yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online
Re: Version ranges not working
Anything else than pure numbers is a candidate to be broken somehow.
yes
Maven defines some qualifiers: see [1] for exact list (notice the synonyms,
even
for the release, that can be ga or final)
I chose the qualifiers from what I could see that didn't have multiple
interpretations: yes, MR is not a good candidate
Even the a and b qualifiers, which are actually synonyms for alpha and
beta, are sometimes used for maintenance release: well known example is
javax.transaction 1.0.1B which is not a beta but maintenance release
But the choice was to ignore such exceptions and support a and b for alpha
and beta shortcuts
Regards,
Hervé
[1]
http://maven.apache.org/ref/3.0.4/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
Le vendredi 28 septembre 2012 09:09:19 Mark Struberg a écrit :
Sad but true.
An example:
There are projects which use 1.0-MR1 as Milestone Release
which gets released _before_ 1.0 final.
And there are other projects which use 1.0-MR1 as Maintenance Release
which obviously gets released _after_ 1.0 final.
Anything else than pure numbers is a candidate to be broken somehow.
LieGrue,
strub
- Original Message -
From: Stephen Connolly stephen.alan.conno...@gmail.com
To: Maven Users List users@maven.apache.org
Cc:
Sent: Friday, September 28, 2012 1:03 AM
Subject: Re: Version ranges not working
My experience with versions-maven-plugin would show different, but each to
their own
On 27 September 2012 23:56, Paul French paul.fre...@kirona.com wrote:
I have to disagree. Version ranges are very useful to us especially with
artifacts we control where we use semantic versioning and api analysis
to
enforce this.
Artifacts we don't control the versioning of e.g SLF4J we nail down the
version we use.
Our product POM's can have 100's of version ranged artifacts
If we could plugin a version range class into maven (maven would ship
with
a version range class with the rules it uses now), at least I would then
have a choice to replace it with an implementation I'm happier with.
Anyway it works for us as it is now, so I'm not going to lose any sleep
over it.
Cheers
On 27/09/2012 23:36, Stephen Connolly wrote:
Well that is a recipe for disaster. rules only make sense within the
scope
of the artifacts they apply to.
This is kind of why version ranges are next to useless from a practical
PoV
anyway
On 27 September 2012 23:05, Paul French paul.fre...@kirona.com
wrote:
I would only want the same version rules applied to all artifacts, not
on
a per artifact basis, that would be a nightmare! I understand that
people
who produce artifacts have their own versioning rules. However we
can
take
that into account in our version ranging.
Usually for 3rd party artifacts we have a very narrow version range
since
we cannot trust the producer of that artifact not to break their
current
API in later versions unless they support semantic versioning.
On 27/09/2012 22:29, Stephen Connolly wrote:
when is that class applied?
each dependency would have its own comparator, as each
dependency has
its
own versioning rules.
and then don't start on epoch's (i.e. where the
versioning rules change
from under your feet mid sequence
It's tempting... but dangerous... the closest I have come
up with is the
rulesets hack from versions-maven-plugin @ mojo... but even
that has
issues... hence why I haven't pushed it further.
-Stephen
On 27 September 2012 22:19, Paul French
paul.fre...@kirona.com wrote:
Okay I see the problem.
How about allowing a user to plugin a Version class that
implements
Comparator
class MavenVersion implements
ComparableMavenVersion
{
public int compareTo(MavenVersion o)
{
// your implementation
}
}
Then we can all do whatever we need.
On 27/09/2012 21:40, Hervé BOUTEMY wrote:
I understand that many people get caught
But what do you expect from [1.7,1.8]?
And [1.7,1.8-beta)?
The actual semantic is pure mathematical range,
including or excluding
an
extreme
since
1.8-alpha1.8-beta-1.8-rc1.**8-SNAPSHOT1.8, it's pure
math
IMHO, anything that doesn't conform mathematical
range will have some
unexpected behaviour sometime
Yes, people need to learn that they usually want
[1.7,1.8-alpha-SNAPSHOT)
if
they want to be precise. Or approximations:
[1.7,1.8-a), [1.7,1.7.999]
Or we need to create another notation and define its
semantics
precisely
Regards,
Hervé
Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit
+1
I agree with Jesse
Re: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do so, it's not a *range* any more but a range + a filter (1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english) and actual discussion helps me dig into other ideas that could be useful: IIUC, it can be useful to exclude SNAPSHOTs from ranges, yes, but alphas and beta too, no? But I'm not sure about the use case (and Guide to using version ranges still needs to be written: https://jira.codehaus.org/browse/MNG-1368) I understand that when a library is at 1.9 and someone needs old 1.8-, he implictely wants releases, not alpha nor SNAPSHOTS But if 1.8 is still not out, and there is still work on 1.7.x, we need to accept *latest* 1.7.x whatever its maturity level is Really , excluding version from a mathematical range is another operation that needs some specification and probably something more expressive than [min,max] Regards, Hervé Le vendredi 28 septembre 2012 08:07:21 David Hoffer a écrit : I find this topic interesting for a couple of reasons. I was one of the original posters of this topic and created some of the relevant JIRA issues regarding it. However one of the problems is that since this issue was never fixed...and sadly seems never will be...we had to abandon the use of version ranges. I do not agree they are a bad idea. I think they could have been a very useful feature if implemented as originally proposed. (The fundamental problem was that they did not exclude SNAPSHOTS as originally intended/stated.) Effectively we had to work around the lack of version ranges by just building against SNAPSHOTS instead (I'm talking about internal code here). So effectively the SNAPSHOT became our version range. One of the problems of this approach is now I have to toggle between going offline/online if I don't want to accept new updates since it will be changing on a regular basis. Using version ranges would have been a more elegant solution as it would give me more control over what versions I depend on during development. Because it wasn't fixed and we had to do the workaround I have not been close to this issue anymore...its been like 5 years or more. But the short answer is it should be fixed and it can/could be useful as some have indicated in this discussion. -Dave On Fri, Sep 28, 2012 at 6:42 AM, Ron Wheeler rwhee...@artifact-software.com wrote: On 28/09/2012 3:17 AM, Jesse Long wrote: Without version ranges, how do I write a library that works with SLF4J version 1.5.*, but does not work with SLF4J 1.6.*? Do I depend on, say, version 1.5.11? Then when a user depends on my library, and on slf4j-api directly, specifying slf4j-api version 1.6.0 in his pom, Maven will link in 1.6.0. So that is pretty useless to me. If I find a way to enforce version 1.5.11. Then I am loosing the ability to upgrade to any future version 1.5.*. I am not sure how version ranges will help you in this case. Your mythical user is overriding your version 1.5.* with 1.6.* so he will be in trouble using your library regardless of what you put in your dependency. If your library is clearly documented as not being compatible with versions after 1.5.*, then the user is responsible for making sure that nothing brings in a later version of slf4j. You had better write a big note about your restriction since most of us will just put an exclusion on your transitive dependency for slf4j and run with the version that we want. There are not many good libraries that are not upwards compatible and it is generally safe to run with the latest version of everything. The good library authors will change the artifact name if the new version is not capable of supporting code written for the previous version. I have yet to see a good case for version ranges and it seems that they cause these sort of discussions every year or so. Ron Cheers, Jesse On 28/09/2012 01:20, Baptiste MATHUS wrote: +1. Version ranges are basically just a bad practice in my experience. I mostly don't see any interest apart from being able to see a normally passing build suddenly going rogue because you somehow had a dependency update somewhere in the dependency tree. (I wrote something similar in that comment http://www.sonatype.com/**people/2012/08/download-it-** all-at-once-a-maven-idea/#**comment-635524577http://www.sonatype.com/pe ople/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577 ) So, please, Maven users, don't use them. It's like having scripts inside your pom.xml, it might seem sexy and powerful, but it's dangerous. Nail down a version, and upgrade explicitly when you need to and/or are ready to. You'll be very happy that way and your build'll stay green. Cheers
Re: Version ranges not working
Le vendredi 28 septembre 2012 09:52:50 Jesse Long a écrit : My point is really about exclusive upper bounds. ok, now I'm starting to see the precise idea and believe it can avoid breaking subtle logic [1.7,1.8) could exclude anything starting with 1.8: betas, alphas, alphas- alphas, snapshots (but this one is a consequence of excluding alphas since alpha snapshot) it's still a mathematical range, just the meaning of the upper bound is different and intended as more natural Changing this behaviour would need good documentation and communication, but seems feasible without wrecking havoc You'll need to create a Jira issue, perhaps have a vote on the list to check that nobody finds big issues with this change (or see the benefit of breaking past-compatibility) I expect that [1.7,1.8] should contains 1.7.0 and above (no snapshots and prerelease for 1.7.0) and 1.8.* release versions. ouch, 1.8.* release versions in [1.7,1.8]? Service packs (1.8-sp1), why not, even if not immediately natural but 1.8.1, no, sorry :) Having said that, I dont really care too much about this use case and have not thought much about it. I have thought about exclusive upper bounds, and I think my proposal is the best solution. [1.7,1.8-beta): Like I said, there is no sense in that at all. Why would a developer want to include 1.8-alpha, but not 1.8-beta? Indeed, why would he want 1.8.0-alpha4 and not 1.8.0? I think we should not make the majority of use cases, where the exclusive upper bound defines a compatibility break according to semver, to suffer because some users will do weird things like [1.7,1.8-beta). [1.7,1.8-beta) is a valid input however, so we should make a plan for it. +1 We could just say that if the upper bound has a qualifier, compare as per usual. If the exclusive upper bound has no qualifier, then ignore the qualifier of the version being compared to the upper bound. So, in [1.7.0,1.8.0), 1.8.0 is outside the range and so is 1.8.0-alpha1. In [1.7.0,1.8.0-beta) 1.8.0 is outside the range, 1.8.0-beta3 is outside the range and 1.8.0-alpha4 is inside the range. I don't think we need special handling: with exclude anything starting with semantics and the version comparison algorithm, IMHO, we have the rule that can be applied to any form of upper bound and stays completely logic and previsible The more I dig into this semantic, the more I like it :) A new question: what about exclusive lower bound? would this semantic apply too? (I'm tired for the moment, just throwing the question without having really thought about consequences) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Version ranges not working
I understand that many people get caught But what do you expect from [1.7,1.8]? And [1.7,1.8-beta)? The actual semantic is pure mathematical range, including or excluding an extreme since 1.8-alpha1.8-beta-1.8-rc1.8-SNAPSHOT1.8, it's pure math IMHO, anything that doesn't conform mathematical range will have some unexpected behaviour sometime Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT) if they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999] Or we need to create another notation and define its semantics precisely Regards, Hervé Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit : +1 I agree with Jesse. A version range like [1.7,1.8) should exclude any artifact that starts with 1.8 Then maven (or aether) would respect semantic versioning rules. We use version ranges/semantic versioning and API analysis to ensure our artifacts are versioned correctly. Sometimes we get caught out by what Jesse outlined below. On 27/09/2012 15:51, Stephen Connolly wrote: On 27 September 2012 14:41, Jesse Long j...@unknown.za.net wrote: Dear Maven Community, I am writing to beg you to fix the problems with the version ranges in Maven 3.0.5, specifically regarding the defining compatible version ranges. I am using Maven 3.0.4. I have a simple project that depends on org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define the version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api version 1.6.0-alpha2 is linked in. Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was released it would probably break again. This is all too counter-intuitive. The current version of SLF4J is 1.7.1. If my project was to be built against it, knowing that there is a likelihood of an incompatible change being introduced in 1.8.0 (SLF4J does not adhere to SemVer), I would like to define my version range for slf4j-api as [1.7.0,1.8.0). I I think you do [1.7.0,1.8.0-!) but that might just include 1.8.0-SNAPSHOT have no way of knowing before the time what type of -RC0, -alpha2 qualified releases will be made for 1.8.0, so I can only exclude 1.8.0. However, when 1.8.0-alpha2 is released with incompatible changes, my build will immediately be broken. I could depend on version 1.5.11 directly, without using a version range, but Maven considers this a soft version dependency and will ignore it as needed. It is apparent that there is no reliable way to define a compatibility range in Maven. I feel that this should be a major concern to all Maven users and developers. It would be a shame for all the effort made by the Maven community to make software builds stable and reproducible to be undermined by consistent, predictable breakage described above. I have read in mailing list archives that the suggested way of excluding all 1.8.0 pre-release version is to define an exclusive upper bound as 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user to wish to include 1.8.0-SNAPSHOT and not 1.8.0. My proposal is that the qualifier is ignored when comparing a version to the version number declared in an exclusive upper bound. ie. 1.6.0-xyz should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore considered to fall outside of the version range. Importantly, it should only be for the special case of comparing to the version number in an exclusive upper bound. If the powers that be see fit, an exception could be made for service pack qualifiers, which according to one web page on Maven version ordering I read, should be sorted after the release, although I would prefer to see Maven more closely aligned to SemVer, where all qualified version numbers are considered pre-release versions. I consider 1.7.2 a better version number than 1.7.1-sp1. Ultimately, I would like to be able to make things as easy as possible for users depending on a library that adheres to SemVer, to define a compatibility range like: [1.4.0,2.0.0). I see no reason why it should not be as easy as that. Please consider fixing this soon. I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The signup link on this page displays an error: http://maven.apache.org/users/ **getting-help.html http://maven.apache.org/users/getting-help.html Jira issue MNG-3092, reported over 5 years ago, is related to this issue, but the initial report is for a similar issue, not this issue. The issue I describe above is reported and discussed in the comments for MNG-3092 though.
Re: Version ranges not working
Le jeudi 27 septembre 2012 15:41:25 Jesse Long a écrit : I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The signup link on this page displays an error: http://maven.apache.org/users/getting-help.html thanks for the report I updated the link, should be visible in the page soon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Project Info Reports Plugin 2.5.1 Released
The Maven team is pleased to announce the release of the Maven Project Info
Reports Plugin, version 2.5.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:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-project-info-reports-plugin/artifactId
version2.5.1/version
/plugin
Release Notes - Maven Project Info Reports Plugin - Version 2.5.1
Bug
* [MPIR-250] dependency-info packaging information broken: displays
${project.packaging
* [MPIR-249] new dependency-info report not added to goals index page
* [MPIR-248] NPE while DependenciesReport
* [MPIR-187] Usage of other(internal) TLD
Improvement
* [MPIR-239] Brazillian Portuguese translation
Enjoy,
-The Maven team
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Any ETA for a m-project-info-report-p 2.5.1 release?
I was trying to fix as much issues as posible before releasing It seems we're now at the maximum feasible for the moment (MPIR-251 will be postponed) I'll start the release tonight Regards Hervé Le samedi 25 août 2012 18:45:15 Olivier Lamy a écrit : 2012/8/25 Dennis Lundberg denn...@apache.org: On 2012-08-23 10:16, myron0...@gmx.net wrote: Hi, just wanted to know, if and when there's a release planned. It is currently being voted on. ? nope dependency plugin is on vote. any volunteer for m-p-i-r ? Tested the 2.6-SN and it worked fine so far. Really want the working new DependencyInfo report :) Or is there anything from the unscheduled items we should wait for? TIA Myron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - 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: MavenProject/MavenSession not injected when executing plugin from a plugin
the most interesting code is probably in maven-reporting-executor
http://maven.apache.org/shared/maven-reporting-exec/, which is used by m-site-
p
Regards,
Hervé
Le jeudi 9 août 2012 12:29:44 Olivier Lamy a écrit :
Hi
Have a look at how we solve that in the site plugin sources
That will probably help you.
--
Olivier
Le 9 août 2012 09:29, Kinai User ki...@live.nl a écrit :
Hi there,
I have developed a plugin which can execute other Maven plugins depending
on
certain properties available in a project.
The process is like this:
1. Maven build starts
2. Plugin A is triggered which has several executions defined. Depending
on
properties in the project on hand a execution is triggered
3. Plugin B (or C, D etc) will be triggered.
The problem is I do not have access to the MavenProject and MavenSession
in
Plugin B (or C, D) because these are not injected resulting in
NullPointerExceptions. The BuildPluginManager however is correctly
injected
(however not needed in this plugin but added it to test the mechanism).
I'm using the same syntax in Plugin A and there both MavenProject and
MavenSession are injected.
Some code examples:
Plugin A executing other plugins:
private void executePlugin ( Plugin plugin, String executionId, String
goal ) throws MojoExecutionException
{
try
{
ListRemoteRepository repositories =
session.getCurrentProject().getRemoteProjectRepositories();
MojoDescriptor mojoDescriptor =
pluginManager.getMojoDescriptor(plugin, goal, repositories,
session.getRepositorySession());
MojoExecution mojoExecution = new MojoExecution( mojoDescriptor,
executionId );
getLog().info( Executing goal + goal + within execution +
executionId + for plugin + plugin );
pluginManager.executeMojo(session , mojoExecution);
}
catch ( Exception e )
{
throw new MojoExecutionException( Error executing plugin +
plugin + with execution id +
executionId, e );
}
}
Plugin B
/**
* Goal which updates the VersionIF.java with the current version.
* @goal updateVersion
* @phase process-sources
*
*/
public class VersionIFMojo extends AbstractMojo {
/**
* The Maven project.
*
* @parameter expression=${project}
*/
private MavenProject project;
/**
* The Maven Session Object
*
* @parameter expression=${session}
* @readonly
*/
protected MavenSession session;
/**
* Plugin manager used to invoke plugin executions.
*
* @required
* @component
*/
private BuildPluginManager pManager;
...
All worked well when using Maven 2 but after migrating to Maven 3 builds
stopped working.
Can somebody help me resolving this issue?
Thank you
Kind regards,
Richad
--
View this message in context:
http://maven.40175.n5.nabble.com/MavenProject-MavenSession-not-injected-wh
en-executing-plugin-from-a-plugin-tp5716570.html Sent from the Maven -
Users mailing list archive at Nabble.com.
-
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] Maven Maven Project Info Reports Plugin 2.5 Released
The Maven team is pleased to announce the release of the Maven Project Info Reports Plugin, version 2.5 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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.5/version /plugin Release Notes - Maven Project Info Reports Plugin - Version 2.5 Bug * [MPIR-245] blacklisted column in dependencies location is rendered without header * [MPIR-244] With Maven 3, Dependency Repository Locations in dependencies report shows my local repository manager id and url instead of public repository info * [MPIR-237] Unexpected download * [MPIR-228] HTML code detection in license content too precise: doesn't detect EPL at http://www.eclipse.org/legal/epl-v10.html is HTML Improvement * [MPIR-236] Create a new report to show how to include the module in different build systems New Feature * [MPIR-227] add an index listing all licenses at page start Task * [MPIR-246] use maven-plugin-tools' java 5 annotations Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Dependency Plugin 2.5 Released
The Maven team is pleased to announce the release of the Maven Dependency Plugin, version 2.5 The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location. http://maven.apache.org/plugins/maven-dependency-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.5/version /plugin Release Notes - Maven Dependency Plugin - Version 2.5 ** Bug * [MDEP-297] - Documentation Problem of an attribute * [MDEP-352] - Attributes for ArtifactItems referenced in AbstractFromConfigurationMojo.java are incorrect (documentation patch attached) * [MDEP-356] - maven dependency plugin should use maven 3 dependency resolver, aether ** Improvement * [MDEP-286] - Typo in documentation * [MDEP-339] - tree mojo doesn't work with maven3 * [MDEP-344] - Documentation for dependency:tree goal is incorrect * [MDEP-357] - use plugins annotations ** Task * [MDEP-363] - The plugin should not write debug messages to 'System.out'. Enjoy, -The Maven team
Re: pluginManagement for reporting plugins
the pluginManagement section is used for reports only when run with Maven 3, but not supported by Maven 2 Notice this has nothing to do with the new configuration format: this new format doesn't add any feature, it's only an implementation detail made visible to users, and it's even more limited that previous format because inheritence isn't available. So it's really not for users, only for internal injection of reports into the site plugin. Regards, Hervé Le dimanche 22 juillet 2012 22:08:22 Anders Hammar a écrit : No, it's not possible to manage the version of reporting plugins in the reporting section through pluginManagement. However, if you're using Maven 3 and maven-site-plugin 3.x, you can take advantage of the new version resolution: http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#Version_Resol ution The text doesn't say, but this *might* require that you use the new configuration format: http://maven.apache.org/plugins/maven-site-plugin/maven-3.html#New_Configura tion_Maven_3_only_no_reports_configuration_inheritance /Anders On Sun, Jul 22, 2012 at 9:06 PM, Radim Kolar h...@filez.com wrote: Its possible to manage version of reporting plugins? I can get version management work for build plugins, but not for reporting. - 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: Writing site documenation with eclipse
choosing format is a question of taste: some prefer apt, some prefer xdoc, you'll have to make your own choice for the editor, there is a good Doxia Eclipse plugin [1] It help writing wiki syntax, or preview, but there is nothing tied to code references. Regards, Hervé [1] http://maven.apache.org/doxia/doxia-ide/eclipse/usage.html Le lundi 16 juillet 2012 10:45:44 Jan Torben Heuer a écrit : I'm starting to write documentation for my maven project. Which format (apt,xdoc,..?) and which editor is available for eclipse? The documentation is very code-centric so any tool that helps me refering to Class names (and even validates it) would be helpful. Also, xDoc != XDoc, right? https://github.com/RvonMassow/xDoc/blob/master/README.textile http://maven.apache.org/doxia/references/xdoc-format.html Cheers, Jan - 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: Writing site documenation with eclipse
Le lundi 16 juillet 2012 10:13:06 Jesse Farinacci a écrit : Greetings, On Mon, Jul 16, 2012 at 9:13 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: for the editor, there is a good Doxia Eclipse plugin [1] [1] http://maven.apache.org/doxia/doxia-ide/eclipse/usage.html Except that the Eclipse installation sites don't work.. http://maven.apache.org/doxia/doxia-ide/eclipse/eclipse ok, this one isn't here https://builds.apache.org/view/M-R/view/Maven/job/doxia-eclipse-editor/ws/do xia-ide-eclipse/eclipse-plugins/features/org.apache.maven.doxia.ide.eclipse. feature/target/site/ but this one is working perfectly for me And it isn't in Eclipse Marketplace.. do you know how to add something to Eclipse Marketplace? -Jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Plugin Plugin 3.1 Released
The Maven team is pleased to announce the release of the Maven Plugin Plugin, version 3.1. This version fixes mostly the support of Java annotations for Maven plugins ( http://maven.apache.org/plugin-tools/maven-plugin-plugin/examples/using- annotations.html ) 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. http://maven.apache.org/plugin-tools/maven-plugin-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-plugin-plugin/artifactId version3.1/version /plugin Release Notes - Maven 2.x Plugin Tools - Version 3.1 ** Bug * [MPLUGIN-208] - HelpMojo class generated by helpmojo goal uses deprecated annotations * [MPLUGIN-210] - NPE in generated help mojo with M2 when no goal has description * [MPLUGIN-213] - NullPointerException in descriptor goal * [MPLUGIN-214] - generated descriptor for Maven object components is not like previous versions * [MPLUGIN-215] - role-hint and configuration generated with empty values * [MPLUGIN-216] - default dependency resolution set to RUNTIME * [MPLUGIN-217] - HelpMojo (always) contains description for the maven- plugin-plugin * [MPLUGIN-218] - Tag 'since' not recognized in the plugin model ** Task * [MPLUGIN-209] - use maven-plugin-tools' java 5 annotations Have Fun, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can't make maven-plugin-testing-harness work...
I tried to build the project but got compilation failures [INFO] Compilation failure /tmp/opennms-maven-plugins/features-maven- plugin/src/main/java/org/opennms/maven/plugins/karaf/FeatureBuilder.java: [79,9] error: no suitable method found for addBundle(String,int,null,null) Regards, Hervé Le lundi 4 juin 2012 10:29:05 Benjamin Reed a écrit : I'm trying to write a maven plugin. I've added maven-plugin-testing-harness to my project as a test dependency, and created a very simple test that right now just tries to load a pom whose only content is a plugin section to load the plugin. If I have it load like this: plugin groupIdorg.opennms.maven.plugins/groupId artifactIdfeatures-maven-plugin/artifactId version1.0-SNAPSHOT/version /plugin ...it bombs with this exception: org.apache.maven.plugin.testing.ConfigurationException: Cannot find a configuration element for a plugin with an artifactId of features-maven-plugin. at org.apache.maven.plugin.testing.AbstractMojoTestCase.extractPluginConfigurat ion(AbstractMojoTestCase.java:466) I thought the configuration section of a plugin was supposed to be optional. However, if I add configuration/configuration after the version tag above, it gives me a new error: org.codehaus.plexus.component.repository.exception.ComponentLookupException: java.util.NoSuchElementException role: org.apache.maven.plugin.Mojo roleHint: org.opennms.maven.plugins:features-maven-plugin:1.0-SNAPSHOT:generate-featur es-xml at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.jav a:257) ...am I doing something wrong? Seems like the test framework is breaking on the simplest things, I'm not sure how to start out if I can't even unit test this. Code is here: https://github.com/RangerRick/opennms-maven-plugins/blob/features-maven-plug in/features-maven-plugin Test is at: https://github.com/RangerRick/opennms-maven-plugins/blob/features-maven-plug in/features-maven-plugin/src/test/java/org/opennms/maven/plugins/karaf/Gener ateFeaturesXmlMojoTest.java - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
