You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Alex F. <al...@fi...> - 2012-04-15 18:48:44
|
Hi Tim On 15 April 2012 18:11, Tim Pizey <ti...@pa...> wrote: > Hi Alex, > > On 11 April 2012 00:05, Alex Fiennes wrote: > > All, > > > > I've been doing some more thinking about the problem defined below and > I've > > got some updates to the situation... > <snip> > > If anyone can see any flaws in the above then let me know - otherwise I > will > > commit the updates and move forwards... > > > > I cannot see a flaw, but that is not saying much. > > Are you going to commit a failing test first and then a fix for that? > I haven't written a test in the webmacro framework, but I will do so. I have already written the fix and tested it manually so that is currently in use by me. As it happens, I have just thought of another reason why the fix is useful - having the Map that is generated by the parser re-used opens up threading issues because there is no guarantee that you will not get the same Map being used by multiple threads rendering the same Template in parallel which will open up nasty crashes due to parallel operations on HashMaps. I'm not going to be able to write a test for that one though... > I do not currently use any of the fancy features of WM, > only its most basic functionality, so am not a central user. > > Which repository are you committing to? (or are you still using CVS?) > I am still using my github clone that we had the brief thread about earlier. I will ensure that there is a branch at the point when I started doing work on things, I don't know whether or not people will want all changes folded back into the "official" version as I will be playing around with different things which might not be guaranteed to be backwards compatible. However, if I find things that seem to be actually broken in the code that isn't mine then I'll post something to webmacro-devel and back port things as time permits (or point other people at the appropriate commits on my branch so that they can do so) Alex > cheers > Tim > > > > > > > -- > Tim Pizey > http://pizey.net/~timp > -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Tim P. <ti...@pa...> - 2012-04-15 17:12:12
|
Hi Alex, On 11 April 2012 00:05, Alex Fiennes wrote: > All, > > I've been doing some more thinking about the problem defined below and I've > got some updates to the situation... > > On 24 November 2011 17:44, Alex Fiennes wrote: >> >> Dear all, > > > <snip> > >> >> First off, I've found a bug. Lets consider the following block of code: >> >> #templet $test { >> Original: $value <br /> >> #set $value = $value + 1 >> Incremented: $value <br /> >> } >> #eval $test using { "value": 1 } >> >> You run this in a servlet and it does what you would expect, ie: >> >> Original: 1 >> Incremented: 2 >> >> However if you reload the page shortly afterwards then you get the >> slightly surprising: >> >> Original: 2 >> Incremented: 3 >> >> which is much less what you would expect. >> >> I've been doing some initial poking around and from what I can see the >> problem is roughly along the lines of: >> >> the parser compiles the {"value": 1} into a Map and then caches this >> the EvalDirective passes this very same Map into the Context that is used >> to evaluate the $test templet >> the $test templet makes changes to it's Context which then changes the >> cached compiled version of {"value": 1} >> the next time we invoke $test, we pass in what we assume is the compiled >> version of {"value": 1}, but it actually now contains {"value": 2} >> >> If one leaves a pause between reloads and the caching engine discards the >> cached parsed templates then the value returns back to 1. >> >> Now obviously, the EvalDirective should be taking a shallow copy of the >> params before setting this as the Map that is backing the Context that is >> used to evaluate $test. >> I've mocked this up in user space so that I can invoke: >> >> #eval $test using $Vars.copyMap({ "value": 1 }) >> >> and I get the expected behaviour, ie the value doesn't increment between >> reloads. >> >> So I'm going to patch EvalDirective to sort this out which brings me onto >> my second point. > > > The problem actually isn't with EvalDirective because I think that it is > doing the right thing. I would like to be able to do something like this if > I wanted to: > > #set $params = { } > #eval $initParams1 using $params > #eval $initParams2 using $params > #eval $doWork using $params > > > and have $doWork get the populated version of $params that has been > customised by passing through the preceeding initialisation routines. > Making EvalDirective clone it's using params breaks this as the > initialisation never makes it out of the preceeding invocations. > > however, if I have a template that reads as follows: > > #set $b = { } > #if ($b.i == null) { #set $b.i = 0 } #else { #set $b.i = $b.i+1 } > Value: $b.i > > then I would expect the value of $b.i to be 0 because we initialise an empty > array and then put the value in. > however this is not the case. The parsed version of $b which is initially > an empty Map is cached along with the rest of the parsed template and > therefore the value of $b.i persists and is incremented each evaluation of > the template until the cache decides to expire it. This is definitely not > what we want to happen and therefore he cloning of the Map should occur when > we want to use the parsed version of "{ }" and therefore we will always have > a "fresh copy" of $b that reflects its state when it was declared. > > I've had a little look into MapBuilder and the code in question looks like > this: > > public Object build(BuildContext pc) > throws BuildException > { > Map<Object, Object> ret = new HashMap<Object, Object>(size()); > boolean isMacro = false; > for (Iterator<Map.Entry<Object, Object>> itr = entrySet().iterator(); > itr.hasNext();) { > Map.Entry<Object, Object> entry = itr.next(); > Object key = entry.getKey(); > Object value = entry.getValue(); > if (key instanceof Builder) > key = ((Builder) key).build(pc); > if (value instanceof Builder) > value = ((Builder) value).build(pc); > if (!isMacro) > isMacro = key instanceof Macro || value instanceof Macro; > ret.put(key, value); > } > if (isMacro) > return new MapMacro(ret); > else > return ret; > } > > What is interesting about this is that we have two different return types - > the Map itself, or the MapMacro wrapper which when evaluated creates a new > Map and populates it with the evaluated contents of the original parsed and > cached Map above. This would imply that if you Map definition is not > constant, ie contains Macros then we shouldn't be seeing the bug, and if we > extend our test case to: > > #set $var = "variable" > #set $b = { "var": $var } > #if ($b.i == null) { #set $b.i = 1 } #else { #set $b.i = $b.i+1 } > Value: $b.i > > > then we do in fact not see an incrementing $b.i because the parser is > evaluating the value of $var each time that $b is utilised and therefore the > problem goes away. > > I am therefore proposing that in cases where MapBuilder doesn't have any > Macros in then it returns a simpler wrapper like so: > > class MapClone > implements Macro > { > private final Map<Object, Object> __map; > > MapClone(Map<Object,Object> map) { > __map = map; > } > > @Override > public Object evaluate(Context context) > throws PropertyException > { > return new HashMap<Object,Object>(__map); > } > > @Override > public void write(FastWriter out, > Context context) > throws PropertyException, IOException > { > out.write(__map.toString()); > } > } > > > which just creates a clean copy of the cached Map every time it is asked for > it, and we return it as follows: > > if (isMacro) > return new MapMacro(ret); > else > return new MapClone(ret); > > > then it is no longer possible to reproduce any of the unexpected behaviour > and state is no longer preserved between re-invocations of the Template. > > If anyone can see any flaws in the above then let me know - otherwise I will > commit the updates and move forwards... > I cannot see a flaw, but that is not saying much. Are you going to commit a failing test first and then a fix for that? I do not currently use any of the fancy features of WM, only its most basic functionality, so am not a central user. Which repository are you committing to? (or are you still using CVS?) cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Alex F. <al...@fi...> - 2012-04-10 23:27:53
|
All, I've been doing some more thinking about the problem defined below and I've got some updates to the situation... On 24 November 2011 17:44, Alex Fiennes <al...@fi...> wrote: > Dear all, <snip> > First off, I've found a bug. Lets consider the following block of code: > > #templet $test { > Original: $value <br /> > #set $value = $value + 1 > Incremented: $value <br /> > } > #eval $test using { "value": 1 } > > You run this in a servlet and it does what you would expect, ie: > > Original: 1 > Incremented: 2 > > However if you reload the page shortly afterwards then you get the > slightly surprising: > > Original: 2 > Incremented: 3 > > which is much less what you would expect. > > I've been doing some initial poking around and from what I can see the > problem is roughly along the lines of: > > - the parser compiles the {"value": 1} into a Map and then caches this > - the EvalDirective passes this very same Map into the Context that is > used to evaluate the $test templet > - the $test templet makes changes to it's Context which then changes > the cached compiled version of {"value": 1} > - the next time we invoke $test, we pass in what we assume is the > compiled version of {"value": 1}, but it actually now contains {"value": 2} > > If one leaves a pause between reloads and the caching engine discards the > cached parsed templates then the value returns back to 1. > > Now obviously, the EvalDirective should be taking a shallow copy of the > params before setting this as the Map that is backing the Context that is > used to evaluate $test. > I've mocked this up in user space so that I can invoke: > > #eval $test using $Vars.copyMap({ "value": 1 }) > > and I get the expected behaviour, ie the value doesn't increment between > reloads. > > So I'm going to patch EvalDirective to sort this out which brings me onto > my second point. > The problem actually isn't with EvalDirective because I think that it is doing the right thing. I would like to be able to do something like this if I wanted to: #set $params = { } #eval $initParams1 using $params #eval $initParams2 using $params #eval $doWork using $params and have $doWork get the populated version of $params that has been customised by passing through the preceeding initialisation routines. Making EvalDirective clone it's using params breaks this as the initialisation never makes it out of the preceeding invocations. however, if I have a template that reads as follows: #set $b = { } #if ($b.i == null) { #set $b.i = 0 } #else { #set $b.i = $b.i+1 } Value: $b.i then I would expect the value of $b.i to be 0 because we initialise an empty array and then put the value in. however this is not the case. The parsed version of $b which is initially an empty Map is cached along with the rest of the parsed template and therefore the value of $b.i persists and is incremented each evaluation of the template until the cache decides to expire it. This is definitely not what we want to happen and therefore he cloning of the Map should occur when we want to use the parsed version of "{ }" and therefore we will always have a "fresh copy" of $b that reflects its state when it was declared. I've had a little look into MapBuilder and the code in question looks like this: public Object build(BuildContext pc) throws BuildException { Map<Object, Object> ret = new HashMap<Object, Object>(size()); boolean isMacro = false; for (Iterator<Map.Entry<Object, Object>> itr = entrySet().iterator(); itr.hasNext();) { Map.Entry<Object, Object> entry = itr.next(); Object key = entry.getKey(); Object value = entry.getValue(); if (key instanceof Builder) key = ((Builder) key).build(pc); if (value instanceof Builder) value = ((Builder) value).build(pc); if (!isMacro) isMacro = key instanceof Macro || value instanceof Macro; ret.put(key, value); } if (isMacro) return new MapMacro(ret); else return ret; } What is interesting about this is that we have two different return types - the Map itself, or the MapMacro wrapper which *when evaluated* creates a new Map and populates it with the evaluated contents of the original parsed and cached Map above. This would imply that if you Map definition is not constant, ie contains Macros then we shouldn't be seeing the bug, and if we extend our test case to: #set $var = "variable" #set $b = { "var": $var } #if ($b.i == null) { #set $b.i = 1 } #else { #set $b.i = $b.i+1 } Value: $b.i then we do in fact not see an incrementing $b.i because the parser is evaluating the value of $var each time that $b is utilised and therefore the problem goes away. I am therefore proposing that in cases where MapBuilder doesn't have any Macros in then it returns a simpler wrapper like so: class MapClone implements Macro { private final Map<Object, Object> __map; MapClone(Map<Object,Object> map) { __map = map; } @Override public Object evaluate(Context context) throws PropertyException { return new HashMap<Object,Object>(__map); } @Override public void write(FastWriter out, Context context) throws PropertyException, IOException { out.write(__map.toString()); } } which just creates a clean copy of the cached Map every time it is asked for it, and we return it as follows: if (isMacro) return new MapMacro(ret); else return new MapClone(ret); then it is no longer possible to reproduce any of the unexpected behaviour and state is no longer preserved between re-invocations of the Template. If anyone can see any flaws in the above then let me know - otherwise I will commit the updates and move forwards... Alex <snip> -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Alex F. <al...@fi...> - 2011-11-30 00:38:54
|
On 29 November 2011 23:15, Guy Bolton King <gu...@wa...> wrote: <snip> > Sorry, I've not been checking my mail as rigorously as normal, so I've > missed most of this thread. Picking up here (briefly) to dispel some > confusion: > > The last change made to webmacro in CVS was on 2011-05-16: > > > https://github.com/alex-fiennes/webmacro/commit/591206790c75d0f8419a4913657c49dc10b1e57c > > The change Tim made to dependencies was on 2010-02-21: > > > https://github.com/alex-fiennes/webmacro/commit/1810052e862974cf4619532390dc0fa8cb5e5768 > > Both changes are included in the github repo; I don't know what additional > changes Alex has made to the dependencies. > I've review the commit at https://github.com/alex-fiennes/webmacro/commit/79b05cdccea0dfaf4ebc0ae30e6ea60372c9d96eand I suspect that I had jumped to conclusions. A combination of missing the commit that happened post 2.1 to switch to java.util.concurrent, and then running eclipse's Tidy Imports routine when I first checked out the github repo, and then reviewing Broker and noticing that it had added java.util.concurrent.ConcurrentHashMap (and failing to notice that it had actually just re-ordered the imports) made me assume that switching across to java.util.concurrent had been done by me rather than Tim. Sorry for the confusion... > In short: the github repo includes _all_ changes from the sourceforge CVS > repo. No changes have been missed. > > If you wish to maintain a repo on sourceforge, I'd clone the github one > and push it upstream to sourceforge's git hosting, and abandon the CVS > repo: you can always take a copy of the old CVS repo from sourceforge > beforehand, or I can send it to you as I have one. > > What I would advise against is backporting into the CVS tree, as at that > point you will start to have to manually maintain two source trees in > painfully different SCMs. > utterly agree. it probably makes sense if people who care about what direction things go in review the commits that I've made to date ( https://github.com/alex-fiennes/webmacro/commits/master) and if they are all fine then we can make this into the current master branch. If any of it is problematic then I can talk to Guy about setting it up in a branch. Once this has been done, then we should have a chat about how we are going to move ahead with new development work. However I suspect that I will just make a skunkworks branch and play around with things. I would really like to get error messages to be a little bit easier to debug when you have deeply nested #eval statements... > Lastly, I apologise for appearing to have rail-roaded the move to git: in > my defense, I'd like to point out that the git repo has enabled the > experimental work that lead Alex to finding a bug, and that the git repo we > now have (which tracks the 2.2 re-org correctly) records the history of > this project with greater fidelity than CVS did. > Yup. I had fully intended to have this conversation at an earlier date, but I wasn't expecting to find anything that I though might need to go back into the public stuff and was just preparing to experiment a bit so just pressed on with things. However I think that the end result might be quite good. How many people on this list might be interested in getting into design decisions for future development on webmacro? Alex > Best regards, and good luck, > > Guy. > -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Tim P. <ti...@pa...> - 2011-11-29 23:49:32
|
On 29 November 2011 23:15, Guy Bolton King wrote: > > On 27 Nov 2011, at 21:00, Alex Fiennes wrote: > > On 27 November 2011 19:46, Tim Pizey wrote: >> >> I do not understand why you are using a copy of someone else's copy of >> webmacro? You are a committer, so should be using the trunk. > > primarily because I initially made the github copy because I wanted to > experiment with some ideas that might or might not have been sensible to > include in the public viewpoint and it was so much easier to handle branches > in git. > >> >> > This has been a gentle experiment so far because I haven't found >> > anything >> > that is actually broken yet, but come this bug then I suspect that I >> > might >> > well start using my branch for production stuff rather than just playing >> > around with ideas. >> > Who else other than me is still using webmacro and should I just >> > continue to >> > work on my github branch and move forwards? Failing that, do people >> > want me >> > to backport changes across to sourceforge? >> >> > Stuff that I have been initially working on in github is: >> > >> > removing the dependencies on the EDU.oswego.cs.dl.util.concurrent >> > packages >> >> This is done: >> >> http://webmacro.sourceforge.net/dependencies.html >> > > I wasn't aware that this had been done. In fact I wasn't aware that > anything had been done to webmacro for some time. This either means that my > mail filters are misconfigured or I am not subscribed to the appropriate > mailing lists. Has there been a release recently? > > Sorry, I've not been checking my mail as rigorously as normal, so I've > missed most of this thread. Picking up here (briefly) to dispel some > confusion: > The last change made to webmacro in CVS was on 2011-05-16: > https://github.com/alex-fiennes/webmacro/commit/591206790c75d0f8419a4913657c49dc10b1e57c > The change Tim made to dependencies was on 2010-02-21: > https://github.com/alex-fiennes/webmacro/commit/1810052e862974cf4619532390dc0fa8cb5e5768 > Both changes are included in the github repo; I don't know what additional > changes Alex has made to the dependencies. > In short: the github repo includes _all_ changes from the sourceforge CVS > repo. No changes have been missed. > If you wish to maintain a repo on sourceforge, I'd clone the github one and > push it upstream to sourceforge's git hosting, and abandon the CVS repo: you > can always take a copy of the old CVS repo from sourceforge beforehand, or I > can send it to you as I have one. > What I would advise against is backporting into the CVS tree, as at that > point you will start to have to manually maintain two source trees in > painfully different SCMs. > Lastly, I apologise for appearing to have rail-roaded the move to git: in my > defense, I'd like to point out that the git repo has enabled the > experimental work that lead Alex to finding a bug, and that the git repo we > now have (which tracks the 2.2 re-org correctly) records the history of this > project with greater fidelity than CVS did. > Best regards, and good luck, > Guy. This all seems great, and I agree (I was not aware that I had damaged history) . All that is required, I think, is to enable a git repository through the sourceforge interface, which creates an empty repository, and push Alex's repository to that and fix the POM to reflect the SCM change. I think this is great. cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Guy B. K. <gu...@wa...> - 2011-11-29 23:15:16
|
On 27 Nov 2011, at 21:00, Alex Fiennes wrote: > On 27 November 2011 19:46, Tim Pizey <ti...@pa...> wrote: > > I do not understand why you are using a copy of someone else's copy of > webmacro? You are a committer, so should be using the trunk. > > primarily because I initially made the github copy because I wanted to experiment with some ideas that might or might not have been sensible to include in the public viewpoint and it was so much easier to handle branches in git. > > > This has been a gentle experiment so far because I haven't found anything > > that is actually broken yet, but come this bug then I suspect that I might > > well start using my branch for production stuff rather than just playing > > around with ideas. > > Who else other than me is still using webmacro and should I just continue to > > work on my github branch and move forwards? Failing that, do people want me > > to backport changes across to sourceforge? > > > Stuff that I have been initially working on in github is: > > > > removing the dependencies on the EDU.oswego.cs.dl.util.concurrent packages > > This is done: > > http://webmacro.sourceforge.net/dependencies.html > > > I wasn't aware that this had been done. In fact I wasn't aware that anything had been done to webmacro for some time. This either means that my mail filters are misconfigured or I am not subscribed to the appropriate mailing lists. Has there been a release recently? Sorry, I've not been checking my mail as rigorously as normal, so I've missed most of this thread. Picking up here (briefly) to dispel some confusion: The last change made to webmacro in CVS was on 2011-05-16: https://github.com/alex-fiennes/webmacro/commit/591206790c75d0f8419a4913657c49dc10b1e57c The change Tim made to dependencies was on 2010-02-21: https://github.com/alex-fiennes/webmacro/commit/1810052e862974cf4619532390dc0fa8cb5e5768 Both changes are included in the github repo; I don't know what additional changes Alex has made to the dependencies. In short: the github repo includes _all_ changes from the sourceforge CVS repo. No changes have been missed. If you wish to maintain a repo on sourceforge, I'd clone the github one and push it upstream to sourceforge's git hosting, and abandon the CVS repo: you can always take a copy of the old CVS repo from sourceforge beforehand, or I can send it to you as I have one. What I would advise against is backporting into the CVS tree, as at that point you will start to have to manually maintain two source trees in painfully different SCMs. Lastly, I apologise for appearing to have rail-roaded the move to git: in my defense, I'd like to point out that the git repo has enabled the experimental work that lead Alex to finding a bug, and that the git repo we now have (which tracks the 2.2 re-org correctly) records the history of this project with greater fidelity than CVS did. Best regards, and good luck, Guy. |
From: Alex F. <al...@fi...> - 2011-11-29 22:57:56
|
On 29 November 2011 22:42, Guy Bolton King <gu...@wa...> wrote: > > On 29 Nov 2011, at 22:27, Tim Pizey wrote: > > <snip> > > What would matter to me is ensuring that this latest bug fix was > > included in any future release. > > Ah, I see. Is there anything in this new arrangement that would prevent > this from happening? > > The only issue is if other things that I have done since I clone Guy's repository wouldn't want to be included in any release. However, I will go through what I have done and make sure that there is nothing contentious (I wasn't necessarily working on the assumption that I was in "the public eye", more just getting re-familiar as to where things were and how they fitted together). From a quick glance against https://github.com/alex-fiennes/webmacro/commits/master I would say that things that "might" be an issue is: https://github.com/alex-fiennes/webmacro/commit/a7a41708f78b089f586311a8dc633cb133883e73- as there may be 3rd party code that is calling the deprecated methods that I've stripped out. https://github.com/alex-fiennes/webmacro/commit/70280ea1043728a8e0aed2cc06bdbc85ddd36368- primarily because it was a first draft of adding in generics information. It all compiles fine and I haven't changed any functionality, but that doesn't mean that it is "right" I'll publish the fix to EvalDirective against both my github version and against the CVS tree and we can work out where we are going to move forwards and whichever course of action we take then we can haven't closed any doors. It will only be a 2 line diff at most. There is an email on list about courses of actions if anyone has any opinions on it... Alex > Regards, > > Guy. -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Guy B. K. <gu...@wa...> - 2011-11-29 22:42:51
|
On 29 Nov 2011, at 22:27, Tim Pizey wrote: > Hi Guy, Alex, > Guy wrote: >> My 0.5p on this: use the current git repo under Alex's GitHub account. >> If you ever want/need to move to a GitHub organisation >> account (for example, the project acquires more active developers, or you feel the need to make it feel more official), then you can. > >> However, there's no need to do this now IMHO, and not doing >> it now doesn't prevent anyone else from doing it should >> they want to either. > > [snip] > >> Thanks for that Tim: I've already migrated the CVS repo to git, >> and the script (and instructions for use) can be seen >> in the webmacro repo's wiki on GitHub. > >> From https://github.com/alex-fiennes/webmacro/wiki/create-git-repo > I understand that Alex's git repository is updated with any changes to > the webmacro CVS (and that the re-organisation of the webmacro might > have caused pain - if so sorry). I did the import some time ago, and if it hurt, I don't remember, so it can't have hurt much :) Besides, reading the comments in the above file it all sounded quite educational. > What would matter to me is ensuring that this latest bug fix was > included in any future release. Ah, I see. Is there anything in this new arrangement that would prevent this from happening? Regards, Guy. |
From: Tim P. <ti...@pa...> - 2011-11-29 22:28:13
|
Hi Guy, Alex, Guy wrote: > My 0.5p on this: use the current git repo under Alex's GitHub account. > If you ever want/need to move to a GitHub organisation > account (for example, the project acquires more active developers, or you feel the need to make it feel more official), then you can. > However, there's no need to do this now IMHO, and not doing > it now doesn't prevent anyone else from doing it should > they want to either. [snip] > Thanks for that Tim: I've already migrated the CVS repo to git, >and the script (and instructions for use) can be seen > in the webmacro repo's wiki on GitHub. >From https://github.com/alex-fiennes/webmacro/wiki/create-git-repo I understand that Alex's git repository is updated with any changes to the webmacro CVS (and that the re-organisation of the webmacro might have caused pain - if so sorry). What would matter to me is ensuring that this latest bug fix was included in any future release. cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Guy B. K. <gu...@wa...> - 2011-11-29 19:22:58
|
On 29 Nov 2011, at 17:41, Tim Pizey <ti...@pa...> wrote: > On 28 November 2011 21:02, Tim Pizey wrote: >> On 27 November 2011 23:38, Alex Fiennes wrote: >>> On 27 November 2011 23:18, Tim Pizey wrote: >>>> On 27 November 2011 21:00, Alex Fiennes wrote: >>>> I know it can be done but I could not figure out how to make a project >>>> github repository - rather than a personal one, so when I moved melati >>>> I moved it to my personal hub. It would be nice to know 'the right >>>> way' to start a project repository. >>> >>> a quick look finds me http://help.github.com/manage-multiple-clients/ >>> I'll need to talk to my local git and github expert (*cough* Guy *cough*), >>> but before I do this, what would you expect from a project repository that >>> you don't get in a personal one - I'm not saying that the personal one is >>> perfect as it stands, I'm just making sure that I'm trying to solve/evaluate >>> the right problem... >> >> I really do not know, however jenkins-ci seems to have a 'project' >> repository not just Kosuke's. My 0.5p on this: use the current git repo under Alex's GitHub account. If you ever want/need to move to a GitHub organisation account (for example, the project acquires more active developers, or you feel the need to make it feel more official), then you can. However, there's no need to do this now IMHO, and not doing it now doesn't prevent anyone else from doing it should they want to either. >> If I get a chance I will look deeper into this, but am happy to be >> guided by anyone who knows. > > http://tim-pizey.blogspot.com/2011/10/cvs-to-github.html > > I have found my notes on the Melati CVS migration (not sourceforge -> github) > and also notes on sourceforge CVS to sourceforge git migration. Thanks for that Tim: I've already migrated the CVS repo to git, and the script (and instructions for use) can be seen in the webmacro repo's wiki on GitHub. Regards, Guy |
From: Tim P. <ti...@pa...> - 2011-11-29 17:41:32
|
On 28 November 2011 21:02, Tim Pizey wrote: > On 27 November 2011 23:38, Alex Fiennes wrote: >> On 27 November 2011 23:18, Tim Pizey wrote: >>> On 27 November 2011 21:00, Alex Fiennes wrote: >>> I know it can be done but I could not figure out how to make a project >>> github repository - rather than a personal one, so when I moved melati >>> I moved it to my personal hub. It would be nice to know 'the right >>> way' to start a project repository. >> >> a quick look finds me http://help.github.com/manage-multiple-clients/ >> I'll need to talk to my local git and github expert (*cough* Guy *cough*), >> but before I do this, what would you expect from a project repository that >> you don't get in a personal one - I'm not saying that the personal one is >> perfect as it stands, I'm just making sure that I'm trying to solve/evaluate >> the right problem... > > I really do not know, however jenkins-ci seems to have a 'project' > repository not just Kosuke's. > > If I get a chance I will look deeper into this, but am happy to be > guided by anyone who knows. http://tim-pizey.blogspot.com/2011/10/cvs-to-github.html I have found my notes on the Melati CVS migration (not sourceforge -> github) and also notes on sourceforge CVS to sourceforge git migration. cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Alex F. <al...@fi...> - 2011-11-29 12:45:05
|
All, moving aside from the discussion about hosting and version control of webmacro, and shifting across to the fixing of the bug (which I will fix in my github tree, and then backport across to the sourceforge tree if people want the fix), there are basically two ways to fix it: 1. Change EvalDirective so that when it invokes setMap on the Context that it has created to invoke the templet on, that it copies the Map before invoking setMap and then utilises the copy. This copy can then be mutated by the templet without effecting the original cached parsed Map. 2. Change EvalDirective so that rather than invoking context.setMap, it instead invokes context.getMap().putAll(argMap) thereby copying the contents of the cached Map into the Map inside the Context that can then be invoked. My personal preference is the second, and I would remove context.setMap which is only used for EvalDirective. My reasons for wanting to remove the method are: 1. it feels like an optimisation to avoid copying the Context in EvalDirective and as a side effect created this bug 2. it doesn't smell very nice to me. I would prefer Context to be responsible for data that can be contained within itself and letting a 3rd party drop in an unknown implementation of Map at an unknown point in the lifecycle of the Context just feels a bit wrong 3. specifically in the context of the fix to EvalDirective - it just feels wrong that we do the following: 1. Create a Context, that creates an empty Map 2. Create an external Map 3. Copy our cached Map into the external Map 4. replace the Context Map with the external Map as opposed to: 1. Create a Context, that creates an empty Map 2. copy our cached Map into the Context's Map Let me know if anyone has any strong feelings about this and I will add in a fix to my tree... Alex On 24 November 2011 17:44, Alex Fiennes <al...@fi...> wrote: > Dear all, > > I have absolutely no idea whether or not there is anybody on this list, or > if they are whether or not they are interested in things webmacro, so I > might be talking to myself, but here goes... > > First off, I've found a bug. Lets consider the following block of code: > > #templet $test { > Original: $value <br /> > #set $value = $value + 1 > Incremented: $value <br /> > } > #eval $test using { "value": 1 } > > You run this in a servlet and it does what you would expect, ie: > > Original: 1 > Incremented: 2 > > > However if you reload the page shortly afterwards then you get the > slightly surprising: > > Original: 2 > Incremented: 3 > > > which is much less what you would expect. > > I've been doing some initial poking around and from what I can see the > problem is roughly along the lines of: > > - the parser compiles the {"value": 1} into a Map and then caches this > - the EvalDirective passes this very same Map into the Context that is > used to evaluate the $test templet > - the $test templet makes changes to it's Context which then changes > the cached compiled version of {"value": 1} > - the next time we invoke $test, we pass in what we assume is the > compiled version of {"value": 1}, but it actually now contains {"value": 2} > > If one leaves a pause between reloads and the caching engine discards the > cached parsed templates then the value returns back to 1. > > Now obviously, the EvalDirective should be taking a shallow copy of the > params before setting this as the Map that is backing the Context that is > used to evaluate $test. > I've mocked this up in user space so that I can invoke: > > #eval $test using $Vars.copyMap({ "value": 1 }) > > and I get the expected behaviour, ie the value doesn't increment between > reloads. > > So I'm going to patch EvalDirective to sort this out which brings me onto > my second point. > I've been doing a bit of playing around with webmacro myself and I've got > a clone of the git repository that Guy Bolton-King took of the sourceforge > CVS repository and this is sitting at > https://github.com/alex-fiennes/webmacro > This has been a gentle experiment so far because I haven't found anything > that is actually broken yet, but come this bug then I suspect that I might > well start using my branch for production stuff rather than just playing > around with ideas. > Who else other than me is still using webmacro and should I just continue > to work on my github branch and move forwards? Failing that, do people > want me to backport changes across to sourceforge? > > Stuff that I have been initially working on in github is: > > - removing the dependencies on the EDU.oswego.cs.dl.util.concurrent > packages and using the java concurrent packages > - adding in generics declarations as required so that the package will > compile cleanly against modern java. > > What I am planning to work on is: > > - adding in support for invoking varargs methods from inside templates > - a certain amount of refactoring to use more of google guava > libraries as appropriate > - better error reporting on nested templet invocations > > If people want to let me know whether or not any of this is of interest to > anyone then we can work out how to move forwards. If I don't hear back > from anyone then I will assume that everyone has moved on to new pastures > and I will just continue down the path outlined above. > > Alex > > -- > Alex Fiennes > email: al...@fi... > mobile: +44 (0)7813 832662 > office: +44 (0)1875 823 310 > > > -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Tim P. <ti...@pa...> - 2011-11-28 21:02:44
|
Hi Alex, On 27 November 2011 23:38, Alex Fiennes wrote: > On 27 November 2011 23:18, Tim Pizey wrote: >> On 27 November 2011 21:00, Alex Fiennes wrote: >> I know it can be done but I could not figure out how to make a project >> github repository - rather than a personal one, so when I moved melati >> I moved it to my personal hub. It would be nice to know 'the right >> way' to start a project repository. > > a quick look finds me http://help.github.com/manage-multiple-clients/ > I'll need to talk to my local git and github expert (*cough* Guy *cough*), > but before I do this, what would you expect from a project repository that > you don't get in a personal one - I'm not saying that the personal one is > perfect as it stands, I'm just making sure that I'm trying to solve/evaluate > the right problem... I really do not know, however jenkins-ci seems to have a 'project' repository not just Kosuke's. If I get a chance I will look deeper into this, but am happy to be guided by anyone who knows. cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Alex F. <al...@fi...> - 2011-11-27 23:44:48
|
Tim On 27 November 2011 23:18, Tim Pizey <ti...@pa...> wrote: > On 27 November 2011 21:00, Alex Fiennes wrote: > > If we do switch to git, then will sourceforge support hosting this, or is > > github a more sensible place to put it? > > This is the question. > > My only experience of hosted git is on github. > I have not looked at sourceforge, my guess is they are trying to keep up. > > It would be churlish after 12 years to desert sourceforge, if they > have a credible offering. > I can empathise. > I know it can be done but I could not figure out how to make a project > github repository - rather than a personal one, so when I moved melati > I moved it to my personal hub. It would be nice to know 'the right > way' to start a project repository. > a quick look finds me http://help.github.com/manage-multiple-clients/ I'll need to talk to my local git and github expert (*cough* Guy *cough*), but before I do this, what would you expect from a project repository that you don't get in a personal one - I'm not saying that the personal one is perfect as it stands, I'm just making sure that I'm trying to solve/evaluate the right problem... A > > cheers > Tim > > > > > -- > Tim Pizey > http://pizey.net/~timp > -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Tim P. <ti...@pa...> - 2011-11-27 23:18:52
|
On 27 November 2011 21:00, Alex Fiennes wrote: > If we do switch to git, then will sourceforge support hosting this, or is > github a more sensible place to put it? This is the question. My only experience of hosted git is on github. I have not looked at sourceforge, my guess is they are trying to keep up. It would be churlish after 12 years to desert sourceforge, if they have a credible offering. I know it can be done but I could not figure out how to make a project github repository - rather than a personal one, so when I moved melati I moved it to my personal hub. It would be nice to know 'the right way' to start a project repository. cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Alex F. <al...@fi...> - 2011-11-27 21:00:25
|
Tim On 27 November 2011 19:46, Tim Pizey <ti...@pa...> wrote: > Hi Alex, > > Great to hear from you, not so great that you have found a bug ! > :-) it is trivial to fix... > [snip] > > > So I'm going to patch EvalDirective to sort this out which brings me > onto my > > second point. > > I've been doing a bit of playing around with webmacro myself and I've > got a > > clone of the git repository that Guy Bolton-King took of the sourceforge > CVS > > repository and this is sitting at > https://github.com/alex-fiennes/webmacro > > I do not understand why you are using a copy of someone else's copy of > webmacro? You are a committer, so should be using the trunk. primarily because I initially made the github copy because I wanted to experiment with some ideas that might or might not have been sensible to include in the public viewpoint and it was so much easier to handle branches in git. > > This has been a gentle experiment so far because I haven't found anything > > that is actually broken yet, but come this bug then I suspect that I > might > > well start using my branch for production stuff rather than just playing > > around with ideas. > > Who else other than me is still using webmacro and should I just > continue to > > work on my github branch and move forwards? Failing that, do people > want me > > to backport changes across to sourceforge? > > > Stuff that I have been initially working on in github is: > > > > removing the dependencies on the EDU.oswego.cs.dl.util.concurrent > packages > > This is done: > > http://webmacro.sourceforge.net/dependencies.html > > I wasn't aware that this had been done. In fact I wasn't aware that anything had been done to webmacro for some time. This either means that my mail filters are misconfigured or I am not subscribed to the appropriate mailing lists. Has there been a release recently? > > and using the java concurrent packages > > adding in generics declarations as required so that the package will > compile > > cleanly against modern java. > > > > What I am planning to work on is: > > > > adding in support for invoking varargs methods from inside templates > > a certain amount of refactoring to use more of google guava libraries as > > appropriate > > better error reporting on nested templet invocations > > I do not know about this, but would aim towards zero external dependencies. I am still pondering things, but I like the caching tools that are being put into guava at present and I would definitely like to look at integration of the Broker to this. > > If people want to let me know whether or not any of this is of interest > to > > anyone then we can work out how to move forwards. If I don't hear back > from > > anyone then I will assume that everyone has moved on to new pastures and > I > > will just continue down the path outlined above. > > I would like to understand why you and Guy have forked WM. > I think that Guy didn't actually fork it but rather used it as a proof of concept to transfer CVS history into git. I don't think that he still has his github copy of it floating around. Mine is primarily because I wanted to play around with some ideas that might be controversial or at least involve changes to APIs and the like. > Is it just because WM is not using Git? > > If so please, lets put the effort into getting the cvs to git > transfer done. > In which case Guy has some scripts which will facilitate this, but I'll let him answer this. > It seems that by using Guy's copy you have missed out on the work > I have done and are proposing to redo it. > I've already redone it. We can compare notes... > It is great to see someone taking an interest, but I would really like > it if this was going on within the project not outside. > Git is great and I think WM should move to it, but to be using a copy > before the trunk has been transferred seems a recipe for wasted work. > I agree. I just wasn't aware that any work was taking place on trunk. I'll speak to Guy and review the differences between head on CVS and where I am at and make a decision as to the most sensible course of action. If we do switch to git, then will sourceforge support hosting this, or is github a more sensible place to put it? Alex -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Marcello H <mar...@gm...> - 2011-11-27 20:06:59
|
I have to admit that I don't use webmacro anymore, but somehow I still feel proud I was a user of it. It's good to see that there all still some of us left. If I ever take another job as webdeveloper or something like that, I will try to use it again. (I'm now a Personal Coach, programming people's minds...) Good luck with all of this, and I will stay on the list :-) Greetings from Holland, Marcel |
From: Tim P. <ti...@pa...> - 2011-11-27 19:46:41
|
Hi Alex, Great to hear from you, not so great that you have found a bug ! [snip] > So I'm going to patch EvalDirective to sort this out which brings me onto my > second point. > I've been doing a bit of playing around with webmacro myself and I've got a > clone of the git repository that Guy Bolton-King took of the sourceforge CVS > repository and this is sitting at https://github.com/alex-fiennes/webmacro I do not understand why you are using a copy of someone else's copy of webmacro? You are a committer, so should be using the trunk. > This has been a gentle experiment so far because I haven't found anything > that is actually broken yet, but come this bug then I suspect that I might > well start using my branch for production stuff rather than just playing > around with ideas. > Who else other than me is still using webmacro and should I just continue to > work on my github branch and move forwards? Failing that, do people want me > to backport changes across to sourceforge? > Stuff that I have been initially working on in github is: > > removing the dependencies on the EDU.oswego.cs.dl.util.concurrent packages This is done: http://webmacro.sourceforge.net/dependencies.html > and using the java concurrent packages > adding in generics declarations as required so that the package will compile > cleanly against modern java. > > What I am planning to work on is: > > adding in support for invoking varargs methods from inside templates > a certain amount of refactoring to use more of google guava libraries as > appropriate > better error reporting on nested templet invocations I do not know about this, but would aim towards zero external dependencies. > If people want to let me know whether or not any of this is of interest to > anyone then we can work out how to move forwards. If I don't hear back from > anyone then I will assume that everyone has moved on to new pastures and I > will just continue down the path outlined above. I would like to understand why you and Guy have forked WM. Is it just because WM is not using Git? If so please, lets put the effort into getting the cvs to git transfer done. It seems that by using Guy's copy you have missed out on the work I have done and are proposing to redo it. It is great to see someone taking an interest, but I would really like it if this was going on within the project not outside. Git is great and I think WM should move to it, but to be using a copy before the trunk has been transferred seems a recipe for wasted work. cheers Tim -- Tim Pizey http://pizey.net/~timp |
From: Alex F. <al...@fi...> - 2011-11-24 18:40:48
|
Dear all, I have absolutely no idea whether or not there is anybody on this list, or if they are whether or not they are interested in things webmacro, so I might be talking to myself, but here goes... First off, I've found a bug. Lets consider the following block of code: #templet $test { Original: $value <br /> #set $value = $value + 1 Incremented: $value <br /> } #eval $test using { "value": 1 } You run this in a servlet and it does what you would expect, ie: Original: 1 Incremented: 2 However if you reload the page shortly afterwards then you get the slightly surprising: Original: 2 Incremented: 3 which is much less what you would expect. I've been doing some initial poking around and from what I can see the problem is roughly along the lines of: - the parser compiles the {"value": 1} into a Map and then caches this - the EvalDirective passes this very same Map into the Context that is used to evaluate the $test templet - the $test templet makes changes to it's Context which then changes the cached compiled version of {"value": 1} - the next time we invoke $test, we pass in what we assume is the compiled version of {"value": 1}, but it actually now contains {"value": 2} If one leaves a pause between reloads and the caching engine discards the cached parsed templates then the value returns back to 1. Now obviously, the EvalDirective should be taking a shallow copy of the params before setting this as the Map that is backing the Context that is used to evaluate $test. I've mocked this up in user space so that I can invoke: #eval $test using $Vars.copyMap({ "value": 1 }) and I get the expected behaviour, ie the value doesn't increment between reloads. So I'm going to patch EvalDirective to sort this out which brings me onto my second point. I've been doing a bit of playing around with webmacro myself and I've got a clone of the git repository that Guy Bolton-King took of the sourceforge CVS repository and this is sitting at https://github.com/alex-fiennes/webmacro This has been a gentle experiment so far because I haven't found anything that is actually broken yet, but come this bug then I suspect that I might well start using my branch for production stuff rather than just playing around with ideas. Who else other than me is still using webmacro and should I just continue to work on my github branch and move forwards? Failing that, do people want me to backport changes across to sourceforge? Stuff that I have been initially working on in github is: - removing the dependencies on the EDU.oswego.cs.dl.util.concurrent packages and using the java concurrent packages - adding in generics declarations as required so that the package will compile cleanly against modern java. What I am planning to work on is: - adding in support for invoking varargs methods from inside templates - a certain amount of refactoring to use more of google guava libraries as appropriate - better error reporting on nested templet invocations If people want to let me know whether or not any of this is of interest to anyone then we can work out how to move forwards. If I don't hear back from anyone then I will assume that everyone has moved on to new pastures and I will just continue down the path outlined above. Alex -- Alex Fiennes email: al...@fi... mobile: +44 (0)7813 832662 office: +44 (0)1875 823 310 |
From: Tim P. <ti...@pa...> - 2010-04-20 00:26:19
|
Sorry all, This problem does not appear to be anything to do with WebMacro. It concerns the death of a thread with an associated shutdown hook. Why this behaves 'correctly' or should I say silently fails in 2.1 I have not discovered, however by executing in a spawned JVM the shutdown hook is correctly run and the 'problem' goes away. Sorry to bother you. Tim On Monday 19 April 2010 21:37:44 Tim Pizey wrote: > Hi Guy, > > It was very nice to meet you in person at ACCU2010. > > I appear to have broken WebMacro, in that if I use the 2.2 snapshot > version I get an error but not if I back out to 2.1 > > The circumstances are: using a WebMacro in a non-servlet setup called as an application from inside Maven. > > I will try to produce a test case that does not include Melati. > > The stack trace is: > [WARNING] thread Thread[Thread-8,5,org.melati.app.TemplateApp] was interrupted but is still alive after waiting at least 15000msecs > [WARNING] thread Thread[Thread-8,5,org.melati.app.TemplateApp] will linger despite being asked to die via interruption > [WARNING] NOTE: 1 thread(s) did not finish despite being asked to via interruption. This is not a problem with exec:java, it is a problem with the running code. Although not serious, it should be remedied. > [WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.melati.app.TemplateApp,maxpri=10] > java.lang.IllegalThreadStateException > at java.lang.ThreadGroup.destroy(ThreadGroup.java:743) > at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:320) > at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > > mvn -version > Apache Maven 2.2.1 (rdebian-2) > Java version: 1.6.0_17 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.17/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-trunk-amd64" arch: "amd64" Family: "unix" > > > cheers > Tim > > -- We are in dialogue. |
From: Tim P. <ti...@pa...> - 2010-04-19 21:11:30
|
Hi Guy, It was very nice to meet you in person at ACCU2010. I appear to have broken WebMacro, in that if I use the 2.2 snapshot version I get an error but not if I back out to 2.1 The circumstances are: using a WebMacro in a non-servlet setup called as an application from inside Maven. I will try to produce a test case that does not include Melati. The stack trace is: [WARNING] thread Thread[Thread-8,5,org.melati.app.TemplateApp] was interrupted but is still alive after waiting at least 15000msecs [WARNING] thread Thread[Thread-8,5,org.melati.app.TemplateApp] will linger despite being asked to die via interruption [WARNING] NOTE: 1 thread(s) did not finish despite being asked to via interruption. This is not a problem with exec:java, it is a problem with the running code. Although not serious, it should be remedied. [WARNING] Couldn't destroy threadgroup org.codehaus.mojo.exec.ExecJavaMojo$IsolatedThreadGroup[name=org.melati.app.TemplateApp,maxpri=10] java.lang.IllegalThreadStateException at java.lang.ThreadGroup.destroy(ThreadGroup.java:743) at org.codehaus.mojo.exec.ExecJavaMojo.execute(ExecJavaMojo.java:320) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) mvn -version Apache Maven 2.2.1 (rdebian-2) Java version: 1.6.0_17 Java home: /usr/lib/jvm/java-6-sun-1.6.0.17/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux" version: "2.6.32-trunk-amd64" arch: "amd64" Family: "unix" cheers Tim -- We are in dialogue. |
From: Tim P. <ti...@pa...> - 2010-03-01 21:02:09
|
On 1 March 2010 19:26, Guy Bolton King wrote: > > On 25 Feb 2010, at 19:36, Guy Bolton King wrote: > >> >> On 21 Feb 2010, at 16:02, Tim Pizey wrote: >>> >>> The CVS tree has been reorganised >> >> Hi all: the reorganised webmacro tree didn't appear to have a tag marking the point of reorganisation. I've added a webmacro-2_2-repo-layout-change tag on 2010-02-20 23:30:07, just for the record. > > Hi Tim: earlier you made an "eek" noise when CVS branches were suggested. A short stint of merging some feature branches back to HEAD last week reminded me of the general flakiness of doing this (even with tool support). However, we still have it in mind to do some experimentation, and while that isn't a promise/threat we don't want to mess up the single CVS branch at sourceforge with possibly disruptive changes. > > Given this, I've updated the webmacro repo at github (http://github.com/guyboltonking/webmacro) such that it now tracks the sourceforge CVS on its CVS-2.2/master branch. This repo contains all the history from CVS, and also tracks the moves from the reorganisation done at the end CVS-2.1. It doesn't show any merges from the early branches: this is because detecting these would have been too much trouble. > > If we get around to making any changes, we'll make them on the master branch (or feature branches) in that repo, and we'll offer them back to the main CVS repo. If approved for inclusion, we can (hopefully easily) commit them to CVS using git's cvsexportcommit command. Guy, This sounds great. I may find time for two little maven plugins: A general WebMacro interpolation plugin and an escape to velocity plugin. I also hope to revisit the javacc Maven plugin. cheers Tim |
From: Guy B. K. <gu...@wa...> - 2010-03-01 19:26:44
|
On 25 Feb 2010, at 19:36, Guy Bolton King wrote: > > On 21 Feb 2010, at 16:02, Tim Pizey wrote: >> >> The CVS tree has been reorganised > > Hi all: the reorganised webmacro tree didn't appear to have a tag marking the point of reorganisation. I've added a webmacro-2_2-repo-layout-change tag on 2010-02-20 23:30:07, just for the record. Hi Tim: earlier you made an "eek" noise when CVS branches were suggested. A short stint of merging some feature branches back to HEAD last week reminded me of the general flakiness of doing this (even with tool support). However, we still have it in mind to do some experimentation, and while that isn't a promise/threat we don't want to mess up the single CVS branch at sourceforge with possibly disruptive changes. Given this, I've updated the webmacro repo at github (http://github.com/guyboltonking/webmacro) such that it now tracks the sourceforge CVS on its CVS-2.2/master branch. This repo contains all the history from CVS, and also tracks the moves from the reorganisation done at the end CVS-2.1. It doesn't show any merges from the early branches: this is because detecting these would have been too much trouble. If we get around to making any changes, we'll make them on the master branch (or feature branches) in that repo, and we'll offer them back to the main CVS repo. If approved for inclusion, we can (hopefully easily) commit them to CVS using git's cvsexportcommit command. Regards, Guy. |
From: Guy B. K. <gu...@wa...> - 2010-03-01 19:09:46
|
On 26 Feb 2010, at 19:35, Tim Pizey wrote: > On 26 February 2010 12:49, Guy Bolton King wrote: >> >> On 25 Feb 2010, at 21:13, Tim Pizey wrote: >> >>> Thanks Guy. >>> >>> Does that mean that the latest build works for you? >> >> $ mvn install >> >> ...passes all unit tests and sticks a jar in targets/. I'm no maven expert, but my ~/.m2/settings.xml is empty, so that should mean I have a fairly vanilla maven setup, yes? I haven't tested the jar against any of our current projects yet. > > > Cool, yes that does mean that. > The ant build also works. Confirmed. > Are your other projects Maven or ant.? Ant + Ivy. Cheers, Guy |
From: Tim P. <ti...@pa...> - 2010-02-26 19:36:01
|
On 26 February 2010 12:49, Guy Bolton King wrote: > > On 25 Feb 2010, at 21:13, Tim Pizey wrote: > >> Thanks Guy. >> >> Does that mean that the latest build works for you? > > $ mvn install > > ...passes all unit tests and sticks a jar in targets/. I'm no maven expert, but my ~/.m2/settings.xml is empty, so that should mean I have a fairly vanilla maven setup, yes? I haven't tested the jar against any of our current projects yet. Cool, yes that does mean that. The ant build also works. Are your other projects Maven or ant.? cheers Tim |