Maven 2 & 3

${basedir} variable makes portable builds overly difficult

Details

  • Number of attachments :
    2

Description

Using log4j.xml I tried to use the resource filtering mechanism of Maven2 to write log files to the directory:

$

{basedir}/logs
(in windows)

In the end the log files indeed do end up in the project directory, but not the ./log directory.

Also the name of the log file becomes the path with all of the '\' (${file.seprator}'s taken out of it:

For instance if the path to my log file was:

"C:\dev\workspace\project\logs\project-1.0-dev_test.log"

My log file would appear in ${basedir}

and be called:

"devworkspaceprojectlogsproject-1.0-dev_test.log"

Thank you,
Andrew J. Leer

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-4713 ${basedir} variable makes portable builds overly difficult

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Emmanuel Hugonnet added a comment -

Hi,
Log4j loads its arguments as java.util.Properties (even if they are in a XML file). '\' is used as an escape parameters in Properties so you have to use '
' instead. What you propose would only postpone the problem because if you want to write to another directory $

{basedir}

/../logs for example it would fail the same way :o(.
Handling path with properties is quite annoying when you want to be cross-platform
Emmanuel

Show
Emmanuel Hugonnet added a comment - Hi, Log4j loads its arguments as java.util.Properties (even if they are in a XML file). '\' is used as an escape parameters in Properties so you have to use ' ' instead. What you propose would only postpone the problem because if you want to write to another directory $ {basedir} /../logs for example it would fail the same way :o(. Handling path with properties is quite annoying when you want to be cross-platform Emmanuel
Hide
Permalink
Jochen Wiedmann added a comment -

Note, that you can safely use C:/dev/workspace/... even on Windows. In other words, the requirement to distinguish between / and
will most likely only be present when running an external batch script or something like that. However, if you do that, then you are platform dependent anyways and should use platform specific profiles, in which case file.separator would simply make the POM unreadable.

Show
Jochen Wiedmann added a comment - Note, that you can safely use C:/dev/workspace/... even on Windows. In other words, the requirement to distinguish between / and will most likely only be present when running an external batch script or something like that. However, if you do that, then you are platform dependent anyways and should use platform specific profiles, in which case file.separator would simply make the POM unreadable.
Hide
Permalink
Brett Porter added a comment -

it sounds like a reasonable alternative was provided, please reopen if that's not the case.

Show
Brett Porter added a comment - it sounds like a reasonable alternative was provided, please reopen if that's not the case.
Hide
Permalink
Mark Michaelis added a comment -

Actually this is a real problem. Especially when working together with the config-processor-plugin.

I have a property which is defined as:

${basedir}/somepath

Now the config-processor-plugin will write a property file containing:

somepath=C:\dev/somepath

And Java will fail to read this property file as it reads:

C:dev/somepath

So this would be no problem if basedir uses slashes as file separators.

Show
Mark Michaelis added a comment - Actually this is a real problem. Especially when working together with the config-processor-plugin. I have a property which is defined as: ${basedir}/somepath Now the config-processor-plugin will write a property file containing: somepath=C:\dev/somepath And Java will fail to read this property file as it reads: C:dev/somepath So this would be no problem if basedir uses slashes as file separators.
Hide
Permalink
Paul Benedict added a comment -

I configure my log4j and send its files to {{$

{project.build.directory}

/logs}}. My rule of thumb is anything and everything transitory should end up in the build directory.

Show
Paul Benedict added a comment - I configure my log4j and send its files to {{$ {project.build.directory} /logs}}. My rule of thumb is anything and everything transitory should end up in the build directory.
Hide
Permalink
Gili added a comment -

Please reopen this issue!

Show
Gili added a comment - Please reopen this issue!
Hide
Permalink
Brett Porter added a comment -

please open an issue in the resources plugin if you need a feature to get the basedir using unix-style separators. I don't believe this is needed in the core. I assume this is only for test cases and plugins run through the build - note that you can also rely on the basedir being the work directory, so you can use relative paths.

Show
Brett Porter added a comment - please open an issue in the resources plugin if you need a feature to get the basedir using unix-style separators. I don't believe this is needed in the core. I assume this is only for test cases and plugins run through the build - note that you can also rely on the basedir being the work directory, so you can use relative paths.

People

  • Assignee:
    Brett Porter
    Reporter:
    Andrew J. Leer
Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: