You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Peter Lynch <pe...@mindspring.com> on 2003/02/06 10:08:22 UTC
Re: goals are broken, let's fix it
Is there going to be any/was there any conclusion to this. <callGoal /> works
for me. So does session="true".
I am all for picking something, because if not I basically have to rewrite
webserver/appserver plugins yet again. They depend heavily on the idea of goals
being already attained.
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.
All this used to work, and now it doesn't at all. I have goals being re-attained
all over the place now even when I want them in the same session.
Do I have to set my own property flags to tell me goals have already been
attained or can we get a fix in. I volunteer to be the tester.
I have opened a critical issue:
http://jira.werken.com/secure/ViewIssue.jspa?id=10433&vote=vote
Thanks,
-Peter
----- 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
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
>
Re: goals are broken, let's fix it
Posted by Peter Lynch <pe...@mindspring.com>.
Colin,
Thanks for driving this,
Let me know if you need a guinea pig.
-Peter
----- Original Message -----
From: "Colin Sampaleanu" <co...@exis.com>
To: "Turbine Maven Developers List" <tu...@jakarta.apache.org>
Sent: Thursday, February 06, 2003 6:21 AM
Subject: Re: goals are broken, let's fix it
> I've created some changes for werkz (the subsequent code in Maven to
> take advantage of them would be trivial). I just need to stabilize with
> Bob M. and Jason exactly what gets submitted. I have one solution that
> would be completely backwards compatible but is not as clean, while
> another that is cleaner has no issues with maven plugins (since those
> are in CVS and can be changed), but has the potential to affect end-user
> maven jelly scripts (maven.xml basically) where the user is depending on
> the old behaviour.
>
> I'll try to do some email with Bob and Jason and get this resolved today...
>
> Peter Lynch wrote:
>
> >Is there going to be any/was there any conclusion to this. <callGoal /> works
> >for me. So does session="true".
> >
> >I am all for picking something, because if not I basically have to rewrite
> >webserver/appserver plugins yet again. They depend heavily on the idea of
goals
> >being already attained.
> >
> >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.
> >
> >All this used to work, and now it doesn't at all. I have goals being
re-attained
> >all over the place now even when I want them in the same session.
> >
> >Do I have to set my own property flags to tell me goals have already been
> >attained or can we get a fix in. I volunteer to be the tester.
> >
> >I have opened a critical issue:
> >http://jira.werken.com/secure/ViewIssue.jspa?id=10433&vote=vote
> >
> >Thanks,
> >
> >-Peter
> >
> >----- 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
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
> >>
> >>
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
>
Re: goals are broken, let's fix it
Posted by Colin Sampaleanu <co...@exis.com>.
I've created some changes for werkz (the subsequent code in Maven to
take advantage of them would be trivial). I just need to stabilize with
Bob M. and Jason exactly what gets submitted. I have one solution that
would be completely backwards compatible but is not as clean, while
another that is cleaner has no issues with maven plugins (since those
are in CVS and can be changed), but has the potential to affect end-user
maven jelly scripts (maven.xml basically) where the user is depending on
the old behaviour.
I'll try to do some email with Bob and Jason and get this resolved today...
Peter Lynch wrote:
>Is there going to be any/was there any conclusion to this. <callGoal /> works
>for me. So does session="true".
>
>I am all for picking something, because if not I basically have to rewrite
>webserver/appserver plugins yet again. They depend heavily on the idea of goals
>being already attained.
>
>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.
>
>All this used to work, and now it doesn't at all. I have goals being re-attained
>all over the place now even when I want them in the same session.
>
>Do I have to set my own property flags to tell me goals have already been
>attained or can we get a fix in. I volunteer to be the tester.
>
>I have opened a critical issue:
>http://jira.werken.com/secure/ViewIssue.jspa?id=10433&vote=vote
>
>Thanks,
>
>-Peter
>
>----- 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
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
>
>
>
Re: goals are broken, let's fix it
Posted by bob mcwhirter <bo...@werken.com>.
> It's almost moot, anyways. I have new code which handles all cases (new
> session, session from parent tag, session from context, both) including
> unit tests and new javadocs. I just need to hear from Bob and Jason
> whether they want the variant that by default behaves exactly like the
> old tag, or the one which 'fixes' things by default.
Yah, I've gotten you mails, still just pondering.
I am leaning towards changing the semantics of <attainGoal>
to work with the global session by default. We're still in
beta, it's good to fix broken windows.
-bob
Re: goals are broken, let's fix it
Posted by Colin Sampaleanu <co...@exis.com>.
I'm sure it's clear to Bob exactly what he originally intended, but
externally it's a bit grayer... It's clear attainGoal was originally
supposed to be used inside the attain tag to combine goals, in a new
session. Above and beyond that, it's somewhat of a guess, since in fact
attainGoal has bad javadocs (they are the docs for attain, not
attainGoal). The only way somebody could really know how it works by
itself is by looking at the source. In any case, at this point, most of
the plugins that use it, use it by itself, but very clearly aren't
expecting it to be in a new session, but the current session, so there
is a problem.
It's almost moot, anyways. I have new code which handles all cases (new
session, session from parent tag, session from context, both) including
unit tests and new javadocs. I just need to hear from Bob and Jason
whether they want the variant that by default behaves exactly like the
old tag, or the one which 'fixes' things by default. I have made the
case that the latter is actually better, since most existing plugin code
is actually expecting shared sessions but are getting new sessions (so
is wrong), and we can easily handle all the code in CVS. The only
question is user code (maven.xml), but based on looking at the plugins,
I would guess most user code is similar, wanting to use the current session.
Colin
Peter Lynch wrote:
>Bob,
>
>Are there not just two cases we need to allow. Use the current session or make a
>new session??
>
>In that case, has it not always been:
>
><!-- New Session -->
><attain>
> <attainGoal name="someGoal" />
></attain>
>
><!-- Same session -->
><attainGoal name="someGoal" />
>
>or your case...
>
><atain>
> <attainGoal name="clean"/>
></attain>
><attainGoal name="myproj:something"/>
>
><atain>
> <attainGoal name="clean"/>
></attain>
><attainGoal name="myproj:something.else"/>
>
>I am so sure that attainGoal used the current session at one time.
>
>There are two reasons why I think that.
>
>1.) previous appserver plugin implementations relied on that and that plugin did
>work at one time around beta 5 of Maven.
>
>2.) why was the <attain> tag invented?
>
>So why not just require those wanting a new session to wrap the attainGoal in an
>attain tag, otherwise leave the attainGoal tag to use the same session?
>
>-Peter
>
>
>----- Original Message -----
>From: "bob mcwhirter" <bo...@werken.com>
>To: "Turbine Maven Developers List" <tu...@jakarta.apache.org>;
>"Peter Lynch" <pe...@mindspring.com>
>Cc: "Turbine Maven Users List" <tu...@jakarta.apache.org>
>Sent: Thursday, February 06, 2003 8:12 AM
>Subject: Re: goals are broken, let's fix it
>
>
>
>
>>I think we decided to -not- change the semantics of existing
>><attainGoal> tags. Either a new tag or a session="true" for
>>new semantics. So, existing code should be safe.
>>
>>-bob
>>
>>On Thu, 6 Feb 2003, Peter Lynch wrote:
>>
>>
>>
>>>Is there going to be any/was there any conclusion to this. <callGoal />
>>>
>>>
>works
>
>
>>>for me. So does session="true".
>>>
>>>I am all for picking something, because if not I basically have to rewrite
>>>webserver/appserver plugins yet again. They depend heavily on the idea of
>>>
>>>
>goals
>
>
>>>being already attained.
>>>
>>>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.
>>>
>>>All this used to work, and now it doesn't at all. I have goals being
>>>
>>>
>re-attained
>
>
>>>all over the place now even when I want them in the same session.
>>>
>>>Do I have to set my own property flags to tell me goals have already been
>>>attained or can we get a fix in. I volunteer to be the tester.
>>>
>>>I have opened a critical issue:
>>>http://jira.werken.com/secure/ViewIssue.jspa?id=10433&vote=vote
>>>
>>>Thanks,
>>>
>>>-Peter
>>>
>>>----- 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
>>>>
>>>>
Re: goals are broken, let's fix it
Posted by Peter Lynch <pe...@mindspring.com>.
Bob,
Are there not just two cases we need to allow. Use the current session or make a
new session??
In that case, has it not always been:
<!-- New Session -->
<attain>
<attainGoal name="someGoal" />
</attain>
<!-- Same session -->
<attainGoal name="someGoal" />
or your case...
<atain>
<attainGoal name="clean"/>
</attain>
<attainGoal name="myproj:something"/>
<atain>
<attainGoal name="clean"/>
</attain>
<attainGoal name="myproj:something.else"/>
I am so sure that attainGoal used the current session at one time.
There are two reasons why I think that.
1.) previous appserver plugin implementations relied on that and that plugin did
work at one time around beta 5 of Maven.
2.) why was the <attain> tag invented?
So why not just require those wanting a new session to wrap the attainGoal in an
attain tag, otherwise leave the attainGoal tag to use the same session?
-Peter
----- Original Message -----
From: "bob mcwhirter" <bo...@werken.com>
To: "Turbine Maven Developers List" <tu...@jakarta.apache.org>;
"Peter Lynch" <pe...@mindspring.com>
Cc: "Turbine Maven Users List" <tu...@jakarta.apache.org>
Sent: Thursday, February 06, 2003 8:12 AM
Subject: Re: goals are broken, let's fix it
>
> I think we decided to -not- change the semantics of existing
> <attainGoal> tags. Either a new tag or a session="true" for
> new semantics. So, existing code should be safe.
>
> -bob
>
> On Thu, 6 Feb 2003, Peter Lynch wrote:
>
> > Is there going to be any/was there any conclusion to this. <callGoal />
works
> > for me. So does session="true".
> >
> > I am all for picking something, because if not I basically have to rewrite
> > webserver/appserver plugins yet again. They depend heavily on the idea of
goals
> > being already attained.
> >
> > 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.
> >
> > All this used to work, and now it doesn't at all. I have goals being
re-attained
> > all over the place now even when I want them in the same session.
> >
> > Do I have to set my own property flags to tell me goals have already been
> > attained or can we get a fix in. I volunteer to be the tester.
> >
> > I have opened a critical issue:
> > http://jira.werken.com/secure/ViewIssue.jspa?id=10433&vote=vote
> >
> > Thanks,
> >
> > -Peter
> >
> > ----- 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
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
turbine-maven-user-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
> >
>
> --
> Bob McWhirter bob@werken.com
> The Werken Company http://werken.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
>
Re: goals are broken, let's fix it
Posted by bob mcwhirter <bo...@werken.com>.
I think we decided to -not- change the semantics of existing
<attainGoal> tags. Either a new tag or a session="true" for
new semantics. So, existing code should be safe.
-bob
On Thu, 6 Feb 2003, Peter Lynch wrote:
> Is there going to be any/was there any conclusion to this. <callGoal /> works
> for me. So does session="true".
>
> I am all for picking something, because if not I basically have to rewrite
> webserver/appserver plugins yet again. They depend heavily on the idea of goals
> being already attained.
>
> 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.
>
> All this used to work, and now it doesn't at all. I have goals being re-attained
> all over the place now even when I want them in the same session.
>
> Do I have to set my own property flags to tell me goals have already been
> attained or can we get a fix in. I volunteer to be the tester.
>
> I have opened a critical issue:
> http://jira.werken.com/secure/ViewIssue.jspa?id=10433&vote=vote
>
> Thanks,
>
> -Peter
>
> ----- 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: turbine-maven-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: turbine-maven-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
>
--
Bob McWhirter bob@werken.com
The Werken Company http://werken.com/