[jira] Commented: (MAVEN-256) does not use the global session

[ji...@codehaus.org]

The following comment has been added to this issue:

     Author: Arik Kfir
    Created: Thu, 17 Jun 2004 5:53 PM
       Body:
I'm just a humble (happy) user, but I think this really should go in the 1.0 release.

The bulk of users for Maven will come with experience with Ant, and as we know, Ant does implement this behavior (using the same "session"), and this will create much confusion I believe.

Ofcourse, that beside the fact that it makes the builds longer (my app gets compiled twice - once on jar:deploy and once on dist:deploy, when I perform a full release).

---------------------------------------------------------------------
View this comment:
  http://jira.codehaus.org/browse/MAVEN-256?page=comments#action_20779

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/browse/MAVEN-256

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: MAVEN-256
    Summary: <attainGoal> does not use the global session
       Type: Bug

     Status: Open
   Priority: Critical

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: maven
 Components: 
             core
   Fix Fors:
             1.1
   Versions:
             1.0-beta-8

   Assignee: bob mcwhirter
   Reporter: Peter Lynch

    Created: Thu, 6 Feb 2003 4:00 AM
    Updated: Thu, 17 Jun 2004 5:53 PM

Description:
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" <co...@exis.com>
To: "Turbine Maven Users List" <tu...@jakarta.apache.org>
Cc: "Turbine Maven Developers List" <tu...@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
> 
> 
> 



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org