Re: maven-3.x-jenkinsfile/master - build #54 - null

2017-02-22 Thread Christian Schulte
Am 02/23/17 um 06:18 schrieb Apache Jenkins Server:
> See https://builds.apache.org/job/maven-3.x-jenkinsfile/job/master/54/
> 

Turns out the "null" in the subject does not indicate a successful
build. Maven master currently does not build successfully.

Regards,
-- 
Christian


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



Re: Launcher script issues in 3.5.0.

2017-02-22 Thread Christian Schulte
Am 02/23/17 um 04:21 schrieb Igor Fedorenko:
> On all platforms .mvn/ search is expected to start with directory
> specified by -f parameter and keep doing "cd .." until it files .mvn/
> subdirectory or hits the filesystem root.

What if I put a .mvn directory at the file system root? Will that become
the default for everything when there is no other .mvn found before?

> The idea is to use .mvn/ subdirectory as a marker of multimodule project
> basedir. The build can be started from any submodule, but multimodule
> project basedir will be always the same.

That's how I understood it as well. If it does not stop anywhere but the
drive root, this will lead to invalid project base directories as soon
as someone adds a .mvn directory somewhere inappropriate. I am not using
that feature myself, so just wanted to be sure. The patch does not
change the logic in any way. Just makes it work for directory names like
"Spaces & Special Char". I'll merge it, if no one objects.

Regards,
-- 
Christian


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



Re: Launcher script issues in 3.5.0.

2017-02-22 Thread Igor Fedorenko
On all platforms .mvn/ search is expected to start with directory
specified by -f parameter and keep doing "cd .." until it files .mvn/
subdirectory or hits the filesystem root.

The idea is to use .mvn/ subdirectory as a marker of multimodule project
basedir. The build can be started from any submodule, but multimodule
project basedir will be always the same.

-- 
Regards,
Igor

On Wed, Feb 22, 2017, at 09:19 PM, Christian Schulte wrote:
> Both issues seem to be related to MNG-5889. MNG-5889 branch created. If
> no one objects, I'll merge it to master when the build job completed
> successfully on Jenkins. Otherwise consider the MNG-5889 branch yours.
> Note: I just noticed that the Windows launcher does not stop searching
> for the .mvn directory at the directory given by the -f option. Search
> does not stop until the drive root has been reached (like C:). I am not
> sure this is intended.
> 
> Regards,
> -- 
> Christian
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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



Re: Launcher script issues in 3.5.0.

2017-02-22 Thread Christian Schulte
Both issues seem to be related to MNG-5889. MNG-5889 branch created. If
no one objects, I'll merge it to master when the build job completed
successfully on Jenkins. Otherwise consider the MNG-5889 branch yours.
Note: I just noticed that the Windows launcher does not stop searching
for the .mvn directory at the directory given by the -f option. Search
does not stop until the drive root has been reached (like C:). I am not
sure this is intended.

Regards,
-- 
Christian


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



Re: Build of maven-dependency-analyzer fails on Windows.

2017-02-22 Thread Christian Schulte
Am 02/20/17 um 18:28 schrieb Robert Scholte:
> On Mon, 20 Feb 2017 02:17:12 +0100, Christian Schulte   
> wrote:
> 
>> Am 02/20/17 um 01:53 schrieb Christian Schulte:
>>> Hi,
>>>
>>> I cannot build 'maven-dependency-analyzer' trunk on Windows. Is there
>>> some dependency I could upgrade to get this going? This is what I am
>>> doing locally:
>>>
>>> svn checkout /repos/asf/maven/shared/trunk/maven-dependency-analyzer
>>> cd maven-dependency-analyzer
>>> mvn verify -Papache-snapshots,run-its
>>>
>>> Jenkins build job is here:
>>>
>>> 
>>>
>>> Regards,
>>>
>>
>> Seems we cannot rename the mvn.bat file to mvn.cmd. Can someone clarify
>> this, please. Is it "just" our invoker relying on this?
> 
> Effective pom says maven-invoker-plugin-2.0.0 is used, which is aware of  
> both mvn.bat and mvn.cmd
> 
> Robert

Can you build the shared trunk on Windows using 3.5.0-SNAPSHOT? I am
running into issues related to something not finding the mvn.bat file. I
manually copied the mvn.cmd to mvn.bat and things started to work.

Regards,
-- 
Christian


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



Re: Launcher script issues in 3.5.0.

2017-02-22 Thread Christian Schulte
Please see the attachment. Can someone please review this and apply the
patches. Both launchers - Windows and Unix - should support directory
names like "Spaces & Special Char" with this patch applied. I do not
know what JIRA issue corresponds to these changes.

Regards,
-- 
Christian

diff --git a/apache-maven/src/bin/mvn b/apache-maven/src/bin/mvn
index 95a407d..cfb39b0 100755
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -141,9 +141,9 @@ find_file_argument_basedir() {
   found_file_switch=0
   for arg in "$@"; do
 if [ ${found_file_switch} -eq 1 ]; then
-  if [ -f ${arg} ]; then
-basedir=$(dirname $(readlink -f "${arg}"))
-if [ ! -d ${basedir} ]; then
+  if [ -f "${arg}" ]; then
+basedir=$(dirname "$(readlink -f "${arg}")")
+if [ ! -d "${basedir}" ]; then
   echo "Directory ${basedir} extracted from the -f/--file command-line argument ${arg} does not exist" >&2
   exit 1
 fi
diff --git a/apache-maven/src/bin/mvn.cmd b/apache-maven/src/bin/mvn.cmd
index e527188..c86662b 100644
--- a/apache-maven/src/bin/mvn.cmd
+++ b/apache-maven/src/bin/mvn.cmd
@@ -120,7 +120,7 @@ if not exist "%FILE_ARG%" (
   echo POM file %FILE_ARG% specified the -f/--file command-line argument does not exist >&2
   goto error
 )
-call :get_directory_from_file %FILE_ARG%
+call :get_directory_from_file "%FILE_ARG%"
 if not exist "%POM_DIR%" (
   echo Directory %POM_DIR% extracted from the -f/--file command-line argument %FILE_ARG% does not exist >&2
   goto error


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

Re: Launcher script issues in 3.5.0.

2017-02-22 Thread Christian Schulte
See the attached patch. This should make the Unix launcher support
directory names like "Spaces & Special Char". At least here:

SH_VERSION='@(#)PD KSH v5.2.14 99/07/13.2'

Can someone review and apply this patch please. Thanks.

Regards,
-- 
Christian

diff --git a/apache-maven/src/bin/mvn b/apache-maven/src/bin/mvn
index 95a407d..cfb39b0 100755
--- a/apache-maven/src/bin/mvn
+++ b/apache-maven/src/bin/mvn
@@ -141,9 +141,9 @@ find_file_argument_basedir() {
   found_file_switch=0
   for arg in "$@"; do
 if [ ${found_file_switch} -eq 1 ]; then
-  if [ -f ${arg} ]; then
-basedir=$(dirname $(readlink -f "${arg}"))
-if [ ! -d ${basedir} ]; then
+  if [ -f "${arg}" ]; then
+basedir=$(dirname "$(readlink -f "${arg}")")
+if [ ! -d "${basedir}" ]; then
   echo "Directory ${basedir} extracted from the -f/--file command-line argument ${arg} does not exist" >&2
   exit 1
 fi


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

Launcher script issues in 3.5.0.

2017-02-22 Thread Christian Schulte
Hi,

our launchers (both Unix and Windows) still seem to be broken for
directory names like "Spaces & Special Char".

pwd
/home/schulte
$ mvn -version
Apache Maven 3.5.0-SNAPSHOT (e6217a455547e5b3bcac310be18daf2a333cd5d1;
2017-02-21T01:24:24+01:00)
Maven home: /home/schulte/Applications/apache-maven-3.5.0-SNAPSHOT
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.7.0/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "openbsd", version: "6.0", arch: "amd64", family: "unix"

$ env LANG=C mvn -f "/tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml" clean

/home/schulte/Applications/apache-maven-3.5.0-SNAPSHOT/bin/mvn[171]: [:
\&\: unexpected operator/operand
POM file /tmp/Spaces\ \&\ Special\ Char/maven-invoker-plugin/pom.xml
specified with the -f/--file command line argument does not exist
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-readable POM /tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml: /tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml (No such file or directory) @


$ env LANG=C mvn -f /tmp/Spaces\ \&\ Special\
Char/maven-invoker-plugin/pom.xml clean

/home/schulte/Applications/apache-maven-3.5.0-SNAPSHOT/bin/mvn[171]: [:
&: unexpected operator/operand
POM file /tmp/Spaces & Special Char/maven-invoker-plugin/pom.xml
specified with the -f/--file command line argument does not exist
[INFO] Scanning for projects...
[INFO]
[INFO]

[INFO] Building Apache Maven Invoker Plugin 3.0.0-SNAPSHOT
[INFO]

[INFO]
[INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @
maven-invoker-plugin ---

Something similar is happening on Windows. On Unix, the mvn launcher
fails as soon as it is used in a directory like "Spaces & Special Char".
On Windows this works. So on Windows only the -f option is affected. Can
someone take a look, please?

Just checkout some project into a directory with a name like "Spaces &
Special Char" and try to execute Maven from inside that directory and
from outside that directory using the -f option pointing to the pom
inside that directory. It won't work on Unix and Windows. I somehow lost
track on all those launcher related issues for 3.5.0 but this should
work with 3.5.0.

Regards,
-- 
Christian

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



[GitHub] maven-plugins pull request #104: MASSEMBLY-848 Do not attempt to resolve rea...

2017-02-22 Thread io7m
GitHub user io7m opened a pull request:

https://github.com/apache/maven-plugins/pull/104

MASSEMBLY-848 Do not attempt to resolve reactor projects

I'm submitting this pull request in the hope of getting some discussion on 
the issue. I feel like the submitted fix here is not the right way to solve 
this problem but do not understand enough of the way Maven resolves artifacts 
to be sure. This change does at least appear to resolve the provided 
integration test properly and does not break any existing tests.

```
This is an attempt at addressing MASSEMBLY-848: When resolving the
dependencies of a project, we explicitly avoid attempting to resolve
any dependency artifacts that are also reactor projects.
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/io7m/maven-plugins trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-plugins/pull/104.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #104


commit c1c9576c7cedc3cfb06d79350251f2a4296b308c
Author: Mark Raynsford 
Date:   2017-02-22T20:36:09Z

MASSEMBLY-848 Do not attempt to resolve reactor projects

This is an attempt at addressing MASSEMBLY-848: When resolving the
dependencies of a project, we explicitly avoid attempting to resolve
any dependency artifacts that are also reactor projects.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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



Re: Injecting MavenProject

2017-02-22 Thread Petar Tahchiev
Hey guys,

thank you for the fast response. I ended up using:

@Inject
protected Provider mavenProjectProvider;

Which works perfectly fine.

Thank you.


2017-02-22 9:12 GMT+02:00 Hervé BOUTEMY :

> IIUC, this feature is available since Maven 3.2.1 (MNG-5530)
>
> Regards,
>
> Hervé
>
> Le mardi 21 février 2017, 22:54:41 CET Igor Fedorenko a écrit :
> > MavenProject is injected as a MojoExecutionScope'd component (see
> > DefaultBuildPluginManager around line 119). Since old-style Plexus
> > components are singleton's by default, there is only one
> > AsciidoctorParser instance which holds the first MavenProject it was
> > used with for the entire build.
> >
> > Couple of ways to solve this.
> >
> > If AsciidoctorParser instances are cheap to create and are disposable,
> > then the easiest solution is to make AsciidoctorParser as non-singleton
> > (this is the default for jsr330 components, and for plexus @Component
> > use instantiationStrategy = "per-lookup").
> >
> > If AsciidoctorParser must be a singleton, then you need to use
> > javax.inject.Provider to access current context MavenProject instance.
> >
> > Hope this helps.
> >
> > > ie. see line 61 of the maven-plugin-tools annotations reference
> > > documentation
> > >
> > > http://maven.apache.org/plugin-tools/maven-plugin-tools-annotations/
> > > index.html#Supported_Annotations
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le mardi 21 février 2017, 19:47:05 CET Robert Scholte a écrit :
> > > > On Tue, 21 Feb 2017 16:16:55 +0100, Petar Tahchiev
> > > > 
> > > >
> > > > wrote:
> > > > > Hello guys,
> > > > >
> > > > > I've recently found out something weird while working with the
> > > > > asciidoctor
> > > > > maven plugin.My project has the following structure:
> > > > >
> > > > > PARENT:
> > > > >  - MODULEA
> > > > >  - MODULEB
> > > > >  - MODULEC
> > > > >
> > > > > and the asciidoctor team have created this doxia parser to be able
> to
> > > > > render asciidoc content as part of your maven site:
> > > > >
> > > > > https://github.com/asciidoctor/asciidoctor-maven-
> plugin/blob/master/sr
> > > > > c/ma
> > > > > in/java/org/asciidoctor/maven/site/AsciidoctorParser.java#L53>
> > > > >
> > > > > Note that they are injecting the MavenProject like this:
> > > > > @Requirement
> > > > > protected MavenProject project;
> > > > >
> > > > > and when I run the site generation at the PARENT (mvn clean site)
> this
> > > > > parser gets called 4 times, and all the 4 times the MavenProject
> that
> > > > > gets
> > > > > injected is PARENT.
> > > > >
> > > > > However, if I run the site generation at PARENT but tell it to
> resume
> > > > > from
> > > > > MODULEA:
> > > > >
> > > > > mvn clean site -rf :MODULEA
> > > > >
> > > > > then the MavenProject is MODULEA every time. First time it is
> MODULEA,
> > > > > second time it is MODULEA and third time it is MODULEA.
> > > > >
> > > > > This may seem like a very small difference, but if you use
> properties
> > > > > like
> > > > > ${project.build.directory} then suddenly your site and images are
> > > > > generated
> > > > > in wrong folders.
> > > > >
> > > > > My questions is:
> > > > >   1) Does it look like a bug in Maven reactor? Or perhaps plexus?
> > > >
> > > > MavenProject is not something which should work like this. It would
> mean
> > > > that project is a @Named component (JSR330), which it isn't. So I
> think
> > > > that it leaks to the plexus context, which shouldn't happen, but
> might
> > > > explain why you always get the same instance.
> > > > A MavenProject is something which needs to be passed as an argument.
> > > >
> > > > Robert
> > > >
> > > > >   2) Is there any special way that I can inject the current child
> > > > >   module
> > > > >
> > > > > of
> > > > > the mulit-module build. I want the MavenProject that is injected
> to be
> > > > > first time MODULEA, second time MODULEB and third time MODULEC.
> > > > >
> > > > > Regarding point 2 I saw Anders had the same question here:
> > > > >
> > > > > http://maven.40175.n5.nabble.com/Get-hold-of-MavenProject-
> object-of-a-> > > > modu
> > > > > le-in-a-multi-module-build-td5811486.html
> > > > >
> > > > > but I didn't get the answer.
> > > > >
> > > > > Thank you.
> > > >
> > > > 
> -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
>
> -
>