On 30 Jul 07, at 6:51 PM 30 Jul 07, Kenney Westerhof wrote:
Hi,
*Phew*, boy, did I open a can of worms when fixing this..
Short: it's fixed.
Nice hunting.
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.
Yes, I had to twiddle the shade plugin.
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).
Awesome, I've done a slew of releases, all the ITs work. So barring
any nastiness we find in the next couple of days I think we can start
releasing alphas for those that are interested. I wouldn't consider
telling everyone to use them but we have to start somewhere. I
imagine the first few will be fixing problems people see with 2.1.x
versus 2.0.x. I already know of several but we have to start the
process.
-- 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]
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]
