FW: How to include @inheritDoc from a dependent jar

2014-01-15 Thread Mikael Petterson
Hi,

New try :-)

I have the following:

Interface in dependency jar javadoc:

/**
 * Deletes the object found at the specified location.
 * 
 * @param Object any type of object
 * @throws InvalidObjectException lots of text
 * @throws NoSuchObjectException lots of text
 */
public void delete (Object object)throws throws InvalidObjectException, 
NoSuchObjectException;

Implementing class:

/**
 * {@inheritDoc}
 */
@Override
public void delete(Object object) throws InvalidObjectException, 
NoSuchObjectException {
//implementation of delete
}

Is this correct or?   Since this will not produce any javadoc for 
implementation of delete ( last code).

Do I need to do anything special in the maven javadoc plugin?


Br.

//mike

-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com]
Sent: den 14 januari 2014 13:27
To: users@maven.apache.org
Subject: RE: How to include @inheritDoc from a dependent jar

  


 From: mikael.petter...@ericsson.com
 To: users@maven.apache.org
 Subject: How to include @inheritDoc from a dependent jar
 Date: Tue, 14 Jan 2014 12:14:21 +
 
 Hi,
 
 We are building a maven site that will contain javadoc for our AppX api ( jar 
 file).
 AppX depends on a few other jar files ( that we have built using maven) . One 
 dependency jar contain an interface with javadoc and we have a class 
 implementing it, in AppX.
 AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
 
 When I use the following under report
 
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version2.8.1/version
 /plugin
 
 But when I open up the javadoc for my Appx and look at the class implementing 
 the interface there is no javadoc. What am I missing?

MG@Inheritdoc pulls Javadoc comments @comment @author @param @throws 
MG@return from Implemented interface If you have none of the Javadoc 
MGtags in the corresponding base method of implemented interface then 
MGAppX class will not be able to 'inherit' those Javadoc attributes
 
 Br,
 
 //mike
The longest journey is the the journey inwards..Of him who has chosen his 
dentiny..Who has started upon his quest for the source of his being Dag 
Hammarskjold
  

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



war + webapp dependency classifier

2014-01-15 Thread Adrien Ruffié
Hello all,

I have maven 3

I have a webapp which derived from a first webapp, I have read this article:

http://ovaraksin.blogspot.fr/2011/09/inheritance-in-maven-based-web-projects
.html

But when I try to done following command, mvn clean package or a simple
mvn dependency:tree I get the following error:

[ERROR] Failed to execute goal on project mycompany-ci: Could not resolve
dependencies for project com.mycompany:mycompany-ci:jar: 001-SNAPSHOT: Could
not find artifact com.mycompany:mycompany-webapp:war:webapp:003 in central
(http://192.168.1.160:8081/artifactory/libs-release) - [Help 1]

However I have 3 artifacts inside libs-release-local of my artifactory:
mycompany-webapp-003-classes.jar
mycompany-webapp-003.jar
mycompany-webapp-003.pom
mycompany-webapp-003.war

I attached also my pom.xml of the second webapp, and below a extract of my
first webapp (the base webapp)

parent
groupIdcom. mycompany /groupId
artifactIdmycompany-parent/artifactId
version-003/version
relativePath../pom.xml/relativePath
/parent

artifactId mycompany-webapp/artifactId
packagingjar/packaging


Do you have an idea of the problem ?

!-- ** 
	* Copyright (c) 2000-2011 E-DEAL * * E-DEAL S.A. * 41, rue Périer * 92120 
	Montrouge * France * * T: +33 (0)1 73 03 29 80 * F: +33 (0)1 73 01 69 77 
	* http://www.e-deal.com * * La diffusion de ce code source sous quelque forme 
	que ce soit sans * l'autorisation de E-DEAL est interdite. * * Vous êtes 
	autorisés à modifier ce code source uniquement pour votre usage * propre 
	et sous réserve que les mentions de copyright demeurent intactes. * * Ce 
	code est fourni en l'état. Aucune garantie d'aucune sorte, explicite ou * 
	implicite n'est donnée. En aucun cas E-DEAL ne pourra être tenu pour * responsable 
	des dommages pouvant résulter de l'utilisation de ce code * source. ** --
project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
	xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
  http://maven.apache.org/xsd/maven-4.0.0.xsd;
	modelVersion4.0.0/modelVersion

	groupIdcom.mycompany/groupId
	artifactIdmycompany-cci/artifactId
	version001-SNAPSHOT/version

	packagingjar/packaging

	properties
		!-- target.dirsrc/main/webapp/mycompanyCRM/WEB-INF/target.dir --
		!-- If mycompanyCRM removed from webapp --
		target.dirsrc/main/webapp/WEB-INF/target.dir
		packaging.directoryjars/packaging.directory
		additional.libs.directorylib/additional.libs.directory
		webapp.context/mycompanycrm/webapp.context
		encoding.formatUTF-8/encoding.format
		java.version1.6/java.version

		!-- Eclipse Project Facets Version --
		wtp.version2.0/wtp.version
		wst.jsdt.web.version1.0/wst.jsdt.web.version
		jst.web.version2.5/jst.web.version

		!-- Database provider version --
		!-- Current lib JDK 1.6 unavailable in public repo get from ou Artifactory --
		oracle.provider.artifactIdojdbc6/oracle.provider.artifactId
		oracle.provider.version11.2.0.3.0/oracle.provider.version

		!-- JDK 1.5 unavailable in public repo get from ou Artifactory --
		!-- oracle.provider.artifactIdojdbc5/oracle.provider.artifactId --
		!-- oracle.provider.version11.2.0.3.0/oracle.provider.version --

		!-- JDK 1.4 --
		!-- oracle.provider.artifactIdojdbc/oracle.provider.artifactId --
		!-- oracle.provider.version14/oracle.provider.version --

		!-- Current lib --
		postgresql.provider.artifactIdpostgresql/postgresql.provider.artifactId
		postgresql.provider.version8.1-404.jdbc3/postgresql.provider.version

		!-- Most recent libs --
		!-- postgresql.provider.version9.1-901.jdbc4/postgresql.provider.version --
		!-- postgresql.provider.version9.1-901.jdbc3/postgresql.provider.version --

		!-- Current lib --
		sqlserver.provider.artifactIdjtds/sqlserver.provider.artifactId
		sqlserver.provider.version1.2.2/sqlserver.provider.version

		!-- Most recent libs --
		!-- sqlserver.provider.version1.2.4/sqlserver.provider.version --

		!-- Packaging properties - Distribution properties like version: 1.0, 
			1.1, 4.1.2 prefix: mycompany, winter2011, autumn2012, cci2012 --
		distribution.prefixmycompany/distribution.prefix
		release.assembly.nameE-DEAL_CRM.${project.version}/release.assembly.name
	/properties

	dependencies
		dependency
			groupIdcom.mycompany/groupId
			artifactIdmycompany-webapp/artifactId
			version003/version
			version003/version
		/dependency
		dependency
			groupIdcom.mycompany/groupId
			artifactIdmycompany-webapp/artifactId
			version003/version
			classifierwebapp/classifier
			typewar/type
			scoperuntime/scope
		/dependency
	/dependencies
	
	scm
		connectionscm:git:ssh://git@rd1/mycompanycrm.git/connection
		developerConnectionscm:git:ssh://git@rd1/mycompanycrm.git/developerConnection
		

Re: war + webapp dependency classifier

2014-01-15 Thread Adrien Rivard
Hi,

Is the mycompany-parent pom.xml in the directory corresponding to
 relativePath../pom.xml/relativePath at version -003 ?

If it is not it may be not used . You should either and put it to 001-SNAPSHOT
if you want to use the relativePath file or let the relativePath empty (
relativePath/relativePath) to use the released version (or don't
specify relativePath)

Also you should remove the trailing '-' in your version, they are usually
automatically appended, and it could be also your problem.

If this does'nt help, please post debug log and the some of your parent pom.


On Wed, Jan 15, 2014 at 10:11 AM, Adrien Ruffié
adriennolar...@hotmail.frwrote:

 Hello all,

 I have maven 3

 I have a webapp which derived from a first webapp, I have read this
 article:


 http://ovaraksin.blogspot.fr/2011/09/inheritance-in-maven-based-web-projects
 .html

 But when I try to done following command, mvn clean package or a simple
 mvn dependency:tree I get the following error:

 [ERROR] Failed to execute goal on project mycompany-ci: Could not resolve
 dependencies for project com.mycompany:mycompany-ci:jar: 001-SNAPSHOT:
 Could
 not find artifact com.mycompany:mycompany-webapp:war:webapp:003 in central
 (http://192.168.1.160:8081/artifactory/libs-release) - [Help 1]

 However I have 3 artifacts inside libs-release-local of my artifactory:
 mycompany-webapp-003-classes.jar
 mycompany-webapp-003.jar
 mycompany-webapp-003.pom
 mycompany-webapp-003.war

 I attached also my pom.xml of the second webapp, and below a extract of my
 first webapp (the base webapp)

 parent
 groupIdcom. mycompany /groupId
 artifactIdmycompany-parent/artifactId
 version-003/version
 relativePath../pom.xml/relativePath
 /parent

 artifactId mycompany-webapp/artifactId
 packagingjar/packaging


 Do you have an idea of the problem ?



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




-- 
Adrien Rivard


Re: war + webapp dependency classifier

2014-01-15 Thread Jörg Schaible
Hi Adrian,

Adrien Ruffié wrote:

 Hello all,
 
 I have maven 3
 
 I have a webapp which derived from a first webapp, I have read this
 article:
 
 http://ovaraksin.blogspot.fr/2011/09/inheritance-in-maven-based-web-projects
 .html
 
 But when I try to done following command, mvn clean package or a simple
 mvn dependency:tree I get the following error:
 
 [ERROR] Failed to execute goal on project mycompany-ci: Could not resolve
 dependencies for project com.mycompany:mycompany-ci:jar: 001-SNAPSHOT:
 Could not find artifact com.mycompany:mycompany-webapp:war:webapp:003 in
 central (http://192.168.1.160:8081/artifactory/libs-release) - [Help 1]
 
 However I have 3 artifacts inside libs-release-local of my artifactory:
 mycompany-webapp-003-classes.jar
 mycompany-webapp-003.jar
 mycompany-webapp-003.pom
 mycompany-webapp-003.war
 
 I attached also my pom.xml of the second webapp, and below a extract of my
 first webapp (the base webapp)

[snip]

 Do you have an idea of the problem ?

The problem is, that Oleg only published half of the truth in his blog. He 
did not inform, how the jar and the war plugin have to be configured in the 
first project. And the produced artifacts from above clearly shows, that you 
do not have an artifact of type war with webapp classifier.

= % ==
 project
   ...
   typejar/type
   ...
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-jar-plugin/artifactId
   configuration
 outputDirectory${project.build.directory}/webapp/WEB-
INF/lib/outputDirectory!--*--
   /configuration
 /plugin
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-war-plugin/artifactId
   executions
 execution
   idwar/id
   phasepackage/phase!--*--
   goals
 goalwar/goal!--*--
   /goals
   configuration
 classifierwebapp/classifier!--*--
 
webappDirectory${project.build.directory}/webapp/webappDirectory
 packagingExcludesWEB-INF/classes/**/packagingExcludes
 archiveClassesfalse/archiveClasses
 ...
   /configuration
 /execution
   /executions
 /plugin
 ...
   /plugins
   ...
 /project
= % ==

The war is build as attached artifact. It contains no .class files, but the 
jar generated as main target. However, that one has to be generated into the 
right location that the war plugin includes it into the war artifact.

The project that used these two artifacts as dependency must also use a 
special configuration for the war plugin:

= % ==
 project
   ...
   plugins
 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-war-plugin/artifactId
   configuration
 dependentWarExcludesMETA-INF/MANIFEST.MF,WEB-
INF/lib/*.*/dependentWarExcludes
 ...
   /configuration
 /plugin
 ...
   /plugins
   ...
 /project
= % ==

It is used to exclude any stuff from WEB-INF/lib (you may chose to exclude 
WEB-INF/classes/** also) from overlayed wars, since all dependencies are 
taken now into account for the resolve algorithm.

You can move most of the configuration values into properties and the 
configuration itself in the pluginManagement section of a shared parent so 
your projects may just contain the settings marked with !--*--.

I've published this solution here on the list before and Oleg was a 
colleague of mine.

Cheers,
Jörg




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



Re: How to include @inheritDoc from a dependent jar

2014-01-15 Thread Stuart McCulloch

On 15 Jan 2014, at 08:20, Mikael Petterson mikael.petter...@ericsson.com 
wrote:

 Hi,
 
 New try :-)
 
 I have the following:
 
 Interface in dependency jar javadoc:
 
 /**
 * Deletes the object found at the specified location.
 * 
 * @param Object any type of object
 * @throws InvalidObjectException lots of text
 * @throws NoSuchObjectException lots of text
 */
 public void delete (Object object)throws throws InvalidObjectException, 
 NoSuchObjectException;
 
 Implementing class:
 
 /**
 * {@inheritDoc}
 */
@Override
public void delete(Object object) throws InvalidObjectException, 
 NoSuchObjectException {
   //implementation of delete
}
 
 Is this correct or?   Since this will not produce any javadoc for 
 implementation of delete ( last code).
 
 Do I need to do anything special in the maven javadoc plugin?

The javadoc tool works primarily from source, and by default the maven javadoc 
plugin doesn’t include the sources of dependencies - which is why @inheritDoc 
doesn’t include the javadoc from the dependency.

You can tell the javadoc plugin to include the sources of dependencies with:

includeDependencySourcestrue/includeDependencySources

and include the sources of transitive dependencies with:


includeTransitiveDependencySourcestrue/includeTransitiveDependencySources

You can also use dependencySourceExcludes / dependencySourceIncludes to control 
which particular sources get pulled in 

( this assumes that the dependency sources - typically produced by the maven 
source plugin - are available in the local/remote repository )

 Br.
 
 //mike
 
 -Original Message-
 From: Martin Gainty [mailto:mgai...@hotmail.com]
 Sent: den 14 januari 2014 13:27
 To: users@maven.apache.org
 Subject: RE: How to include @inheritDoc from a dependent jar
 
 
 
 
 From: mikael.petter...@ericsson.com
 To: users@maven.apache.org
 Subject: How to include @inheritDoc from a dependent jar
 Date: Tue, 14 Jan 2014 12:14:21 +
 
 Hi,
 
 We are building a maven site that will contain javadoc for our AppX api ( 
 jar file).
 AppX depends on a few other jar files ( that we have built using maven) . 
 One dependency jar contain an interface with javadoc and we have a class 
 implementing it, in AppX.
 AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
 
 When I use the following under report
 
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version2.8.1/version
 /plugin
 
 But when I open up the javadoc for my Appx and look at the class 
 implementing the interface there is no javadoc. What am I missing?
 
 MG@Inheritdoc pulls Javadoc comments @comment @author @param @throws 
 MG@return from Implemented interface If you have none of the Javadoc 
 MGtags in the corresponding base method of implemented interface then 
 MGAppX class will not be able to 'inherit' those Javadoc attributes
 
 Br,
 
 //mike
 The longest journey is the the journey inwards..Of him who has chosen his 
 dentiny..Who has started upon his quest for the source of his being Dag 
 Hammarskjold
 
 
 -
 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: Reworking the main project site...

2014-01-15 Thread Stephen Connolly
should work now


On 10 January 2014 21:31, Anders Hammar and...@hammar.net wrote:

 Still can't get it to work in firefox (on mac). But it does work on my
 phone. Looks way cool! But we should probably support firefox as well...:-)

 /Anders


 On Fri, Jan 10, 2014 at 9:13 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  an extra space in the xdoc... should be fixed now
 
 
  On 10 January 2014 19:46, Anders Hammar and...@hammar.net wrote:
 
http://stephenc.github.io/junit/
  
I recommend clicking the Let's take a tour button.
   
  
   Does not work in my browser! (tm)
  
  
 
 https://www.dropbox.com/s/oezmyk4khsynl78/Screenshot%202014-01-10%2020.45.35.png
  
   /Anders
  
  
   
-Stephen
   
  
 



Re: Reworking the main project site...

2014-01-15 Thread Anders Hammar
Yes, it does.

/Anders


On Wed, Jan 15, 2014 at 3:52 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 should work now


 On 10 January 2014 21:31, Anders Hammar and...@hammar.net wrote:

  Still can't get it to work in firefox (on mac). But it does work on my
  phone. Looks way cool! But we should probably support firefox as
 well...:-)
 
  /Anders
 
 
  On Fri, Jan 10, 2014 at 9:13 PM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   an extra space in the xdoc... should be fixed now
  
  
   On 10 January 2014 19:46, Anders Hammar and...@hammar.net wrote:
  
 http://stephenc.github.io/junit/
   
 I recommend clicking the Let's take a tour button.

   
Does not work in my browser! (tm)
   
   
  
 
 https://www.dropbox.com/s/oezmyk4khsynl78/Screenshot%202014-01-10%2020.45.35.png
   
/Anders
   
   

 -Stephen

   
  
 



Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-15 Thread S. Ali Tokmen
Hi Andreas

You are right - this makes a lot of sense.

Shall I still raise a JIRA entry for this functionality; or is this
close to impossible to implement?

Thank you

S. Ali Tokmen
http://ali.tokmen.com/

My IM, GSM, PGP and other contact details
are on http://contact.ali.tokmen.com

On 14/01/14 21:16, Anders Hammar wrote:
 Don't think that's doable as the user could configure the params for
 different goals in the same configuration section (on plugin level, not
 execution level).

 /Anders


 On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.comwrote:

 Hi Baptiste, Thomas

 I guess you all got a point :) The reason why I want to check the
 configuration is indeed something that would have to be done in each goal.

 My remaining question would be whether there is a way to read the
 configuration XML definition from the MOJO - I could then manually
 implement such a verification in the different MOJOs.

 Please advise

 Thank you

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 14/01/14 14:24, Baptiste Mathus wrote:
 Hi,
 Stephen already answered along those lines. What are you missing?
 Cheers


 2014/1/9 S. Ali Tokmen nos...@alishomepage.com

 Hi Anders

 Thanks for your reply - and happy new year :)

 Is there any way I can inject / read the whole plugin configuration from
 the plugin?

 Best regards

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 08/01/14 20:00, Anders Hammar wrote:
 AFAIK there is no support for this. If you think there should be,
 please
 file a ticket [1].

 /Anders

 [1] http://jira.codehaus.org/browse/MNG/


 On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.com
 wrote:

 Dear Maven users

 I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
 plugin; and would have a question with regards to how parameters are
 managed.

 We defined our MOJOs with parameters (you can see


 http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
 for example), but what happens is that if a user unwillingly puts a
 parameter in the wrong place then the plugin execution doesn't stop.

 As an example, I can write the below POM and build still works (even
 thought the MOJO has no parameter called foo):

   plugin
 groupIdorg.codehaus.cargo/groupId
 artifactIdcargo-maven2-plugin/artifactId
 version1.4.6/version
 configuration
   foo
 bar
   /foo
 /configuration
   /plugin

 Is there any way I can instruct by MOJO to fail if there is an unknown
 parameter?

 Please advise

 Thank you

 --

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.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

 --
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor ! nbsp;! 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



Maven just won't die! -- WTF is Takari?

2014-01-15 Thread Jason van Zyl
Hi,

As some may know, a lot of work has been done at tesla.io on various advanced 
features in Maven but, unfortunately, not enough work for these features to see 
the light of day. It wouldn't be surprising if Maven users have no idea what 
these features are because I've not done a great job at communicating about the 
work. Some of the work is mine, some of other major contributors, and more 
recently from key customers.

To make a long story short there's a lot of cool stuff to talk about, and the 
work as a new venue at takari.io! I'll be giving a webinar next week and here 
are some of the features I'd like to talk about:

- Polyglot support: Ruby, Groovy, and Scala DSLs. These have all been actively 
worked on in the recent past, especially the Ruby and Scala DSLs.
- Full incremental support: the complete Maven lifecycle including an 
incremental command line compiler based on JDT, all with m2e integration
- Aggressive parallelization: a new parallelization mode that also optimizes 
scheduling based on critical path analysis
- Generations: a new form of continuous delivery for Maven -- Smart delta 
protocol and no more SNAPHOTs!
- Shell: long-lived CLI process for Maven

Much of this work is functional, and the new parallelization mode and 
generations support are actively being used in production. We are still 
iterating on these specific features but they show a lot of promise. Where all 
of this code eventually lands is a question for the Maven development 
community. All of this work was developed outside of Apache, and how easy it is 
to integrate back into the Maven project remains to be seen. At the very least 
there is a lot of very interesting work and I wanted to start the dialog 
because Maven just isn't going to die :-)

So please join us for a webinar, Tuesday, January 21 at 11:30AM EST (UTC -5 
hours) to learn more about what we're working on and what we're trying to 
accomplish.

All registrants will receive access to the recording, so if you can’t make it — 
you won’t have to miss out.

Register here: http://goo.gl/vqSvL7

Hope you can make it,

Jason van Zyl
--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-









javadoc:aggregate project filter

2014-01-15 Thread Christian Pontesegger

Hi,

I'd like to create API documentation for an eclipse RCP project. 
Therefore I use the javadoc:aggregate goal which nicely builds 
documentation for all my projects.


Now I want to filter some of them. When building with tycho junit tests 
are typically kept in a separate project. Still the package names for a 
test class ae the same as for the main class. This seems to be the best 
practice approach right now.


Currently API documentation for test classes is built too. Is there a 
way to filter a whole project from the aggregation step?


The only other approach I found was to use the javadoc:javadoc goal and 
to manually add paths using the sourcepath parameter. For a big project 
this is an error prone task which I would like to avoid.


regards
Christian


RE: javadoc:aggregate project filter

2014-01-15 Thread Justin Georgeson
I'm in a similar environment and use profiles in my aggregator POM to specify 
different reactors for different things. I have a profile for a javadoc reactor 
which doesn't include any eclipse-feature, eclipse-test-plugin, or 
eclipse-repository projects (ie it only includes the projects for the actual 
plugins that constitute the product).

-Original Message-
From: Christian Pontesegger [mailto:christian.ponteseg...@web.de] 
Sent: Wednesday, January 15, 2014 12:52 PM
To: users@maven.apache.org
Subject: javadoc:aggregate project filter

Hi,

I'd like to create API documentation for an eclipse RCP project. 
Therefore I use the javadoc:aggregate goal which nicely builds documentation 
for all my projects.

Now I want to filter some of them. When building with tycho junit tests are 
typically kept in a separate project. Still the package names for a test class 
ae the same as for the main class. This seems to be the best practice approach 
right now.

Currently API documentation for test classes is built too. Is there a way to 
filter a whole project from the aggregation step?

The only other approach I found was to use the javadoc:javadoc goal and to 
manually add paths using the sourcepath parameter. For a big project this is an 
error prone task which I would like to avoid.

regards
Christian

--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.

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



Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-15 Thread Anders Hammar
It doesn't work with the way Maven plugins currently are configured.
But there will soon be discussions around a new version of the pom, so you
could file a ticket to get this wish on the board.

/Anders (mobile)
Den 15 jan 2014 19:22 skrev S. Ali Tokmen nos...@alishomepage.com:

 Hi Andreas

 You are right - this makes a lot of sense.

 Shall I still raise a JIRA entry for this functionality; or is this
 close to impossible to implement?

 Thank you

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 14/01/14 21:16, Anders Hammar wrote:
  Don't think that's doable as the user could configure the params for
  different goals in the same configuration section (on plugin level, not
  execution level).
 
  /Anders
 
 
  On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.com
 wrote:
 
  Hi Baptiste, Thomas
 
  I guess you all got a point :) The reason why I want to check the
  configuration is indeed something that would have to be done in each
 goal.
 
  My remaining question would be whether there is a way to read the
  configuration XML definition from the MOJO - I could then manually
  implement such a verification in the different MOJOs.
 
  Please advise
 
  Thank you
 
  S. Ali Tokmen
  http://ali.tokmen.com/
 
  My IM, GSM, PGP and other contact details
  are on http://contact.ali.tokmen.com
 
  On 14/01/14 14:24, Baptiste Mathus wrote:
  Hi,
  Stephen already answered along those lines. What are you missing?
  Cheers
 
 
  2014/1/9 S. Ali Tokmen nos...@alishomepage.com
 
  Hi Anders
 
  Thanks for your reply - and happy new year :)
 
  Is there any way I can inject / read the whole plugin configuration
 from
  the plugin?
 
  Best regards
 
  S. Ali Tokmen
  http://ali.tokmen.com/
 
  My IM, GSM, PGP and other contact details
  are on http://contact.ali.tokmen.com
 
  On 08/01/14 20:00, Anders Hammar wrote:
  AFAIK there is no support for this. If you think there should be,
  please
  file a ticket [1].
 
  /Anders
 
  [1] http://jira.codehaus.org/browse/MNG/
 
 
  On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen 
 nos...@alishomepage.com
  wrote:
 
  Dear Maven users
 
  I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
  plugin; and would have a question with regards to how parameters are
  managed.
 
  We defined our MOJOs with parameters (you can see
 
 
 
 http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
  for example), but what happens is that if a user unwillingly puts a
  parameter in the wrong place then the plugin execution doesn't stop.
 
  As an example, I can write the below POM and build still works (even
  thought the MOJO has no parameter called foo):
 
plugin
  groupIdorg.codehaus.cargo/groupId
  artifactIdcargo-maven2-plugin/artifactId
  version1.4.6/version
  configuration
foo
  bar
/foo
  /configuration
/plugin
 
  Is there any way I can instruct by MOJO to fail if there is an
 unknown
  parameter?
 
  Please advise
 
  Thank you
 
  --
 
  S. Ali Tokmen
  http://ali.tokmen.com/
 
  My IM, GSM, PGP and other contact details
  are on http://contact.ali.tokmen.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
 
  --
  Baptiste Batmat MATHUS - http://batmat.net
  Sauvez un arbre,
  Mangez un castor ! nbsp;! 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: javadoc:aggregate project filter

2014-01-15 Thread Christian Pontesegger


Am 15.01.2014 20:07, schrieb Justin Georgeson:

I'm in a similar environment and use profiles in my aggregator POM to specify 
different reactors for different things. I have a profile for a javadoc reactor 
which doesn't include any eclipse-feature, eclipse-test-plugin, or 
eclipse-repository projects (ie it only includes the projects for the actual 
plugins that constitute the product).


Seems to be a feasible way. Still I would prefer to have filters - which 
I guess is not possible right now.
My documentation is built to one of these eclipse plugins providing 
online help. By using different profiles I would have 2 separate build 
steps: first build the documentation, afterwards build the product 
(containing the docs).




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



Re: New logo?

2014-01-15 Thread Eric Kolotyluk

  
  
+1

On 1/13/2014 2:29 PM, John Miller
  wrote:


  
  
  
  
  
Well I guess the attachment did not go
  through.. 




Thanks
John

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


  



Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-15 Thread Alejandro . Endo
If you do open a ticket, please let me/us know. I will +1 it. I am also 
interested in this feature

Alejandro Endo | Software Designer/Concepteur de logiciels



From:   Anders Hammar and...@hammar.net
To: Maven Users List users@maven.apache.org, 
Date:   2014-01-15 02:47 PM
Subject:Re: Maven2/Maven3 plugin development: Ensuring only the 
available parameters are allowed
Sent by:anders.g.ham...@gmail.com



It doesn't work with the way Maven plugins currently are configured.
But there will soon be discussions around a new version of the pom, so you
could file a ticket to get this wish on the board.

/Anders (mobile)
Den 15 jan 2014 19:22 skrev S. Ali Tokmen nos...@alishomepage.com:

 Hi Andreas

 You are right - this makes a lot of sense.

 Shall I still raise a JIRA entry for this functionality; or is this
 close to impossible to implement?

 Thank you

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 14/01/14 21:16, Anders Hammar wrote:
  Don't think that's doable as the user could configure the params for
  different goals in the same configuration section (on plugin level, 
not
  execution level).
 
  /Anders
 
 
  On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen 
nos...@alishomepage.com
 wrote:
 
  Hi Baptiste, Thomas
 
  I guess you all got a point :) The reason why I want to check the
  configuration is indeed something that would have to be done in each
 goal.
 
  My remaining question would be whether there is a way to read the
  configuration XML definition from the MOJO - I could then manually
  implement such a verification in the different MOJOs.
 
  Please advise
 
  Thank you
 
  S. Ali Tokmen
  http://ali.tokmen.com/
 
  My IM, GSM, PGP and other contact details
  are on http://contact.ali.tokmen.com
 
  On 14/01/14 14:24, Baptiste Mathus wrote:
  Hi,
  Stephen already answered along those lines. What are you missing?
  Cheers
 
 
  2014/1/9 S. Ali Tokmen nos...@alishomepage.com
 
  Hi Anders
 
  Thanks for your reply - and happy new year :)
 
  Is there any way I can inject / read the whole plugin configuration
 from
  the plugin?
 
  Best regards
 
  S. Ali Tokmen
  http://ali.tokmen.com/
 
  My IM, GSM, PGP and other contact details
  are on http://contact.ali.tokmen.com
 
  On 08/01/14 20:00, Anders Hammar wrote:
  AFAIK there is no support for this. If you think there should be,
  please
  file a ticket [1].
 
  /Anders
 
  [1] http://jira.codehaus.org/browse/MNG/
 
 
  On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen 
 nos...@alishomepage.com
  wrote:
 
  Dear Maven users
 
  I am one of the owners of Codehaus CARGO, which has a 
Maven2/Maven3
  plugin; and would have a question with regards to how parameters 
are
  managed.
 
  We defined our MOJOs with parameters (you can see
 
 
 
 
http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java

  for example), but what happens is that if a user unwillingly puts 
a
  parameter in the wrong place then the plugin execution doesn't 
stop.
 
  As an example, I can write the below POM and build still works 
(even
  thought the MOJO has no parameter called foo):
 
plugin
  groupIdorg.codehaus.cargo/groupId
  artifactIdcargo-maven2-plugin/artifactId
  version1.4.6/version
  configuration
foo
  bar
/foo
  /configuration
/plugin
 
  Is there any way I can instruct by MOJO to fail if there is an
 unknown
  parameter?
 
  Please advise
 
  Thank you
 
  --
 
  S. Ali Tokmen
  http://ali.tokmen.com/
 
  My IM, GSM, PGP and other contact details
  are on http://contact.ali.tokmen.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
 
  --
  Baptiste Batmat MATHUS - http://batmat.net
  Sauvez un arbre,
  Mangez un castor ! nbsp;! 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




DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate 

Perforce and Maven Release process help...

2014-01-15 Thread Jeff
I'm stuck.  I don't normally use Perforce. I don't know why the Maven
release process doesn't work with Perforce.

I can pull and build the source.  When I use the Jenkins Maven Release
plugin, I give it my personal credentials.  My user owns the Jenkins_master
work space I created.  It is the same user used to check out the source
initially.

The error I get is:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
(default-cli) on project webpulse-parent-pom: Error writing POM:
/home/tomcat7/.jenkins/jobs/my-parent-pom/workspace/pom.xml
(Permission denied) - [Help 1]


I thought it was because it was read-only but after adding the 'allwrite'
option, I get the error:

[INFO] Checking in modified POMs...

[ERROR] CommandLineException Exit code: 1 - Error in change specification.


Can't include file(s) not already opened.

Open new files with p4 add, p4 edit, etc.


Doesn't the Maven Perforce connector do a 'p4 edit' before trying to
change/submit the POM?

What am I doing wrong?


-- 

Jeff Vincent
See my LinkedIn profile at:
http://www.linkedin.com/in/rjeffreyvincent


Re: Maven just won't die! -- WTF is Takari?

2014-01-15 Thread Dan Tran
is it a new baby from Sonatype?

-D


On Wed, Jan 15, 2014 at 10:26 AM, Jason van Zyl ja...@tesla.io wrote:

 Hi,

 As some may know, a lot of work has been done at tesla.io on various
 advanced features in Maven but, unfortunately, not enough work for these
 features to see the light of day. It wouldn't be surprising if Maven users
 have no idea what these features are because I've not done a great job at
 communicating about the work. Some of the work is mine, some of other major
 contributors, and more recently from key customers.

 To make a long story short there's a lot of cool stuff to talk about, and
 the work as a new venue at takari.io! I'll be giving a webinar next week
 and here are some of the features I'd like to talk about:

 - Polyglot support: Ruby, Groovy, and Scala DSLs. These have all been
 actively worked on in the recent past, especially the Ruby and Scala DSLs.
 - Full incremental support: the complete Maven lifecycle including an
 incremental command line compiler based on JDT, all with m2e integration
 - Aggressive parallelization: a new parallelization mode that also
 optimizes scheduling based on critical path analysis
 - Generations: a new form of continuous delivery for Maven -- Smart delta
 protocol and no more SNAPHOTs!
 - Shell: long-lived CLI process for Maven

 Much of this work is functional, and the new parallelization mode and
 generations support are actively being used in production. We are still
 iterating on these specific features but they show a lot of promise. Where
 all of this code eventually lands is a question for the Maven development
 community. All of this work was developed outside of Apache, and how easy
 it is to integrate back into the Maven project remains to be seen. At the
 very least there is a lot of very interesting work and I wanted to start
 the dialog because Maven just isn't going to die :-)

 So please join us for a webinar, Tuesday, January 21 at 11:30AM EST (UTC
 -5 hours) to learn more about what we're working on and what we're trying
 to accomplish.

 All registrants will receive access to the recording, so if you can’t make
 it — you won’t have to miss out.

 Register here: http://goo.gl/vqSvL7

 Hope you can make it,

 Jason van Zyl
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -










javadoc:aggregate project filter

2014-01-15 Thread Christian Pontesegger

Hi,

I'd like to create API documentation for an eclipse RCP project. 
Therefore I use the javadoc:aggregate goal which nicely builds 
documentation for all my projects.


Now I want to filter some of them. When building with tycho junit tests 
are typically kept in a separate project. Still the package names for a 
test class ae the same as for the main class. This seems to be the best 
practice approach right now.


Currently API documentation for test classes is built too. Is there a 
way to filter a whole project from the aggregation step?


The only other approach I found was to use the javadoc:javadoc goal and 
to manually add paths using the sourcepath parameter. For a big project 
this is an error prone task which I would like to avoid.


regards
Christian

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



Re: How to mkdir and move files as part of build

2014-01-15 Thread Don'tTellMeToGoogleItDammit
I Googled this, and came to this forum, only to find a remark telling me I
should have Googled this.

Always annoying to find this remark.

Hope you enjoyed your Friday.


Baptiste MATHUS wrote
 Somebody made me discover that recently: http://tinyurl.com/62f6ku ...
 
 No offense, week-end is coming :-).
 Cheers
 
 2008/12/12 CheapLisa lt;

 lisa@

 gt;
 

 great.  Do you remember the name of the plugin and have an example?

 thanks

 L


 Wei Tan wrote:
 
  there is a maven plug-in that can run ant tasks, I remember
 
 
 
  On Fri, Dec 12, 2008 at 2:25 PM, CheapLisa lt;

 lisa@

 gt; wrote:
 
 
  Before the build takes place, I need to create a directory
  /target/
 somedir
  and then copy some files from /src/main/resources/* to there.
 
  How do I do this with maven?
 
  thanks
 
  cl
  --
  View this message in context:
 
 http://www.nabble.com/How-to-mkdir-and-move-files-as-part-of-build-tp20983063p20983063.html
  Sent from the Maven - Users mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: 

 users-unsubscribe@.apache

  For additional commands, e-mail: 

 users-help@.apache

 
 
 
 

 --
 View this message in context:
 http://www.nabble.com/How-to-mkdir-and-move-files-as-part-of-build-tp20983063p20983705.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: 

 users-unsubscribe@.apache

 For additional commands, e-mail: 

 users-help@.apache



 
 
 -- 
 Baptiste 
 Batmat
  MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor !





--
View this message in context: 
http://maven.40175.n5.nabble.com/How-to-mkdir-and-move-files-as-part-of-build-tp114567p5781484.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



Re: How to mkdir and move files as part of build

2014-01-15 Thread Barrie Treloar
On 15 January 2014 23:16, Don'tTellMeToGoogleItDammit c...@rmen.ca wrote:
 I Googled this, and came to this forum, only to find a remark telling me I
 should have Googled this.

 Always annoying to find this remark.

Not knowing what you are attempting to do (because you were too busy
flame-baiting to bother to tell us) and dreading up zombie threads - I
assume you actually clicked on the links in this thread?
e.g. http://tinyurl.com/62f6ku

I'm assuming you want to mkdir and move files as part of the build.
Which the ant plugin will do for you.

Otherwise, please have a look at the freely available books at
http://maven.apache.org/articles.html they might help you with your
problems too.

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



Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-15 Thread S. Ali Tokmen
Hi Anders

Great, sounds good. I've opened
https://jira.codehaus.org/browse/MNG-5563 for it.

Have a great day

S. Ali Tokmen
http://ali.tokmen.com/

My IM, GSM, PGP and other contact details
are on http://contact.ali.tokmen.com

On 15/01/14 20:48, Anders Hammar wrote:
 It doesn't work with the way Maven plugins currently are configured.
 But there will soon be discussions around a new version of the pom, so you
 could file a ticket to get this wish on the board.

 /Anders (mobile)
 Den 15 jan 2014 19:22 skrev S. Ali Tokmen nos...@alishomepage.com:

 Hi Andreas

 You are right - this makes a lot of sense.

 Shall I still raise a JIRA entry for this functionality; or is this
 close to impossible to implement?

 Thank you

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 14/01/14 21:16, Anders Hammar wrote:
 Don't think that's doable as the user could configure the params for
 different goals in the same configuration section (on plugin level, not
 execution level).

 /Anders


 On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen nos...@alishomepage.com
 wrote:

 Hi Baptiste, Thomas

 I guess you all got a point :) The reason why I want to check the
 configuration is indeed something that would have to be done in each
 goal.
 My remaining question would be whether there is a way to read the
 configuration XML definition from the MOJO - I could then manually
 implement such a verification in the different MOJOs.

 Please advise

 Thank you

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 14/01/14 14:24, Baptiste Mathus wrote:
 Hi,
 Stephen already answered along those lines. What are you missing?
 Cheers


 2014/1/9 S. Ali Tokmen nos...@alishomepage.com

 Hi Anders

 Thanks for your reply - and happy new year :)

 Is there any way I can inject / read the whole plugin configuration
 from
 the plugin?

 Best regards

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com

 On 08/01/14 20:00, Anders Hammar wrote:
 AFAIK there is no support for this. If you think there should be,
 please
 file a ticket [1].

 /Anders

 [1] http://jira.codehaus.org/browse/MNG/


 On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen 
 nos...@alishomepage.com
 wrote:

 Dear Maven users

 I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
 plugin; and would have a question with regards to how parameters are
 managed.

 We defined our MOJOs with parameters (you can see


 http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
 for example), but what happens is that if a user unwillingly puts a
 parameter in the wrong place then the plugin execution doesn't stop.

 As an example, I can write the below POM and build still works (even
 thought the MOJO has no parameter called foo):

   plugin
 groupIdorg.codehaus.cargo/groupId
 artifactIdcargo-maven2-plugin/artifactId
 version1.4.6/version
 configuration
   foo
 bar
   /foo
 /configuration
   /plugin

 Is there any way I can instruct by MOJO to fail if there is an
 unknown
 parameter?

 Please advise

 Thank you

 --

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.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

 --
 Baptiste Batmat MATHUS - http://batmat.net
 Sauvez un arbre,
 Mangez un castor ! nbsp;! 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