You know someone is going to also desire not just the timestamp, but only
the time, or just the date. If you're doing the work now, might as well
throw in the other 2.
Paul
On Sun, Jun 22, 2008 at 1:46 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> Hi John,
>
> The document doesn't exactly explain what you were doing other than
> swapping in plexus-interpolation. Is that effectively the gist of it? Better
> isolating the code without making any functional changes so it is more
> stable, while the other proposal was for fixing something?
>
> The code looks good to me. The devil is always in the details and I'm happy
> with it as long as we've battle tested it enough. It won't hit all the
> cases, but I was thinking I could extend my tool that resolves all the POMs
> in a repository (tried against central) and see if this yields different
> results with the new interp code. WDYT?
>
> Small comment on the RegexBasedModelInterpolator - the static block could
> be replaced with an array initializer like you have above it for the other
> var :)
>
> With the build timestamp addition, I'm not sure if I like that the format
> is specified by an arbitrary property in the POM? Just a thought really - I
> would hope plugins can access the variable for the actual date and use it
> more than being able to substitute it into the POM (bear in mind two
> different uses might want different formats in the same POM). Possibly
> getting a bit "out there", but what if we could paramaterise interpolation
> for certain formats instead? eg. ${maven.build.timestamp|format='yyyyMMdd'}
>
> Cheers,
> Brett
>
>
> On 17/06/2008, at 3:35 AM, John Casey wrote:
>
> Hi everyone,
>>
>> I wanted to start another discussion having to do with POM interpolation
>> in the upcoming Maven 2.0.10 release. If you recall, I previously sent out a
>> proposal for retaining dynamic expressions in the build section of the POM,
>> to allow updates to that section that take place via plugin execution to be
>> reflected in subsequent executions.
>>
>> This proposal is somewhat different, and is mostly orthogonal to that
>> previous discussion. This proposal is less about _when_ we interpolate
>> different parts of the POM, and more about _how_ we do it. Since before its
>> original release, Maven has used a single-class implementation of the
>> ModelInterpolator used to resolve expressions in the POM. As we learned more
>> about what we needed to support in POM expressions - and, what the order of
>> operations was for interpolating - this single class quickly grew into quite
>> a beast of tangled conditional logic and loops. Even the interface and the
>> code surrounding the call to that interface were abused more than a little,
>> as we tried to trick the interpolator into making exceptions of certain
>> parts of the POM, and prioritizing certain sources of expression values over
>> others.
>>
>> The full proposal is here:
>> http://docs.codehaus.org/display/MAVEN/POM+Interpolation+Refactor
>>
>> As a brief synopsis:
>>
>> For anyone who has tried to improve the interpolator ahead of a 2.0.x
>> release, you already know what I'm talking about; the interpolator has been
>> limping along for some time now. For anyone who hasn't spent much time on
>> this functionality, a quick scan of JIRA for any given release will show you
>> how persistent and varied the interpolation problems have been. It has
>> reached the point where solving these problems within the current
>> implementation often requires threading your way through rules that seem
>> diametrically opposed to one another.
>>
>> At the same time, I've been working on the interpolation code in
>> plexus-utils for use in the Assembly plugin (and though I'm not sure who you
>> are, I know others are using plexus-utils for interpolation as well). I
>> believe this code has reached a level of maturity and sophistication that
>> will allow us to replace the original interpolator in maven-project with a
>> less-complex solution implemented around this plexus-utils code. However,
>> because of the historic problems with plexus-utils in Maven, and because
>> plexus-utils contains several other hotspots of variability like the CLI
>> code used to fork child processes, I split this interpolation code out into
>> a new library called plexus-interpolation. The old plexus-utils classes now
>> depend on plexus-interpolation, which is shaded into plexus-utils until
>> those deprecated classes can be removed.
>>
>> Additionally, I've implemented this refactor on a feature branch, so you
>> can take a look at:
>>
>>
>> https://svn.apache.org/repos/asf/maven/components/branches/john-2.0.x-plxInterpolation
>>
>> to see the actual implementation.
>>
>> Please take a look and tell me what you think.
>>
>> Thanks,
>>
>> -john
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
