Proper way to have my Mojo instrument both main and test classes

[offbynull-maven]

I've written a Maven plugin. When it runs, I want it to process both 
main classes and test classes. I originally thought that setting my 
mojo's defaultPhase to PROCESS_CLASSES would handle this, but I've come 
to find out that PROCESS_CLASSES is only for main classes. There seems 
to be separate phase for test classes: PROCESS_TEST_CLASSES. So, when I 
do mvn clean install, my test classes don't get instrumented but my main 
classes do.


What is the proper way to have a single goal process both test classes 
and main classes? Is there a way to have two default phases? or should I 
have separate goals, one for main classes and one for test classes? or 
should I tell the user to explicitly specify two execution blocks in 
their pom (one for bound to process-classes and the other to 
process-test-classes -- but then how would I find out which phase I'm in 
so that I can target the appropriate directory)?




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

Using a file that was pulled in via maven

[Peter Schmitz]

Hi all,
I am trying to use a file I believe has been pulled in to the system via
Maven dependency.
This is a JSON file.  I am using this JSON file to do a simple Schema
Validation using Rest Assured.  The validation steps I believe I have down
no problem, however, I cannot seem to validate against a file I pulled in
from an external source.  I can use a local file to validate, but not
external.

Anyone know where this file could be located and how to use it?   I have
used the resource: dir/filename.json but doesnt find the file or work

Any help here with the semantics would be awesome


Thanks

[ANN] Exec Maven Plugin 1.4.0 Released

[Dennis Lundberg]

Hi,

The Mojo team is pleased to announce the release of the Exec Maven
Plugin version 1.4.0.

The plugin helps with execution of system and Java programs.

http://mojo.codehaus.org/exec-maven-plugin/

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


org.codehaus.mojo
exec-maven-plugin
1.4.0


Release Notes

** Bug
* [MEXEC-150] - Plugin warns that "killAfter is now deprecated"
for no obvious reason

** Improvement
* [MEXEC-143] - Rename skip property to exec.skip
* [MEXEC-147] - Update of mojo parent to version 34
* [MEXEC-148] - Upgrade plexus-utils to 3.0.20
* [MEXEC-149] - Upgrade plexus-interpolation to 1.21

** Task
* [MEXEC-127] - Remove added parameters after commons-exec is fixed
* [MEXEC-152] - Update to commons-exec:1.3

Enjoy,

The Mojo team.


-- 
Dennis Lundberg

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

Re: Aggregating Javadocs in an assembly

[Christopher]

I'd probably configure the asciidoc plugin to run at the "site" phase,
and change its output directory to target/site. That is, unless you
really want to package the html as an a separate artifact in addition
to putting it on the site. In that case, I might use exec-maven-plugin
(or another plugin) to unpack the zip artifact into the appropriate
target/site during the "site" phase to avoid executing asciidoctor a
second time.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Mar 26, 2015 at 12:01 PM, dan bress  wrote:
> Christopher,
>Thanks for the info.
>I am going with the approach of generating my javadocs as part of the
> mvn site.  This works great.  Now the next problem:
>
>Under my top level project I have a project called "docs".  It is a
> collection of asciidoc source files that I use the asciidoc plugin to turn
> into html files, and then i use the assembly plugin to put them in a zip.
> This all happens during the "install" lifecycle.  This is the "in-app" html
> documentation that is bundled with my application.  I am trying to get this
> generated html also included in my site, but don't see a good way to do
> that right now.
>
> I noticed I can put a dependency from maven-site-plugin to
> asciidoctor-maven-plugin, and then copy the source .adoc files to
> src/site/asciidoc then they get picked up, and html is generated.  This is
> cool EXCEPT it means that I have to have my source asciidoc files in two
> places, one for the install phase generation, and one for the site phase
> generation.
>
> I suppose I could always keep the files in src/site/asciidocc, and point
> the "install phase" ascii-doctor plugin to
>
> Any ideas here?
>
> Dan
>
>
>
> On Fri, Mar 20, 2015 at 3:15 PM Christopher  wrote:
>
>> On Fri, Mar 20, 2015 at 2:51 PM, dan bress  wrote:
>> > Christopher,
>> >Thanks for the info.
>> >was your "docs" submodule, where the assembly lived?  How would you
>> > bundle the javadocs created by the parent?
>> >
>>
>> At the time we were doing this, the docs module was where we generated
>> a PDF from LaTeX source. A sibling module did the final tarball
>> assembly, which grabbed the PDF documentation generated in the docs
>> module, and the javadocs which were generated in the parent but stored
>> in the docs module's directory (by overriding outputDirectory in the
>> parent task to point to docs/apidocs instead of the default
>> target/apidocs; note: this is a terrible idea; generated stuff should
>> always go in target).
>>
>> To be clear, I would not advise this method. I just know it's do-able
>> with multiple lifecycle arguments on the maven command-line.
>>
>> >What I am trying to do is capture all the build related
>> > documentation(javadoc, asciidoc, and some other build generated
>> > documentation artifacts) and put that in a directory structure so that I
>> > can put it on our website.  This is why I am aggregating all the javadoc
>> in
>> > one place.  I'm open to other ideas if you have them.
>> >
>>
>> There's a couple of ideas.
>>
>> 1. You could try using the site/reporting features to generate
>> javadocs, rather than using aggregate goal.
>> 2. You could create a separate project to build the assembly for the
>> site, which depends on your main project.
>> 2a) You could depend on your main project's source artifact,
>> executes a task which builds the javadocs, and bundles them
>> 2b) You could depend on your main project's individual modules'
>> individual javadoc jars, and aggregate them manually in your site's
>> assembly
>> 3. You could manually execute a separate task to build the docs for
>> the site, which does not depend on your main build.
>>
>> Keep in mind that your main Maven build should be for the purposes of
>> reproducibly creating deployable artifacts. There are many plugins
>> which can be executed independently from your main build, to perform
>> useful tasks, but I would avoid conflating the two and trying to bake
>> in these utility tasks into your main build, as you're just going to
>> make it difficult to produce artifacts/releases. "mvn
>> javadoc:aggregate" can always be executed as a separate task, and it
>> *may* be more appropriate to do that separately, after you build and
>> deploy your artifacts.
>>
>> > Dan
>> >
>> > On Fri, Mar 20, 2015 at 12:59 PM Christopher 
>> wrote:
>> >
>> >> On Fri, Mar 20, 2015 at 12:16 PM, dan bress  wrote:
>> >> > Maven,
>> >> >I have a multi module maven project and am trying to generate an
>> >> > assembly that houses all our javadocs and our asciidoc generated docs.
>> >> How
>> >> > would you do this?
>> >> >
>> >> > Currently I have a directory structure that looks like this:
>> >> >
>> >> > root
>> >> >   java-library-one
>> >> >   java-library-two
>> >> >   ascidoc-project
>> >> >   pom.xml
>> >> >
>> >> > If I put a javadoc:aggregate plugin execution on the root pom it
>> >> generates
>> >> > the javadoc for both of my projects, which is what I want. 

Re: Aggregating Javadocs in an assembly

[dan bress]

Christopher,
   Thanks for the info.
   I am going with the approach of generating my javadocs as part of the
mvn site.  This works great.  Now the next problem:

   Under my top level project I have a project called "docs".  It is a
collection of asciidoc source files that I use the asciidoc plugin to turn
into html files, and then i use the assembly plugin to put them in a zip.
This all happens during the "install" lifecycle.  This is the "in-app" html
documentation that is bundled with my application.  I am trying to get this
generated html also included in my site, but don't see a good way to do
that right now.

I noticed I can put a dependency from maven-site-plugin to
asciidoctor-maven-plugin, and then copy the source .adoc files to
src/site/asciidoc then they get picked up, and html is generated.  This is
cool EXCEPT it means that I have to have my source asciidoc files in two
places, one for the install phase generation, and one for the site phase
generation.

I suppose I could always keep the files in src/site/asciidocc, and point
the "install phase" ascii-doctor plugin to

Any ideas here?

Dan



On Fri, Mar 20, 2015 at 3:15 PM Christopher  wrote:

> On Fri, Mar 20, 2015 at 2:51 PM, dan bress  wrote:
> > Christopher,
> >Thanks for the info.
> >was your "docs" submodule, where the assembly lived?  How would you
> > bundle the javadocs created by the parent?
> >
>
> At the time we were doing this, the docs module was where we generated
> a PDF from LaTeX source. A sibling module did the final tarball
> assembly, which grabbed the PDF documentation generated in the docs
> module, and the javadocs which were generated in the parent but stored
> in the docs module's directory (by overriding outputDirectory in the
> parent task to point to docs/apidocs instead of the default
> target/apidocs; note: this is a terrible idea; generated stuff should
> always go in target).
>
> To be clear, I would not advise this method. I just know it's do-able
> with multiple lifecycle arguments on the maven command-line.
>
> >What I am trying to do is capture all the build related
> > documentation(javadoc, asciidoc, and some other build generated
> > documentation artifacts) and put that in a directory structure so that I
> > can put it on our website.  This is why I am aggregating all the javadoc
> in
> > one place.  I'm open to other ideas if you have them.
> >
>
> There's a couple of ideas.
>
> 1. You could try using the site/reporting features to generate
> javadocs, rather than using aggregate goal.
> 2. You could create a separate project to build the assembly for the
> site, which depends on your main project.
> 2a) You could depend on your main project's source artifact,
> executes a task which builds the javadocs, and bundles them
> 2b) You could depend on your main project's individual modules'
> individual javadoc jars, and aggregate them manually in your site's
> assembly
> 3. You could manually execute a separate task to build the docs for
> the site, which does not depend on your main build.
>
> Keep in mind that your main Maven build should be for the purposes of
> reproducibly creating deployable artifacts. There are many plugins
> which can be executed independently from your main build, to perform
> useful tasks, but I would avoid conflating the two and trying to bake
> in these utility tasks into your main build, as you're just going to
> make it difficult to produce artifacts/releases. "mvn
> javadoc:aggregate" can always be executed as a separate task, and it
> *may* be more appropriate to do that separately, after you build and
> deploy your artifacts.
>
> > Dan
> >
> > On Fri, Mar 20, 2015 at 12:59 PM Christopher 
> wrote:
> >
> >> On Fri, Mar 20, 2015 at 12:16 PM, dan bress  wrote:
> >> > Maven,
> >> >I have a multi module maven project and am trying to generate an
> >> > assembly that houses all our javadocs and our asciidoc generated docs.
> >> How
> >> > would you do this?
> >> >
> >> > Currently I have a directory structure that looks like this:
> >> >
> >> > root
> >> >   java-library-one
> >> >   java-library-two
> >> >   ascidoc-project
> >> >   pom.xml
> >> >
> >> > If I put a javadoc:aggregate plugin execution on the root pom it
> >> generates
> >> > the javadoc for both of my projects, which is what I want.  But I am
> not
> >> > sure where to put my assembly.  Should that be called from the root
> pom?
> >> > Should I make a sub project for the assembly?  If I do that, can it
> refer
> >> > to the javadoc generated by the parent?
> >> >
> >> > Let me know what you think!
> >> > Thanks!
> >>
> >> I've done something like this in the past. It's not pretty, but
> >> essentially, I had a sub-module for "docs", which, in its package
> >> phase, would bundle the javadocs created by the parent. To get this to
> >> work, I would have to run:
> >>
> >> mvn compile javadoc:aggregate package
> >>
> >> This would essentially force 3 lifecycles, the first to compile and
> >

Re: Plugin dependency resolution from plugin pom?

[Curtis Rueden]

Hi Gary,

> I'm trying to patch a third-party plugin at the moment as a temporary
> workaround for a problem. (I don't want to get into details because
> it's not important)

Since the workaround is temporary, could you not simply clone the plugin's
SCM repository to a local Git repository, then create a branch with your
changes? Then rebuild the plugin whenever you like and use it. No need for
all the hoop-jumping it sounds like you're doing now...

Regards,
Curtis

On Mon, Mar 23, 2015 at 5:41 PM, Gary Kennedy  wrote:

> I'm trying to patch a third-party plugin at the moment as a temporary
> workaround for a problem. (I don't want to get into details because it's
> not important)
>
> So I currently have a 'patch project' that depends on the plugin, uses the
> maven-dependency-plugin to unpack the dependant plugin (without the
> replacement files), contains the replacement files, does some replacer
> magic on the extracted plugin.xml to fixup the version/etc, and then
> package it all.
>
> This all works fine, in that the new project jar is a good content copy of
> the old plugin with all the changes needed.
>
> However, when using the new plugin, several dependency errors occur.
> (i.e., the dependencies of the old plugin are not pulled in).
>
> This confused me for a while because the maven plugin.xml file correctly
> lists all the dependencies. After a bit more playing around I worked out
> that this is because the plugin dependency resolution comes from the
> plugins pom.xml and NOT the plugin.xml file.
>
> So my main question for the group is: How/Can I, at build time, add the
> dependency (and properties, if possible) section from the old plugin pom
> into my new plugin's artefact pom? (So not the project pom itself, but the
> one written to the maven repository)
>
> And because I'm curious, does anyone know,
>a) why the plugin.xml contains the dependencies if they are not used?
> or b) why the pom.xml is used instead of the plugin.xml to resolve
> dependencies? (I suspect aether + coding simplicity for this one)
>
> Cheers,
> Gary
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

RE: Plugin dependency resolution from plugin pom?

[Martin Gainty]

plugin.xml
requiresDependencyResolution



  String



Flags this Mojo as requiring the dependencies in the specified 
class path to be resolved before it can
execute: compile, runtime, test,
compile+runtime (since Maven 3.0) or runtime+system (since Maven 
3.0)
  
Default value is: runtime.
https://maven.apache.org/ref/3.2.1/maven-plugin-api/plugin.html

does setting in plugin.xml  not force 
dependencies to be resolved?

for your next run can you display debug info and error info so we can see 
determine the behaviour of the reactor?

>mvn -e -X 

?
Martin 


> From: g...@apnic.net
> To: users@maven.apache.org
> Subject: Plugin dependency resolution from plugin pom?
> Date: Mon, 23 Mar 2015 22:41:39 +
> 
> I'm trying to patch a third-party plugin at the moment as a temporary 
> workaround for a problem. (I don't want to get into details because it's not 
> important)
> 
> So I currently have a 'patch project' that depends on the plugin, uses the 
> maven-dependency-plugin to unpack the dependant plugin (without the 
> replacement files), contains the replacement files, does some replacer magic 
> on the extracted plugin.xml to fixup the version/etc, and then package it all.
> 
> This all works fine, in that the new project jar is a good content copy of 
> the old plugin with all the changes needed.
> 
> However, when using the new plugin, several dependency errors occur. (i.e., 
> the dependencies of the old plugin are not pulled in).
> 
> This confused me for a while because the maven plugin.xml file correctly 
> lists all the dependencies. After a bit more playing around I worked out that 
> this is because the plugin dependency resolution comes from the plugins 
> pom.xml and NOT the plugin.xml file.
> 
> So my main question for the group is: How/Can I, at build time, add the 
> dependency (and properties, if possible) section from the old plugin pom into 
> my new plugin's artefact pom? (So not the project pom itself, but the one 
> written to the maven repository)
> 
> And because I'm curious, does anyone know,
>a) why the plugin.xml contains the dependencies if they are not used?
> or b) why the pom.xml is used instead of the plugin.xml to resolve 
> dependencies? (I suspect aether + coding simplicity for this one)
> 
> Cheers,
> Gary
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 
  

Re: Maven does not find existing artifacts in local repository because it looks in central where they are not?

[Ron Wheeler]

Running Maven with -x and including the relevant part of the log might help.

We are all guessing what you have screwed up.
Of course Maven has to be able to use stuff that is not in Maven Central 
otherwise none of us could ever develop a library or a project with more 
than one piece.


You should install a repo.
Nexus Community version is the one that I use but there are others.
Even if it is just on your workstation, it will help make Maven easier 
to understand and a lot easier to use.


"Free Maven Advice" (http://blog.artifact-software.com/tech/?p=177)  is 
an article that I wrote a few years ago to help people get started.
It reflects the things that we learned as a company developing with 
Maven rather than as people with inside (or very deep) knowledge about 
Maven.


The people in this forum are very helpful and a lot of them really know 
Maven well.


We will get you through this stage in your Maven journey :-)

Ron

On 26/03/2015 8:48 AM, Jörg Schaible wrote:

Hi Christian,

Christian Eugster wrote:


Hi

as I understand, there is a central repository for maven artifacts:
central (http://repo.maven.apache.org/maven2
) and a local one
(${user.home}/.m2/repository. What I do not understand is, why after a mvn
test maven complains about artifacts that are not in local repository. The
named artifacts are in local repository as I checked. And it says, that it
cannot download them from central. Because these artifacts are from my own
project, they are only in the local repository. Why does maven try to
download them, when they are already in local repository? Is there a wrong
setting? Does exist a reasonable documentation for beginners that is able
to explain what is going wrong?

I am thankfully for any hint!

How do you refer those artifacts? Any chance that they are included using an
import scope?

Cheers,
Jörg


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





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

Re: Maven does not find existing artifacts in local repository because it looks in central where they are not?

[Jörg Schaible]

Hi Christian,

Christian Eugster wrote:

> Hi
> 
> as I understand, there is a central repository for maven artifacts:
> central (http://repo.maven.apache.org/maven2
> ) and a local one
> (${user.home}/.m2/repository. What I do not understand is, why after a mvn
> test maven complains about artifacts that are not in local repository. The
> named artifacts are in local repository as I checked. And it says, that it
> cannot download them from central. Because these artifacts are from my own
> project, they are only in the local repository. Why does maven try to
> download them, when they are already in local repository? Is there a wrong
> setting? Does exist a reasonable documentation for beginners that is able
> to explain what is going wrong?
> 
> I am thankfully for any hint!

How do you refer those artifacts? Any chance that they are included using an 
import scope?

Cheers,
Jörg


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

maven-release-plugin / SVN credentials

[Sebastian Oerding]

Hello,

I have a problem with the maven-release-plugin using the SVN credentials 
(details below). I always get an SVN authorization error. It seems that the 
release plugin does not use the existing credentials. Unfortunately I'm even 
not sure whether it is a problem of the maven-release-plugin or SVN. How can I 
check / get a log which credentials / whether credentials are actually used?

Please explain me how an installed SVN is used (SlikSvn and Tortoise SVN 
installed, both with version 1.8 of the subversion protocol).

Details:
I'm in a company where we have Windows 7, 64 bit systems and an Active 
Directory for Single Sign On (This Windows Kerberos / NTLM like stuff).

The maven-release-plugin worked fine until switching from subversion 1.6 to 
subversion 1.8. However I had exactly the same problem last month after the 
monthly password change. Surprisingly I was able to get this solved by making a 
single commit with Tortoise SVN providing the credentials (and choosing 
Tortoise to save them). However after my laptop has been renewed the same 
problem occurs again and I can not solve it using the same trick as before.

Using Google I found a lot of posts on stackoverflow and similar stuff where 
users report a problem with the maven-release-plugin and SVN credentials. 
However all of the solutions presented are unacceptable to me or do not solve 
my problem. For example I can not store my company wide password in some file 
which is checked into the SVN. Providing the parameters for each invocation of 
the maven-release-plugin adjusting them every month would also be somehow 
risky. At least it would be error-prone - every time when I forget to adjust 
the password after a monthly change I have to rollback the release, clean up 
the project, adjust the settings and try again.

In my previous setup where I was able to solve the problem by a Tortoise commit 
I noticed that the SVN credentials persisted under 
%USER%\AppData\Roaming\Subversion\auth changed. Before there were only empty 
directories, now there is a directory svn.simple which contains a text file 
with the SVN realm, username and so on as expected. The password also seems to 
be fine but I can not definitely say as it is encrypted.

Do you have any further hints on that, maybe a SVN mailing list where to go?

With kind regards,

Sebastian Oerding

Entwickler

Robotron Datenbank-Software GmbH
Stuttgarter Straße 29
01189 Dresden
sebastian.oerd...@robotron.de
www.robotron.de