Problem using project.name as build directory

["Arend v. Reinersdorff" <ar...@arendvr.com>]

Hi,

usually when project.name is not set, it defaults to project.artifactId.
But when I set <build><directory>${project.name}</directory></build>, it
seems to not use the default in some places.

Setup:
- project.name is not explicitly set
- project.build.directory set to ${project.name}
- a Java class under src/main
- a unit test under src/test

Example project:
https://code.google.com/p/outsidedirectorywithname/source/browse/

Reproduce problem:
mvn -X clean test

Result:
Build fails during compilation of unit test:
COMPILATION ERROR :
[ERROR]
\opt\gitrepos\outsidedirectorywithname\src\test\java\com\example\outsidedirectorywithname\GreeterTest.java:[3,43]
error: cannot find symbol

Complete output:
https://code.google.com/p/outsidedirectorywithname/source/browse/output-failed-build.txt


When I echo project.name with antrun, it defaults to project.artifactId as
expected.
When I set project.name in pom.xml, the build succeeds. Complete fixed
output:
https://code.google.com/p/outsidedirectorywithname/source/browse/output-fixed-by-setting-project-name.txt

In the debug output (-X) I see places where "${project.name}" appears, for
example
[DEBUG]   (f) classpathElements =
[C:\opt\gitrepos\outsidedirectorywithname\${project.name}\classes]
When I set project.name, this works fine:
[DEBUG]   (f) classpathElements =
[C:\opt\gitrepos\outsidedirectorywithname\outsidedirectorywithname\classes]


Why doesn't project.name default to project.artifactId in this case? Is
this a bug? Or is there a reason why I cannot rely on the default value
here?

Regards,
Arend v. Reinersdorff

Re: Problem using project.name as build directory

["Arend v. Reinersdorff" <ar...@arendvr.com>]

On Mon, Jul 8, 2013 at 2:06 PM, Baptiste MATHUS <bm...@batmat.net> wrote:

> As a side note, I would personnally prefer that there's no such fallback.
> I'm not sure I see much value here. In this cas it seems preferable to just
> use ${project.artifactId}.
>

Agreed. I'll do this to fix my project.
But I'm still curious what the correct behavior is.

Regards.

Re: Problem using project.name as build directory

[Baptiste MATHUS <bm...@batmat.net>]

I didn't dig in the code, but looking at that reference page :
http://maven.apache.org/pom.html#More_Project_Information

If there's no mention about this point here. This is either an important
missing statement or simply not guaranteed.

As a side note, I would personnally prefer that there's no such fallback.
I'm not sure I see much value here. In this cas it seems preferable to just
use ${project.artifactId}.

Cheers



2013/7/8 Arend v. Reinersdorff <ar...@arendvr.com>

> On Sun, Jul 7, 2013 at 3:22 PM, Baptiste MATHUS <bm...@batmat.net>
> wrote:
>
> > That being said, I'm not sure project.name is guaranteed to fallback to
> > project.artifactId value. So you might be relying on something unstable
> > here.
> >
> This is a good point. I remember reading somewhere that project.name falls
> back to project.artifactId. But I can't find the reference anymore.
>
> Does anyone know if the fallback behavior of project.name is officially
> documented anywhere?
>
> Regards,
> Arend
>



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

Re: Problem using project.name as build directory

["Arend v. Reinersdorff" <ar...@arendvr.com>]

On Sun, Jul 7, 2013 at 3:22 PM, Baptiste MATHUS <bm...@batmat.net> wrote:

> That being said, I'm not sure project.name is guaranteed to fallback to
> project.artifactId value. So you might be relying on something unstable
> here.
>
This is a good point. I remember reading somewhere that project.name falls
back to project.artifactId. But I can't find the reference anymore.

Does anyone know if the fallback behavior of project.name is officially
documented anywhere?

Regards,
Arend

Re: Problem using project.name as build directory

[Baptiste MATHUS <bm...@batmat.net>]

Hi,

I tested quickly your project, I guess you should file an issue against
MCOMPILER with your test project (check it's not already there).

That being said, I'm not sure project.name is guaranteed to fallback to
project.artifactId value. So you might be relying on something unstable
here.
I'd advice you to use something really defined like ${project.artifactId},
or even far better to *not* define the directory tag and leave the default
value.

Cheers

Apart from


2013/7/7 Arend v. Reinersdorff <ar...@arendvr.com>

> Hi,
>
> usually when project.name is not set, it defaults to project.artifactId.
> But when I set <build><directory>${project.name}</directory></build>, it
> seems to not use the default in some places.
>
> Setup:
> - project.name is not explicitly set
> - project.build.directory set to ${project.name}
> - a Java class under src/main
> - a unit test under src/test
>
> Example project:
> https://code.google.com/p/outsidedirectorywithname/source/browse/
>
> Reproduce problem:
> mvn -X clean test
>
> Result:
> Build fails during compilation of unit test:
> COMPILATION ERROR :
> [ERROR]
>
> \opt\gitrepos\outsidedirectorywithname\src\test\java\com\example\outsidedirectorywithname\GreeterTest.java:[3,43]
> error: cannot find symbol
>
> Complete output:
>
> https://code.google.com/p/outsidedirectorywithname/source/browse/output-failed-build.txt
>
>
> When I echo project.name with antrun, it defaults to project.artifactId as
> expected.
> When I set project.name in pom.xml, the build succeeds. Complete fixed
> output:
>
> https://code.google.com/p/outsidedirectorywithname/source/browse/output-fixed-by-setting-project-name.txt
>
> In the debug output (-X) I see places where "${project.name}" appears, for
> example
> [DEBUG]   (f) classpathElements =
> [C:\opt\gitrepos\outsidedirectorywithname\${project.name}\classes]
> When I set project.name, this works fine:
> [DEBUG]   (f) classpathElements =
> [C:\opt\gitrepos\outsidedirectorywithname\outsidedirectorywithname\classes]
>
>
> Why doesn't project.name default to project.artifactId in this case? Is
> this a bug? Or is there a reason why I cannot rely on the default value
> here?
>
> Regards,
> Arend v. Reinersdorff
>



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