<attainGoal> does not use the global session

The problem:

Basically there needs to be a way to call a goal from inside another goal and
have the called goal use the current session.

The result being no new session created and all already attained goals would not
be called again by the called goal's prereqs attribute or nested <attainGoal> tags.

The only way to create a new session would be to use the <attain> tags or set <attainGoal newsession="true" name="someGoal"/> if an attribute is decided to be the way to flag session creation.

Alternatively it was suggested a new tag be added called <callGoal> which would always create a new session, and <attainGoal> would be reverted to use the current session.

Here is the thread from the mailing lists describing the problems and soltuions.

----- Original Message -----
From: "Colin Sampaleanu" <colinml1@exis.com>
To: "Turbine Maven Users List" <turbine-maven-user@jakarta.apache.org>
Cc: "Turbine Maven Developers List" <turbine-maven-dev@jakarta.apache.org>
Sent: Thursday, January 30, 2003 7:27 AM
Subject: Re: goals are broken, let's fix it

> bob mcwhirter wrote:
>
> >On Thu, 30 Jan 2003, Colin Sampaleanu wrote:
> >
> >>I think that there is currently a serious problem in maven and a number
> >>of plugins, in that 'attainGoal' is being used in various places (goals,
> >>preGoals, and postGoals) with the expectation that the goal being named
> >>to be attained will be part of the dependency graph of the main build
> >>itself, and will be attained only once. However, due to the way the
> >>werkz 'attainGoal' tag is implemented, there is no integration into the
> >>main maven dependency session, and each invocation of attainGoal with a
> >>specific goal will call that goal again including all its dependencies,
> >>becoming more of a subroutine call. At best, I would say it's confusing
> >>as hell, since the name 'attainGoal' implies something; certainly there
> >>is some code which is using the tag with the expectation that it is
> >>integrating into the dependency graph, and there is other code which is
> >>using it like a subroutine call. I would also suggest there need to be
> >>clearly named, different mechanisms, to handle both usage semantics.
> >>
> >>
> >Yah, this is a well-understood problem (at least by me, having written
> >werkz).
> >
> >Though, my non-scientific polling has resulted in me thinking that
> >most folks are now taking advantage of the fact that <attainGoal>
> >doesn't participate in the global session.
> >
> >ie:
> >
> > <attainGoal name="clean"/>
> > <attainGoal name="myproj:something"/>
> > <attainGoal name="clean"/>
> > <attainGoal name="myproj:something.else"/>
> >
> >Where 'clean' wouldn't fire the 2nd time if we shared in the global
> >session.
> >
> >We noodled around with keeping the current syntax and semantics the
> >same but adding a session="true" attribute for folks needing new
> >semantics.
> >
> >Or, since so many other things have changed lately, retaining backwards
> >compatibility is less important, and we could certain make <attainGoal>
> >behave has expected, and rename the current functionality to <callGoal>
> >or <forceAttainGoal> or somesuch.
> >
> >The biggest use-case we must accomodate is folks wanting to 'clean'
> >multple times and not have werkz think everything is still attained.
> >
> >Though, that could maybe be rememdied with something like:
> >
> > <goal name="clean">
> > <!-- normal clean stuff -->
> > <resetWerkzSession/>
> > </goal>
> >
> >That'd allow us to invalidate the werkz session and allow for rebuilds
> >without confusing werkz.
> >
> >IRC would probably be a glad place to hammer out the details.
> >
> (still cross-posting, as I think this has big implications for users as
> well as developers...)
>
> How are the IRC sessions typically arranged? i.e. when are you guys
> normally on?. My main issue with IRC is that unfortunately it is blocked
> for me during the day due to the firewall at work, although in the worst
> case I could probably ssh to my home machine and do a text mode client
> from there. Evenings wouldn't be a problem.
>
> My suggestion would be to have very clearly named mechanisms (either
> separate tags or attributes on the same tag) to attain goals and share
> the maven session, to attain goals and not share the maven session, and
> some other mechanism (such as calling a custom tag), that is encouraged
> as a means of code reuse/macro/subroutine, which some code is currently
> using attainGoal for today. I would favour making a maven (not
> necessarilly werkz) attainGoal by default share the session, given it's
> name, it'd be less confusing, but if people think backwards
> compatibility is that big an issue that is a consideration (I agree that
> a lot of stuff has changed anyways, so personally I think it is not that
> big a deal here). I would also suggest that this is important enough
> that it should be handled before beta 8 is released. If people get too
> dependent on the current usage semantics it will be way harder to change
> it later...
>
> Regards, Colin
>
>
>