Colin, Thanks for driving this,
Let me know if you need a guinea pig. -Peter ----- Original Message ----- From: "Colin Sampaleanu" <[EMAIL PROTECTED]> To: "Turbine Maven Developers List" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > >To: "Turbine Maven Users List" <[EMAIL PROTECTED]> > >Cc: "Turbine Maven Developers List" <[EMAIL PROTECTED]> > >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: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
