Hi,
*Phew*, boy, did I open a can of worms when fixing this..
Short: it's fixed.
Long:
I broke it... Though I only broke an obscure hack.. This code shouldn't
have been committed though I understand why it's done.
(below jdcasey's comments, there's a long piece I wrote explaining what goes
on, if you're interested
in the details).
When this was fixed I stumbled upon the next problem, which is slightly more
interesting:
The assembly goes wrong, due to the shade plugin's location of the 'dependency
reduced pom'.
I added some debug to the PluginParameterExpressionEvaluator's
'alignToBaseDirectory' method,
since the assembly plugin couldn't find '.../target/src/main/assembly/bin.xml'
(note the 'target').
Here's some output:
[java] !!!! Aligning file to basedir: '/vol/home/forge/work/opensource-rw/maven-trunks/components/maven-embedder/src/main/assembly/bin.xml'
[java] !!!! Basedir is: /vol/home/forge/work/opensource-rw/maven-trunks/components/maven-embedder/target from project file's parent: /vol/home/forge/work/opensource-rw/maven-trunks/components/maven-embedder/target/dependency-reduced-pom.xml
[java] !!!! Result: '/vol/home/forge/work/opensource-rw/maven-trunks/components/maven-embedder/target/src/main/assembly/bin.xml'
The fix here is to use ${basedir}/src/main/assembly/bin.xml.
This presents the next problem: the archiver can't find any files, due to the
bad alignment.
The basedir for the embedder is seen as '.../target/' due to the altered POM
being used as the main
project artifact.
So my fix broke the build (the build was already broken since the alpha-8-snap
of shade plugin
wasn't available).
The alignment code (PluginparameterexpressionEvaluator, last method) has to be
changed
to not use project.getFile().getParentFile(), but ${basedir} or something. The
project dir
should never change, not in the 'main build'. If you replace the POM file to
any file anywhere,
that should just be possible.
I hacked around for an hour, moving the problem along, until I finally upgraded
to shade plugin alpha-10,
which places the pom in the ${basedir}, probably just to fix this problem. So
this has probably
been a known problem for a while, and was solved (for 2.0.x), but didn't appear
on 2.1
due to me breaking a hack.
Anyway, it all works fine now (but we still need to allow any pom in any
location to be used
as the main pom without this bug reappearing).
-- Kenney
John Casey wrote:
IIRC, path resolution was taking place in the project builder...which
would mean that it could have happened during kenney's cleanup of the
interpolation. Not sure, though. (I'm fairly certain on the timing of
the path translation, though...I'm pretty sure it happened during
project-building, not plugin configuration...)
Running 'mvn help:effective-pom' using 2.0.7 and 2.1 yields different results:
With 2.0.7, the plugin configuration is untouched (i.e. the
<projectBuildDirectory>${project.build.directory}</projectBuildDirectory> is
unchanged),
but with 2.1, it's interpolated to
<projectBuildDirectory>target</projectBuildDirectory>.
I found this in DefaultMavenProjectBuilder:
// TODO: this is a hack to ensure MNG-2124 can be satisfied without
triggering MNG-1927
// MNG-1927 relies on the false assumption that ${project.build.*}
evaluates to null, which occurs before
// MNG-2124 is fixed. The null value would leave it uninterpolated, to
be handled after path translation.
// Until these steps are correctly sequenced, we guarantee these fields
remain uninterpolated.
context.put( "build.directory", null );
context.put( "build.outputDirectory", null );
context.put( "build.testOutputDirectory", null );
context.put( "build.sourceDirectory", null );
context.put( "build.testSourceDirectory", null );
Since the 'old' code (RegexBasedModelInterpolator) which I cleaned up to fix
about 5 jira issues,
has a different ordering, I'm to blame for this regression.
The old code did something like this:
value = context.get( expression );
if ( value == null && map.containsKey( expression ) )
{
continue; // i.e. leave uninterpolated.
}
This is the reason the outputs for 2.1 and 2.0.x differ. It simply is a hack
to prevent interpolation of directory expressions, so that they may be
interpolated
at runtime (for plugin params).
This fix was so elaborate that I missed this 'hacky' relationship.
So, I'm sorry for breaking this - I really didn't think I was responsible..
Anyway, some solutions:
1) Reverting my fix: I wouldn't revert my changes since it'll break 5 or so
fixed jira issues.
2) We can do the special 'don't interpolate' check in the beginning of the loop
to sustain this hack;
3) Or, since the expression _is_ evaluated to 'target', which obviously comes
from somewhere in the model, we can make sure it returns the absolute path.
The super pom contains <build><directory>target</directory>, which is a
String.
This _should_ be a java.io.File - the model won't change, just the model API.
This
is probably very bad... the fix would be to check if the value object is a
File,
and if so, convert it to a string using getAbsolutePath. Unfortunately, not
possible
(though Mojo's shouldn't access the model like that but use expressions).
4) Change the hack in DefaultMavenProjectBuilder.processProjectLogic to update
the model
before it's interpolated. We can check if the value contains an expression; if so,
leave it alone (unless we interpolate that value ourselves to see if it's an absolute
path or not); if not, convert to absolute path.
This solution requires some thinking though..
So, in short: bug tracked down, it's a regresssion. The clean fix requires some
thinking.
The hack could be cleaner to prevent future code modification to regress.
-john
On Jul 29, 2007, at 12:36 PM, Jason van Zyl wrote:
I'm trying to find the source of the problem, but it0088 is broken on
trunk and that's the very nasty ${project.build.directory} not
resolving to a full path which caused a tremendous amount of grief
between the 2.0. and 2.0.1 releases.
I can tell immediately what broke it, but if anyone was mucking about
with mojo configurations that is probably it.
The IT is it0088 which uses the support plugin here:
http://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-testing-plugins/maven-it-plugin-generate-properties/src/main/java/org/apache/maven/plugin/coreit/InterpolatedPomConfigurationMojo.java
In a nutshell the problem is that ${project.build.directory} used in a
plugin configuration like so:
<configuration>
<projectBuildDirectory>${project.build.directory}</projectBuildDirectory>
</configuration>
Is not making it into the mojo fully resolved but only as "target"
which is bad.
I will dig around but if you touched anything in the interpolation,
mojo configuration bits take a look. Once this is fixed I think we can
start pushing out early alphas for those that want to live on the edge.
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
