You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by bw...@apache.org on 2003/01/30 11:59:36 UTC
cvs commit: jakarta-turbine-maven/src/plugins-build/linkcheck/xdocs goals.xml navigation.xml properties.xml .cvsignore index.xml
bwalding 2003/01/30 02:59:36
Added: src/plugins-build/linkcheck/xdocs goals.xml navigation.xml
properties.xml .cvsignore index.xml
Log:
MAVEN-214: LinkChecker plugin
Revision Changes Path
1.1 jakarta-turbine-maven/src/plugins-build/linkcheck/xdocs/goals.xml
Index: goals.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<document>
<properties>
<title>Maven Link Check Plug-in Goals</title>
<author email="ben@walding.com">Ben Walding</author>
</properties>
<body>
<goals>
<goal>
<name>linkcheck</name>
<description></description>
</goal>
<goal>
<name>report</name>
<description></description>
</goal>
</goals>
</body>
</document>
1.1 jakarta-turbine-maven/src/plugins-build/linkcheck/xdocs/navigation.xml
Index: navigation.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<project name="Maven Link Check Plugin">
<title>Maven junit-report Plugin</title>
<body>
<links>
<item href="http://jakarta.apache.org/turbine/maven/" name="Maven">
</item>
</links>
<menu name="Overview">
<item href="/goals.html" name="Goals">
</item>
<item href="/properties.html" name="Properties">
</item>
</menu>
</body>
</project>
1.1 jakarta-turbine-maven/src/plugins-build/linkcheck/xdocs/properties.xml
Index: properties.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<document>
<properties>
<title>junit-report Properties</title>
<author email="dion@apache.org">dIon Gillard</author>
</properties>
<body>
<section name="junit-report Settings">
<table>
<tr>
<th>Property</th>
<th>Optional?</th>
<th>Description</th>
</tr>
<tr>
<td>maven.linkcheck.enable</td>
<td>Yes</td>
<td>If defined, the report is enabled
<p>Default value is
<code>undefined</code>.</p>
</td>
</tr>
<tr>
<td>maven.linkcheck.baseurl</td>
<td>No</td>
<td>Used to create links to live documents
</td>
</tr>
<tr>
<td>maven.conf.dir</td>
<td>Yes</td>
<td>
<p>Default value is
<code>${basedir}/conf</code>.</p>
</td>
</tr>
<tr>
<td>maven.gen.docs</td>
<td>Yes</td>
<td>
<p>Default value is
<code>${maven.build.dir}/generated-xdocs</code>.</p>
</td>
</tr>
<tr>
<td>maven.docs.src</td>
<td>Yes</td>
<td>
<p>Default value is
<code>${basedir}/xdocs</code>.</p>
</td>
</tr>
<tr>
<td>maven.build.dir</td>
<td>Yes</td>
<td>
<p>Default value is
<code>${basedir}/target</code>.</p>
</td>
</tr>
<tr>
<td>maven.docs.dest</td>
<td>Yes</td>
<td>
<p>Default value is
<code>${maven.build.dir}/docs</code>.</p>
</td>
</tr>
<tr>
<td>maven.docs.outputencoding</td>
<td>Yes</td>
<td>
<p>Default value is
<code>ISO-8859-1</code>.</p>
</td>
</tr>
</table>
</section>
</body>
</document>
1.1 jakarta-turbine-maven/src/plugins-build/linkcheck/xdocs/.cvsignore
Index: .cvsignore
===================================================================
stylesheets
1.1 jakarta-turbine-maven/src/plugins-build/linkcheck/xdocs/index.xml
Index: index.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Maven LinkCheck Plug-in</title>
<author email="ben@walding.com">Ben Walding</author>
</properties>
<body>
<section name="Maven LinkCheck Plug-in">
<p>
This plug-in validates the HTML that is produced as part of the site
</p>
</section>
<section name="Future Features">
<p>
This section holds a list of possible future features that might be nice
to have implemented. (In decreasing order of importance)
</p>
<p>
<ol>
<li>The ability to include exclude parts of the tree</li>
<li>Persists remote url checks across runs</li>
</ol>
</p>
</section>
</body>
</document>
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/
Re: goals are broken, let's fix it
Posted by Peter Lynch <pe...@mindspring.com>.
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 di...@multitask.com.au.
Colin Sampaleanu <co...@exis.com> wrote on 31/01/2003 03:30:09 AM:
[snip good stuff]
> I feel strongly enough that this is likely to cause confusion and pain
> for maven users that I'm willing to put my money where my mouth is and
> try to implement a solution myself which I can submit as a patch. It
> will take some time since I have to do it in the evenings after I am
> done with the kids, and I don't know maven internals that well. I do
> agree that the werkz tag (attainGoal) itself probably shouldn't be
> changed. There is really nothing that wrong with it, when used as a
> child of the attain tag. I would suggest that I should implement another
> tag or two that is specific to maven, and that effectively work fairly
> similarly, with control of session inheritance. Once that tag or tags
> is/are available, they are pushed as preferred in usage over attainGoal.
>
> Does that sound reasonable?
It does.
I'm +1 on it. (Agree & willing to help).
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: goals are broken, let's fix it
Posted by Colin Sampaleanu <co...@exis.com>.
Jason van Zyl wrote:
>On Thu, 2003-01-30 at 10:27, Colin Sampaleanu wrote:
>
>
> 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...
>>
>>
>
>None of these are issues we aren't aware of. Almost all the pieces
>involved have been written/augmented by Bob, Dion and myself and I'm
>loathe to change the behaviour of werkz. If anything an attribute can be
>used to signify a different behaviour of a different tag all together.
>
>
The fact that the three of you know about it doesn't negate the fact
that is some respects this is a very serious issue, affecting
fundamental usage of maven. I doubt most users coming to maven will know
about it, and I don't see it mentioned anywhere in the tasks for beta 8,
beta 9, or post beta 9, which is why I brought it up at this time.
I feel strongly enough that this is likely to cause confusion and pain
for maven users that I'm willing to put my money where my mouth is and
try to implement a solution myself which I can submit as a patch. It
will take some time since I have to do it in the evenings after I am
done with the kids, and I don't know maven internals that well. I do
agree that the werkz tag (attainGoal) itself probably shouldn't be
changed. There is really nothing that wrong with it, when used as a
child of the attain tag. I would suggest that I should implement another
tag or two that is specific to maven, and that effectively work fairly
similarly, with control of session inheritance. Once that tag or tags
is/are available, they are pushed as preferred in usage over attainGoal.
Does that sound reasonable?
Colin
Re: goals are broken, let's fix it
Posted by di...@multitask.com.au.
Jason van Zyl <ja...@zenplex.com> wrote on 31/01/2003 02:51:48 AM:
> On Thu, 2003-01-30 at 10:27, Colin Sampaleanu wrote:
> > bob mcwhirter wrote:
> >
>
> 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...
>
> None of these are issues we aren't aware of. Almost all the pieces
> involved have been written/augmented by Bob, Dion and myself and I'm
> loathe to change the behaviour of werkz. If anything an attribute can be
> used to signify a different behaviour of a different tag all together.
Just for my 2 bits.
I understand where Colin is coming from, and understand the naming might
throw people off, but, changing the behaviour of attainGoal at the moment
will be counterintuitive to the existing users. Taking the existing
behaviour and renaming it, whilst leaving the existing tag and changing
it's behaviour is a recipe for disaster, IMHO.
For the new behaviour of "attain this goal if it hasn't already been
done", I'm happy to have a shared="true" attribute or sharedSession="true"
attribute. But let's not break the way the tag works and introduce a
replacement with a new name.
--
dIon Gillard, Multitask Consulting
Blog: http://www.freeroller.net/page/dion/Weblog
Work: http://www.multitask.com.au
Re: goals are broken, let's fix it
Posted by Jason van Zyl <ja...@zenplex.com>.
On Thu, 2003-01-30 at 10:27, Colin Sampaleanu wrote:
> bob mcwhirter wrote:
>
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...
None of these are issues we aren't aware of. Almost all the pieces
involved have been written/augmented by Bob, Dion and myself and I'm
loathe to change the behaviour of werkz. If anything an attribute can be
used to signify a different behaviour of a different tag all together.
> Regards, Colin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
Re: goals are broken, let's fix it
Posted by Peter Lynch <pe...@mindspring.com>.
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 Colin Sampaleanu <co...@exis.com>.
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 Colin Sampaleanu <co...@exis.com>.
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 Donald <pe...@realityforge.org>.
On Fri, 31 Jan 2003 02:09, bob mcwhirter wrote:
> 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.
+1 to having a completely separate tag for different way of doing the
"calling". The "ant/antcall" tasks from ant suck when they try to blend both
functions and this has led to more than one backwards incompatible change as
ant evolved.
--
Cheers,
Peter Donald
A right is not what someone gives you; it's what no one can take from you.
-- Ramsey Clark
Re: goals are broken, let's fix it
Posted by bob mcwhirter <bo...@werken.com>.
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.
-bob
Re: goals are broken, let's fix it
Posted by bob mcwhirter <bo...@werken.com>.
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.
-bob
goals are broken, let's fix it
Posted by Colin Sampaleanu <co...@exis.com>.
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.
To explain in better detail, consider the following maven.xml file:
<project
xmlns:j="jelly:core"
xmlns:maven="jelly:maven"
xmlns:log="jelly:log"
>
<preGoal name="java:compile">
<attainGoal name="my:goal"/>
</preGoal>
<preGoal name="java:jar">
<attainGoal name="my:goal"/>
</preGoal>
<goal name="my:goal">
<log:info>this is my:goal!</log:info>
</goal>
</project>
A number of plugins (and presumably user maven.xml files) are written in
a similar fashion, doing an attainGoal on something like 'java:compile',
etc. with the expectation that they are inserting themselves into the
main dependency chain. What they are really doing is calling the goal in
question again, including all of its dependencies. In the case above,
the my:goal goal is called twice, if I invoke
maven java:jar
The issue stems from the fact that werkz's attainGoal tag doesn't know
anything about the main Maven goals session. It is mean to be used as a
child of the attain tag, as follows:
<attain>
<attainGoal name="aGoal">
<attainGoal name="anotherGoal">
<attainGoal name="aThirdGoal">
</attain>
In this usage, the dependency session is stored by the attain tag, and
each of the attainGoal tags will use the session from the parent attain
tag, so all the goals will use the same dependency session, and a goal
will only be called once.
When attainGoal is used by itself in a jelly script in Maven, as it is
commonly used, a new session is created just for that invocation. The
goal in question, and all of its dependencies, is simply called again,
regardless of whether or not that goal or any dependent goals have
already been attained in the build session.
My suggested solution is to create a maven tag which essentially calls
werkz's attainGoal, but uses the parent maven goal session. For people
that want to call goals in a subroutine like fashion (as the current
attainGoal usage does), another tag with another name (invokeGoal) would
be created, which exists just to have a clearer name, and would delegate
to the existing attainGoal tag. I would however discourage usage of
goals as subroutines, this should be handled by some other mechanism,
such as defining custom tags and invoking them. I think it's a lot
clearer if goals are generally part of the dependency graph...
Any comments?
goals are broken, let's fix it
Posted by Colin Sampaleanu <co...@exis.com>.
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.
To explain in better detail, consider the following maven.xml file:
<project
xmlns:j="jelly:core"
xmlns:maven="jelly:maven"
xmlns:log="jelly:log"
>
<preGoal name="java:compile">
<attainGoal name="my:goal"/>
</preGoal>
<preGoal name="java:jar">
<attainGoal name="my:goal"/>
</preGoal>
<goal name="my:goal">
<log:info>this is my:goal!</log:info>
</goal>
</project>
A number of plugins (and presumably user maven.xml files) are written in
a similar fashion, doing an attainGoal on something like 'java:compile',
etc. with the expectation that they are inserting themselves into the
main dependency chain. What they are really doing is calling the goal in
question again, including all of its dependencies. In the case above,
the my:goal goal is called twice, if I invoke
maven java:jar
The issue stems from the fact that werkz's attainGoal tag doesn't know
anything about the main Maven goals session. It is mean to be used as a
child of the attain tag, as follows:
<attain>
<attainGoal name="aGoal">
<attainGoal name="anotherGoal">
<attainGoal name="aThirdGoal">
</attain>
In this usage, the dependency session is stored by the attain tag, and
each of the attainGoal tags will use the session from the parent attain
tag, so all the goals will use the same dependency session, and a goal
will only be called once.
When attainGoal is used by itself in a jelly script in Maven, as it is
commonly used, a new session is created just for that invocation. The
goal in question, and all of its dependencies, is simply called again,
regardless of whether or not that goal or any dependent goals have
already been attained in the build session.
My suggested solution is to create a maven tag which essentially calls
werkz's attainGoal, but uses the parent maven goal session. For people
that want to call goals in a subroutine like fashion (as the current
attainGoal usage does), another tag with another name (invokeGoal) would
be created, which exists just to have a clearer name, and would delegate
to the existing attainGoal tag. I would however discourage usage of
goals as subroutines, this should be handled by some other mechanism,
such as defining custom tags and invoking them. I think it's a lot
clearer if goals are generally part of the dependency graph...
Any comments?