Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]
On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma wrote: > I've move this into a separate [DISCUSS] thread as I think it needs separate > discussion. > > Jörg gave some objections below about using Milestone releases, as I > proposed earlier to support releasing intermediate versions of a > not-yet-stabalized component. > > While I understand his problems with unstable versions potentially getting > 'stuck' for long time, where end-users *might* start expecting them to > remain stable, I don't agree this is, or should be, the common case. Or at > least not an argument to hold against using such 0.x or -Milestone releases. > > Instead, the whole point is to get project/component development moving > *faster* by allowing *experimental* end-users to provide feedback, and more > flexibility and convenience for the developers of such project/component. > > The idea to have to 'switch' to a next major version for any incompatibile > change, as Jörg proposes, requiring package changes, whatnot, while a > project clearly is not ready to stabalize, really puts way too much hurdles > up for both the developers *and* such experimental end-users, as they would > HAVE to change all of their code to be able to provide AND leaverage such > new 0.x or Milestone version. > > Case in point: SCXML > If we are allowed to start working on this component shortly, we intend to, > and HAVE to switch to a 1.0 version first, as there already is a 0.9 version > release out, while we will need to move to newer JDK and incompatible API > changes anyway. At the same time, getting a final/stabalized 1.0 release out > most certainly will take several iterations. Release version comparisons being what the are, we could go to v0.10, as in below (greater than sign implies more recent release version): 0.11 > 0.10 > 0.9 Not very different than, say the following, which may appear more intuitive for release versions (agree 0.x line is trickier): 2.11 > 2.10 > 2.9 Overall, I think it's OK to go the 0.10 route, if you want to save a 1.0 major release for later at a point it's really needed. In hindsight, the first Commons SCXML release could've been 0.1 (rather than 0.5) to give more room for 4 more releases before getting to this point :-) -Rahul > I don't want to have to wait doing an intermediate release, nor rapidly > having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone > releases are acceptable for this purpose. Where would Milestone releases [1] > be useful for otherwise, anyway? > > I think a real problem might arise IF other components (or 3rd party > libraries) would start depending directly on such Milestone releases, > potentially introducing unexpected instabilities for end-users. And maybe it > is worthwhile to make such usages, at least for Commons, prohibited. That > would make sense to me. > > But for components like SCXML, javaflow, or csv, this I don't think would be > a real issue. Those end-users making use of these experimental components > are, or should be very well aware, of the added responsibility they take > depending on a not-yet-stabilized version, as clearly is also indicated by > the version, as well as SHOULD be prominently documented in the release > notes, readme, etc. > > Thoughts? > > Ate > > On 10/10/2013 12:45 PM, Benedikt Ritter wrote: >> >> I like the idea of releasing 0.x versions. A good example is [csv]. I >> would have no problem with releasing the current trunk as 0.9. At the moment >> [csv] is just another component we don't releaese because we want to come up >> with a perfect API (and I take responsibility for that :-) >> >> Benedikt >> >> Send from my mobile device >> >>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible >>> : >>> >>> Hi, >>> >>> Ate Douma wrote: >>> > On 10/10/2013 12:24 AM, Torsten Curdt wrote: > Every now and then I keep getting requests via private mail asking to > release javaflow as it seems to be working for people. Yet I know there > is still so much essential stuff to fix for a 1.0 release. > > Crossing over to the other thread: I know on github I would made a 0.x > release already ages ago but knowing I won't have time to work on it > anymore I keep pushing this out at commons. Wouldn't this be a case to allow and use intermediate milestone releases? Using a 1.0-Mxx version would make still clear to the users things haven't settled yet (API wise), so should not limit or restrict making API changes before a final 1.0 release, but would help both the community and the project moving. More likely to incite further involvement and contributions, etc. Being 'stuck' on getting a (final) 1.0 release out because everything should be settled and 'frozen' (API wise) first doesn't make sense to me at all. >>> >>> >>> We should not be so afraid to switch to 2.x if the 1.x API turns out to >>> be >>> cumbersome in some cases. Typically you may also incre
Re: [SCXML] knock knock?
On Tue, Oct 8, 2013 at 9:39 AM, Woonsan Ko wrote: > Yeah, that's great! > State machine is a generic and simplistic concept which can be applied > anywhere. > In our case (Hippo), we want to leverage SCXML library as a core Document > Processing Engine. By exposing state machines in XML with ability to add > custom actions and other declarative configurations, we believe it can > increase customizability and flexibility in our product a lot. > I worked at a BPM company for several years in the past, so I'm very familiar > with process/workflow management as well, in both state machine based > approach or activity-flow based approach. State machine based approach should > fit better in our internal core document processing, I think. > > > I really hope to get involved in Commons-SCXML together. I've also worked for > Apache Portals project as committer (and PMC member) for several years and > release manager for Apache Portals Applications, too. I have been enjoyed > helping users/developers in the mailing lists and contributing to other ASF > projects (e.g, commons-lang, log4j2, camel, cxf, etc.). I do respect the > community and the Apache Way. > In any way, I'm really looking forward to helping it. > Cool, glad you're on board then. Thanks for the background above :-) -Rahul > Cheers, > > Woonsan > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
On Tue, Oct 8, 2013 at 9:25 AM, Ate Douma wrote: > On 10/08/2013 02:18 PM, Rahul Akolkar wrote: >> >> Who's there :-) >> >> Agree with all your Commons SCXML related comments below.I've been >> >> out of time for this for a while; you're welcome to have at it. Being >> ASF committers helps as discussed down-thread. I'll continue to lurk, >> but likely won't be active in the immediate future. >> >> Welcome to Commons, >> -Rahul >> > Thanks for the welcome Rahul. > > Its great to hear you agree to the proposal, and welcoming us to go ahead. > Too bad you won't be able to participate directly, but we'll make sure to > properly discuss and propose important changes first, so you still be able > to chime in any time you feel like it. > > And knowing you'll still be lurking is cool: we'll assume no feedback as a > good sign then :) > Yup, good plan! -Rahul > Thanks and regards, Ate > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] knock knock?
Who's there :-) Agree with all your Commons SCXML related comments below. I've been out of time for this for a while; you're welcome to have at it. Being ASF committers helps as discussed down-thread. I'll continue to lurk, but likely won't be active in the immediate future. Welcome to Commons, -Rahul On Mon, Oct 7, 2013 at 10:40 AM, Ate Douma wrote: > Hi SCXML developers/community, > > We are trying to figure out what the status and activity of SCXML > development is, and and/or who in the community might be interested in > re-activating it. > > From the mailing lists and JIRA activity we gather not much has been > happening here for a very long time: the last release 0.9 dates back to > December 2008 and the last serious code commits to June 2011... > > Looking back through the history of SCXML, Rahul Akolkar was and pretty much > still is the only maintainer of the code but seemingly no longer able or > willing to contribute much anymore. > > So, what to do with Commons SCXML? > > To put it bluntly, we would very much like to revive the development of > SCXML again. > > We are working for Hippo (Open Source CMS vendor) and intend to start using > SCXML as state machine engine in our product shortly. > > As the latest release is so old, and based on only Java 1.4, we're looking > into using the Java 6 (J6) branch instead. But this branch is still 'work in > progress' without any release (but targeted at next major version 1.0). > > This J6/1.0 branch AFAIK is intended to cover the final SCXML specification > [1], but already running quite a bit behind the latest draft of that > specification. However, this being a W3C specification, having to wait for > it to become final before releasing a next major version of Commons SCXML > seems very counter-productive to me... > > Both myself and Woonsan are Apache committers on several other ASF projects > for quite some time, so we know 'how it works'. We would like to get out > hands dirty, start contributing on Commons SCXML, and help move it forward > towards a more current release. > > But the question is: is there still anyone out here willing to pick up and > review contributions, discuss stuff, etc. > > Hopefully Rahul can chime in (if still listening) and let us know what his > ideas and plans are, or else maybe other active members of the Commons > community? > > As a minimum we would like to get a Java 6+ compatible version released > soon, maybe as a first milestone release towards 1.0, and incrementally add > (more) compliance to the current SCXML specification. > > For this we propose to 'archive' the current stalled trunk (move it to a > 0.xx branch or something), promote the current J6 branch to trunk, and then > take it from there. Website and documentation fixes would be next to pick up > and straighten out and updating the current Maven build. Possibly drop the > outdated Ant build as well if nobody really is using or dependening on it > anyway. > > As said, we're willing to step up here, but as non committers for Apache > Commons we do need a 'handle' to get stuff moving again. > > Thanks, Ate & Woonsan > > [1] http://www.w3.org/TR/scxml/ > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Deployment of component builds to Maven repo
On Thu, Aug 16, 2012 at 7:23 PM, sebb wrote: > For components which use a Maven groupId starting with > "org.apache.commons.", Maven deployment is already enabled via Nexus. > > There are a few components which still use a Maven groupId of the form > "commons-". > Some of these are already enabled in Nexus. > > Nexus infra have stated that it is just as much work to enable one > component as enabling lots, so I said I would ask Commons which > components still need to be enabled. > > So hopefully we can put together a list of components that need to be > enabled in Nexus and ask for these all to be done at once. > > The following are not (yet) in Nexus > > commons-beanutils > commons-betwixt > commons-collections > commons-discovery > commons-el > commons-jxpath > commons-launcher > commons-logging > commons-modeler > commons-primitives > commons-scxml > > Are any of the above definitely NOT going to make another release > using the same groupId? > This could be because: > - the component is dormant, or > - future releases will use a groupId of o.a.c (and change package name!). > Hard to say about commons-scxml, so suggest keeping in the list for Nexus infra. -Rahul > The following are now using o.a.c for trunk releases: > > commons-digester (2.x) > commons-lang (2.x) > commons-dbcp (1.x) > > It seems very unlikely that another digester 2.x release will ever be > needed, and probably not LANG 2.x, but what about DBCP? > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] why in all test case there is instead of
On Thu, May 31, 2012 at 4:58 PM, Alessandro Scarozza wrote: > the question is simple: > > in w3c standard the final state is: > > but in all test case there is: > > > it also seems that by the final attribute does not work, while using > the tag final works fine > > long story short: > commons scxml are according to W3C > test case are wrong > > Is that so? > In the earliest drafts of the SCXML specification, the syntax with the final attribute was used, those test cases that use the syntax were written then and use the older version of the Commons SCXML parser. The new parser may not recognize the old syntax. -Rahul > -- > Alessandro Scarozza > http://www.google.com/profiles/xan.scale > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] Anybody active?
On Thu, May 31, 2012 at 3:15 AM, Kukosa, Tomas wrote: > > What are rules for the trunk and the J6 branch? > > May I develop against the J6 branch or should it contain just differences for > Java 1.6 and all development should be against the trunk? > J6 is the 1.x development line (unreleased, first release from the line would be 1.0). trunk is the 0.x line, is on JDK 1.4. In theory, the trunk should be a proper subset of the J6 functionality. I'd add to J6 and backport any bugs/essential changes to trunk. -Rahul > Tomas > > -----Original Message- > From: Rahul Akolkar > Sent: Thursday, May 17, 2012 3:32 PM > To: Commons Developers List > Subject: Re: [scxml] Anybody active? > > On Thu, May 17, 2012 at 4:27 AM, Kukosa, Tomas > wrote: >> Hi Rahul, >> >> thanks for your offer. >> >> When I get more familiar with current commons-scxml and have some reasonable >> patches I will send them. >> >> After short time playing with it, I can see following topics: >> - update to the latest SCXML W3C draft >> (http://www.w3.org/TR/2012/WD-scxml-20120216/ for now) >> - switch to commons-digester3 >> - update Java requirement to 1.5 and use generics instead of raw types where >> possible >> >> What do you think? >> > > > Yup, reasonable list. We do have a J6 branch (for 1.6, note it's > unreleased code): > > http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/ > > -Rahul > > >> Best regards, >> Tomas >> >> PS: sorry for not following mail thread but I sent/received previous >> messages just via web >> >> >> On Wed, May 16, 2012 at 10:01 AM, Kukosa, Tomas >> wrote: >>> Hi, >>> >>> is anbody working on commons-scxml? >>> >> >> >> No. If you (or anyone else) would like to work on it, I can help with >> reviewing and applying patches etc. >> >> -Rahul >> >> >>> Tomas >>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] Anybody active?
On Thu, May 17, 2012 at 4:27 AM, Kukosa, Tomas wrote: > Hi Rahul, > > thanks for your offer. > > When I get more familiar with current commons-scxml and have some reasonable > patches I will send them. > > After short time playing with it, I can see following topics: > - update to the latest SCXML W3C draft > (http://www.w3.org/TR/2012/WD-scxml-20120216/ for now) > - switch to commons-digester3 > - update Java requirement to 1.5 and use generics instead of raw types where > possible > > What do you think? > Yup, reasonable list. We do have a J6 branch (for 1.6, note it's unreleased code): http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/ -Rahul > Best regards, > Tomas > > PS: sorry for not following mail thread but I sent/received previous messages > just via web > > > On Wed, May 16, 2012 at 10:01 AM, Kukosa, Tomas > wrote: >> Hi, >> >> is anbody working on commons-scxml? >> > > > No. If you (or anyone else) would like to work on it, I can help with > reviewing and applying patches etc. > > -Rahul > > >> Tomas >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] Anybody active?
On Wed, May 16, 2012 at 10:01 AM, Kukosa, Tomas wrote: > Hi, > > is anbody working on commons-scxml? > No. If you (or anyone else) would like to work on it, I can help with reviewing and applying patches etc. -Rahul > Tomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Eclipse SCXML Editor status?
On Thu, Apr 12, 2012 at 2:12 PM, Eric Rosevear wrote: > Hello, > > I've tried out the eclipse scxml editor and have a question. The project > apparently dates back to 2010. > That is correct, the above was a GSoC project that summer. > Is this project still active? What is the status of the project? > The project is not active. You may of course look at the source directly in SVN and try to build and use it, but note that the code is unreleased. -Rahul > Thanks, > > Eric - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: help for scxml conformance update
On Mon, Jan 16, 2012 at 11:09 AM, Jacob Beard wrote: > Hi Ingo, > > On Mon, Jan 16, 2012 at 10:53 AM, Ingo Lütkebohle > wrote: >> Hi, >> >> Am Mon 16 Jan 2012 04:10:40 PM CET schrieb Rahul Akolkar: >> >>> Sounds reasonable. There hasn't been any time put into bringing the >>> code upto conformance in over a year. If you're keen to work on some >>> issues over others, I suggest you simply make a note of that by >>> commenting on the appropriate ticket in JIRA (and creating a new one >>> if such doesn't exist) and when you feel you have a fix / solution, >>> please attach a patch with appropriate test cases to the JIRA >>> issue(s). >> >> >> Okay. >> >> One question: I was going to start on implementing the "content" child of >> invoke statements and noticed that SCXML-146 has the title , without >> further comments though. There are a couple tickets like that, most >> associated with Jacob Beard. Has that work stopped? > > That work was related to my Google Summer of Code 2010 project, > scxml-js. Those tickets were children of the following task: > https://issues.apache.org/jira/browse/SCXML-120 > This work has now stopped, and these tasks should probably be closed > as "won't fix". I can go ahead and clean this up. > Jake - Yup, such cleanup would be useful, thanks. >> >> Also, are you aware of a specific change-log between the last draft and the >> current draft? I noticed a couple of things that are missing/different, but >> a changelog would make it much easier to check everything. > Ingo - Right, we could do better in this area. We have SVN history, release notes and this old changelog [1], but a draft-by-draft status / comparison would be nice indeed. Something to start documenting going forward if there is interest. -Rahul [1] http://commons.apache.org/scxml/changes-report.html > Note that the last time I looked at the Algorithm for SCXML > Intepreteration, it had a serious bug: > http://lists.w3.org/Archives/Public/www-voice/2011JanMar/0043.html > It appears they have changed the algorithm since then to support > internal transitions and late binding data, so perhaps this bug has > been fixed in later revisions as well. > > Jake > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: help for scxml conformance update
On Mon, Jan 16, 2012 at 10:00 AM, Ingo Lütkebohle wrote: > Hi All, > > I'd be interested in getting a version of commons scxml which supports the > latest SCXML standard and would be willing to contribute code to that > effect, work on open tickets, etc.. > Cool :-) > If you're interested in that, please let me know how I could help best. > > FWIW, I've looked over the SCXML tickets marked "major" in JIRA and there > are both feature requests (some of which appear to be quite substantial but > not particularly essential with respect to standard conformance), and > requests for conformance updates. I'd be happy work on the latter, but not > so keen on the former. Maybe we could prioritize, to see what would be > essential for 0.10, and postpone the others for a later release? > Sounds reasonable. There hasn't been any time put into bringing the code upto conformance in over a year. If you're keen to work on some issues over others, I suggest you simply make a note of that by commenting on the appropriate ticket in JIRA (and creating a new one if such doesn't exist) and when you feel you have a fix / solution, please attach a patch with appropriate test cases to the JIRA issue(s). Couple of comments for easier review of patches: * Patches containing small incremental changes are usually better than large refactorings as they are easier to validate * Patches shouldn't mix functional changes with changes to code style Cheers, -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Long standing update: Switched to JDK 5 and Maven 2
On Wed, Jul 27, 2011 at 3:54 PM, Rahul Akolkar wrote: > On Wed, Jul 27, 2011 at 2:25 PM, Thomas Vandahl wrote: >> Hi folks, >> >> I finished the updates to JDK 5 generics and concurrent and updated the >> maven-2 build. Still some tests fail, others should never have passed. I >> would like to ask for close review because I basically touched >> everything. I tried to fix some obvious problems and typos on the way. >> > > Separately, would you be able to publish the JCS site here: > > http://commons.apache.org/jcs > > Above 404s from Commons homepage link. > I cp -R'ed the site over, but it should be republished more gracefully. > Once its posted, I can redirect from the Jakarta site to the Commons > counterpart (for BCEL as well). > Redirects now in place. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Long standing update: Switched to JDK 5 and Maven 2
On Wed, Jul 27, 2011 at 2:25 PM, Thomas Vandahl wrote: > Hi folks, > > I finished the updates to JDK 5 generics and concurrent and updated the > maven-2 build. Still some tests fail, others should never have passed. I > would like to ask for close review because I basically touched > everything. I tried to fix some obvious problems and typos on the way. > Separately, would you be able to publish the JCS site here: http://commons.apache.org/jcs Above 404s from Commons homepage link. Once its posted, I can redirect from the Jakarta site to the Commons counterpart (for BCEL as well). > My impression was that a lot of things could be simplified although I > have been wrong on such judgements before... > > For example, I'd suggest to remove the tempbuilds and rather create more > releases. > Indeed, one of the good things about the Commons move is things like tempbuilds won't be able to survive here :-) -Rahul > Your comments are welcome. > > Bye, Thomas > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Migrating over from Jakarta?
On Sat, Jul 23, 2011 at 2:17 AM, Henri Yandell wrote: > On Fri, Jul 22, 2011 at 10:10 AM, Thomas Vandahl wrote: >> On 22.07.11 11:33, Henri Yandell wrote: >>> Anyone adverse to me svn moving JCS over from Jakarta? It will mean >>> someone needing to update the site (which they should do while moving >>> that over). >> >> I'd be willing to help, just need some directions. >> >> I did some larger modifications to the code base recently, namely the >> switch to JDK 1.5 concurrent and generics which I wanted to commit >> before the move. However this is not ready yet as some tests don't pass. > > Basically changing the site from saying /jakarta/jcs to saying > /commons/proper/jcs wherever it makes svn url statements. > > If you want to get the code committed, it makes life fractionally > easier for you rather than figuring out how to svn switch over. I'm > happy to wait on your nod before doing the svn move. > I'd say go ahead now, nothing here to wait for :-) -Rahul > Hen > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JCS] Migrating over from Jakarta?
On Fri, Jul 22, 2011 at 5:33 AM, Henri Yandell wrote: > Anyone adverse to me svn moving JCS over from Jakarta? Not at all, thanks for both the svn moves Hen! -Rahul > It will mean > someone needing to update the site (which they should do while moving > that over). > > Hen > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[RESULT][VOTE] Accept BCEL and JCS as Commons components
Votes to accept BCEL (1 and 1a) pass with 12 +1 votes and 1 -1 vote:
+1: luc, oheger, simonetripodi, sebb, ggregory, grobmeier, rgoers,
mbenson, bayard, joehni, bodewig, psteitz
-1: jochen (concern about activity, sufficiently addressed IMO)
Votes to accept JCS (2, 2a, 2b and 2c) pass with 13 +1 votes from:
luc, oheger, simonetripodi, sebb, ggregory, grobmeier, rgoers,
mbenson, bayard, joehni, jochen, bodewig, psteitz
Thanks to everyone who voted.
Next steps:
* psteitz: commons += {dbrosius, asmuts, tv, seade} please.
* once above folks have karma, will move the repos and sites (w/
redirects from j.a.o).
-Rahul
On Sun, Jun 26, 2011 at 12:48 AM, Rahul Akolkar wrote:
> This is half a dozen related votes in one thread (for convenience), namely:
>
> 1. Accept BCEL [1] as Commons component
> 1a. Grant Commons karma to Dave Brosius (dbrosius)
>
> 2. Accept JCS [2] as Commons component
> 2a. Grant Commons karma to Aaron Smuts (asmuts)
> 2b. Grant Commons karma to Thomas Vandahl (tv)
> 2c. Grant Commons karma to Scott Eade (seade)
>
> -
> [ ] +1 to all above
> [ ] +/- 0
> [ ] -1, which ones and why ...
> --
>
> You may ofcourse vote on each separately if necessary.
>
> Vote will minimally stay open for 72 hours. Thanks.
>
> -Rahul
>
> [1] http://jakarta.apache.org/bcel/
> [2] http://jakarta.apache.org/jcs/
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Accept BCEL and JCS as Commons components
On Mon, Jun 27, 2011 at 3:50 AM, Jochen Wiedmann wrote: > On Sun, Jun 26, 2011 at 6:48 AM, Rahul Akolkar > wrote: >> This is half a dozen related votes in one thread (for convenience), namely: >> >> 1. Accept BCEL [1] as Commons component >> 1a. Grant Commons karma to Dave Brosius (dbrosius) > > -1 BCEL hasn't shown any meaningful signs of activity since ages > and even Thorsten Curdt has opined that it should be sent to the > attic. > I understand the concern (though s/Thorsten/Torsten/). I think if BCEL is to survive, Commons is a great place with potential for new blood. As others have said, if it doesn't, we can mothball it from Commons. -Rahul > >> 2. Accept JCS [2] as Commons component >> 2a. Grant Commons karma to Aaron Smuts (asmuts) >> 2b. Grant Commons karma to Thomas Vandahl (tv) >> 2c. Grant Commons karma to Scott Eade (seade) > > +1 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Accept BCEL and JCS as Commons components
This is half a dozen related votes in one thread (for convenience), namely: 1. Accept BCEL [1] as Commons component 1a. Grant Commons karma to Dave Brosius (dbrosius) 2. Accept JCS [2] as Commons component 2a. Grant Commons karma to Aaron Smuts (asmuts) 2b. Grant Commons karma to Thomas Vandahl (tv) 2c. Grant Commons karma to Scott Eade (seade) - [ ] +1 to all above [ ] +/- 0 [ ] -1, which ones and why ... -- You may ofcourse vote on each separately if necessary. Vote will minimally stay open for 72 hours. Thanks. -Rahul [1] http://jakarta.apache.org/bcel/ [2] http://jakarta.apache.org/jcs/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Wiki spam prevention measure
On Wed, Jun 22, 2011 at 8:51 AM, sebb wrote: > Gavin recently updated the details of how the ASF Wiki works, and > added details of how SpamAssassin have completely stopped spam > happening: > > http://wiki.apache.org/general/OurWikiFarm#per_wiki_access_control_-_tighten_your_wiki_just_a_little.2C_benefit_just_a_lot > > Might be worth considering for Commons? > > The ContributorsGroup could be pre-populated with recent 'ham' contributors. > > The Commons Wiki is not very active, and most edits are by existing > developers, so it's unlikely that the ContributorsGroup will need to > be updated often. > > On the other hand, spam does not seem to be a big problem on the > Commons Wiki - it's much worse on the general and Tomcat Wikis. > > One advantage of changing the permission scheme is that AIUI it would > allow attachments to be re-enabled. > If the above route is taken, I'd be glad to help by being in the AdminGroup for the Commons wiki. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] BCEL and JCS as Commons components?
On Sun, Jun 19, 2011 at 12:47 PM, Thomas Vandahl wrote: > On 18.06.11 18:45, Rahul Akolkar wrote: >> On Fri, Jun 17, 2011 at 4:09 AM, Henri Yandell wrote: >>> Just code on its own = -1. As long as committers are coming, +1. >>> >> >> >> Proposal is to give existing committers karma (some have it). In >> addition, there seems some new folks interested (amongst Commons >> committers). > > Would that mean that commit karma will be transferred from Jakarta to > Commons if, for example, JCS moves? > I'd propose bringing atleast the following folks with the code: BCEL: dbrosius (tcurdt already has Commons karma) JCS: asmuts, tv The Commons PMC would have to approve ofcourse. Further, if anyone else who has previously contributed shows up interested, I'd be willing to nominate them as well. -Rahul > Bye, Thomas. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [digester] fixing old broken links
On Fri, Jun 17, 2011 at 6:31 PM, Simone Tripodi wrote: > Thanks a lot for the suggestions Phil, very appreciated!!! > I honestly thought that there was some Maven trick somewhere that I > wasn't aware of :P > So, I think I'll proceed following the first approach, I see it > quicker and easier :) Along these lines: * Check out release sources from SVN tags (or grab source distros) for all prior versions you want sites deployed for * For $version in versions, change site URL in pom to be c.a.o/$component/$version (instead of c.a.o/$component) and deploy (or you could manually upload) * Check out trunk, update site.xml or equivalent (see bottom of [scxml] site.xml [1] for example of menu with other versions) and deploy -Rahul [1] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/site/site.xml > Online soon, stay tuned! :D > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Jun 17, 2011 at 11:59 PM, Phil Steitz wrote: >> On 6/17/11 12:24 PM, Simone Tripodi wrote: >>> Hi all guys, >>> because of my fault, we've been notified more than once - and there's >>> an open Issue[1] - about bad links on Digester site :( >>> Since SNAPSHOT artifacts have already been successfully deployed on >>> Nexus, I would like to publish also the new Digester snapshot site >>> with updated documentation, so users can start to play with the new >>> component version - but I now have the need to fix those links >>> otherwise the 2.X version would lose the doc, and that would be really >>> annoying. >>> Does someone know how we published that documentation in the past >>> (before I join, I mean), so I can apply the fix? >> >> As with all things Commons, a little comparative shopping always >> works best ;) >> >> Have a look at the [beanutils] site, which maintains docs for two >> versions simultaneously, or [math] or [dbcp], which like most other >> commons sites maintains prior version javadocs on the site. What we >> usually do for the javadoc is just manually push the files to p.a.o >> and link them. Same could work for user guide type material. Just >> create an "old" version, tar it, scp it to p.a.o, unpack somewhere >> and adjust links. Alternatively, you can spend n hours trying to >> figure out how to cajole maven into creating a site that includes >> all of the content. I strongly recommend the first route. Maybe >> Niall can chime in with comments on how he did the [beanutils] stuff. >> >> Phil >>> Many thanks in advance, any help would be really appreciated! >>> All the best, >>> Simo >>> >>> [1] https://issues.apache.org/jira/browse/DIGESTER-147 >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] BCEL and JCS as Commons components?
On Fri, Jun 17, 2011 at 4:09 AM, Henri Yandell wrote: > On Thu, Jun 16, 2011 at 8:29 AM, Phil Steitz wrote: >> On 6/16/11 8:22 AM, Matt Benson wrote: >>> (accidentally sent to Jochen personally before, sorry) >>> >>> On Thu, Jun 16, 2011 at 10:19 AM, Jochen Wiedmann >>> wrote: On Thu, Jun 16, 2011 at 5:03 PM, Matt Benson wrote: > Considering [1], I'd say it's more relevant now than, arguably, ever. Are you sure, that's related? Reading [2], my understanding is that JCS doesn't aim to implement JSR-107, but to be "close to". >>> My point was that if we have a good cache library @ Commons, I would >>> assume we could build on that to implement the JSR (if the TCK is >>> licensed such that we can actually use it, no guarantee there) if we >>> want to. Perhaps an incorrect assumption, but I have a difficult time >>> with the concept of "can't be done." >> >> +1 - whoever picks this thing up can do whatever they want with it. >> I suspect all of the "I" references in [2] are obsolete :) Looks >> like we have several people interested in working on it, so I see no >> reason not to let them do it here. > > +1. > > Just code on its own = -1. As long as committers are coming, +1. > Proposal is to give existing committers karma (some have it). In addition, there seems some new folks interested (amongst Commons committers). > From a bigger picture point of view - I want Jakarta to go to the > Attic. These components, as with many in Commons, have kept themselves > just about alive and keep Jakarta out of the Attic. Moving them over > to Commons is no real change to themselves, no real impact to Commons > in the worst case and a big step towards closing down Jakarta. > Indeed. > Then Rahul just has to convince BSF, Cactus and JMeter that they'd be > just the same as quiet TLPs :) > Yup, BSF and Cactus come next (JMeter is in fair shape). But, one step at a time, slow and steady :-) -Rahul > Hen > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ALL] BCEL and JCS as Commons components?
As Jakarta winds down, we are looking for sustainable homes for couple of Java libraries -- BCEL [1] and JCS [2]. These aren't very different from many Commons libraries in size, number of developers, list traffic etc. Would Commons be interested in accepting these? Couple of the developers already have Commons karma, we will request karma for a couple more if the move happens. Background threads in Jakarta land here [3, 4]. -Rahul [1] http://jakarta.apache.org/bcel/ [2] http://jakarta.apache.org/jcs/ [3] http://markmail.org/thread/vtgzc5pqsjol4cft [4] http://markmail.org/thread/uacopjsbw7xkw4q7 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dormant][commons-graph] or [graph2] What must be the subject line?
On Fri, Jun 10, 2011 at 9:13 AM, Arshad Ansari wrote: > Hello, > The project commons-graph is being listed under dormant (here > https://svn.apache.org/repos/asf/commons/dormant/) as graph2. So, when I > have any questions, the subject line should have [commons-graph] or > [graph2]. I have a few questions regarding it, but I wanted to have this one > cleared first. > Commons list so "commons-" prefix not needed. If you stick to the component directory name in SVN, that will always work -- thats [graph2] -- in this case, [graph] may work too. -Rahul > Thanks for the help in advance. > > Arshad. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DIGESTER][SANDBOX] back proposing the Digester3 merge to trunk
On Wed, Jun 1, 2011 at 1:46 AM, Simone Tripodi wrote:
> Hi Rahul :)
> thanks for following up!
>
> I can confirm they're NOT binary compatible even without running
> clirr, because of the following reasons:
>
We'll need to analyze with clirr anyway, minimally to produce good
release notes and 2.x -> 3.0 migration notes.
Not all breaks are equal, so in below:
> - deprecated APIs don't exist anymore;
Permissible in major release.
> - internals of annotations/xml modules have been rewritten as EDSL
> extensions;
> - some Digester methods changed signature, like Digester.pushParams(
> Object object ) versus the new Digester.pushParams( Object... object )
Above may be OK.
> - due to all these changes, I took advantage to repackage classes to
> org.apache.commons.digester3
>
+1 to repackage.
> Anyway I didn't break the pure Digester use as I did in the previous
> attempt, users are still able to bin rules using the usual pattern
>
> Digester d = new Digester();
> d.addObjectCreate("foo", "mypackage.Foo");
> ...
>
This is useful IMO.
-Rahul
> I would really appreciate if you have spare time to have a look at the
> code, I immagine you are quiet busy but there's no rush ;)
> Have a nice day, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Jun 1, 2011 at 12:08 AM, Rahul Akolkar
> wrote:
>> On Tue, May 31, 2011 at 5:46 PM, Simone Tripodi
>> wrote:
>>> New site is online, does someone have some spare time to check[1] and
>>> provide feedbacks about the merge proposal?
>>
>>
>> Don't have much time, but if its now compatible with 2.x thats a good
>> thing :-) You may want to confirm using a clirr or equivalent report.
>>
>> -Rahul
>>
>>
>>> Thanks in advance, have a nice day!!!
>>> Simo
>>>
>>> [1] http://commons.apache.org/sandbox/digester3/
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Tue, May 31, 2011 at 6:41 PM, Simone Tripodi
>>> wrote:
>>>> Hi all guys,
>>>> after some day of work on Sandbox, I'm back to propose once again the
>>>> merge of my work in proper /trunk.
>>>> Failing my first attempt was good, because I had the opportunity to
>>>> learn a lot and this time the proposal is much better :P
>>>>
>>>> What I did:
>>>>
>>>> - moved the current sandbox in a separate branch;
>>>> - copied the current trunk in sandbox;
>>>> - polished APIs (few trivial checkstyle violations yet), removed
>>>> @Deprecated methods, added more power with generics;
>>>> - re-introduced - simplifying! - the Digester EDSL;
>>>> - removed old custom DigesterLoader for annotations/xml package.
>>>>
>>>> So, at the end of the day, this time users are still able to create
>>>> Digester instances using the old-fashioned APIs - even if they're
>>>> encouraged to use the more expressive fluent APIs - except when using
>>>> annotations/XML extensions.
>>>>
>>>> I still have to publish the site - it's the site on /trunk + EDSL
>>>> documentation - I'll do it as soon as I'll get home (I'm leaving the
>>>> office now) so you can see how APIs/Doc look
>>>>
>>>> Anyway interested people can start having a look at the component code on
>>>> SVN[1]
>>>>
>>>> Please send huge feedbacks!!!
>>>> Have a nice day!
>>>> Simo
>>>>
>>>> [1] https://svn.apache.org/repos/asf/commons/sandbox/digester3/trunk
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DIGESTER][SANDBOX] back proposing the Digester3 merge to trunk
On Tue, May 31, 2011 at 5:46 PM, Simone Tripodi wrote: > New site is online, does someone have some spare time to check[1] and > provide feedbacks about the merge proposal? Don't have much time, but if its now compatible with 2.x thats a good thing :-) You may want to confirm using a clirr or equivalent report. -Rahul > Thanks in advance, have a nice day!!! > Simo > > [1] http://commons.apache.org/sandbox/digester3/ > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Tue, May 31, 2011 at 6:41 PM, Simone Tripodi > wrote: >> Hi all guys, >> after some day of work on Sandbox, I'm back to propose once again the >> merge of my work in proper /trunk. >> Failing my first attempt was good, because I had the opportunity to >> learn a lot and this time the proposal is much better :P >> >> What I did: >> >> - moved the current sandbox in a separate branch; >> - copied the current trunk in sandbox; >> - polished APIs (few trivial checkstyle violations yet), removed >> @Deprecated methods, added more power with generics; >> - re-introduced - simplifying! - the Digester EDSL; >> - removed old custom DigesterLoader for annotations/xml package. >> >> So, at the end of the day, this time users are still able to create >> Digester instances using the old-fashioned APIs - even if they're >> encouraged to use the more expressive fluent APIs - except when using >> annotations/XML extensions. >> >> I still have to publish the site - it's the site on /trunk + EDSL >> documentation - I'll do it as soon as I'll get home (I'm leaving the >> office now) so you can see how APIs/Doc look >> >> Anyway interested people can start having a look at the component code on >> SVN[1] >> >> Please send huge feedbacks!!! >> Have a nice day! >> Simo >> >> [1] https://svn.apache.org/repos/asf/commons/sandbox/digester3/trunk >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Tidy up test cases
On Thu, May 26, 2011 at 7:06 PM, sebb wrote:
> On 26 May 2011 14:46, Rahul Akolkar wrote:
>> On Thu, May 26, 2011 at 9:24 AM, sebb wrote:
>>> On 23 May 2011 16:22, Rahul Akolkar wrote:
>>>> On Mon, May 23, 2011 at 8:16 AM, sebb wrote:
>>>>> SCXML has had a couple of ongoing Gump failures, which I started to
>>>>> look at again.
>>>>>
>>>>
>>>> Thanks, the initial breakage was from EL trunk changes, if you follow
>>>> this trail (if you've begun to look into it, this probably won't be
>>>> new information):
>>>>
>>>> http://markmail.org/message/v2ioxdq2s7c62mtl
>>>>
>>>> Ofcourse, EL isn't active and I haven't looked into it.
>>>
>>> Progress so far:
>>>
>>> The test case breaks because the condition needed to change states is
>>> not set up.
>>>
>>> In particular the following line in jsp/datamodel-01.xml:
>>>
>>>
>>>
>>> causes the error:
>>>
>>> SEVERE: Attempt to convert String "baz" to type "org.w3c.dom.Node",
>>> but there is no PropertyEditor for that type
>>>
>>> It looks like the handling of assignment statements changes with the
>>> new version of EL.
>>>
>>> I've not yet established what the EL change is that causes the error.
>>> I suppose it's possible that the actual error is in SCXML, and EL code
>>> now reveals it.
>>>
>>
>>
>> Right, but certainly doesn't look like EL is a drop-in replacement --
>> I don't know if thats what the EL devs were aiming for :-) We are
>> attempting the conversion in the message above, which is possible when
>> using EL 1.0.
>
> The cause is https://issues.apache.org/jira/browse/EL-17.
>
> Previously, pLogger.isLoggingError() always returned true, whereas
> log.isErrorEnabled() only returns true if error logging is enabled.
> The default error logging is fatal, which prevents the ELException
> from being thrown when doing the conversion.
> If you set the log level to error or info, the tests pass - as can be
> seen in the Gump run:
>
> http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html
>
> The Gump run works, because I enabled info logging in order to try and
> debug the code ...
>
Thanks for digging into this.
Lets separate the two items clearly:
(a) whether the EL behavior change in r133240 is desired, and
(b) how the piece of SCXML code in question may be improved.
WRT (a) then, as you say in EL-17, the commit message seems to imply
the change is pretty innocuous so it may not be the case that the
change in behavior was actually desired. IMO behavior WRT throwing
exceptions changing based on logging level is not a good pattern. It
seems the relevant portions in EL should be reverted.
> I'm not entirely sure whether there is a bug in SCXML or not.
> Currently SCXML relies on an Exception being thrown for certain
> conversions - e.g. String to Node - when doing an Assign.
> The Assign.execute method has this clause:
>
> } catch (SCXMLExpressionException see) {
> // or something else, stuff toString() into lvalue
> Object valueObject = eval.eval(ctx, expr);
> SCXMLHelper.setNodeValue(oldNode, valueObject.toString());
> }
>
> This is rather fragile, as there are potentially quite a few
> conditions that can cause the exception.
>
> Seems to me it would be better to use some other way of establishing
> whether the assignment is intended to replace the node or set its
> value, but perhaps that would be rather difficult?
>
WRT (b), the WG is aware of the above fragility and has already
addressed this in the latest SCXML WD (Section D.3.5). The
implementation will have to follow the new clearer pattern when it
gets updated.
In summary, I think the EL change in question needs to be revisited,
if anyone is still around to look at EL. If not, EL seems a good
candidate for dormancy and subsequent removal of use of EL trunk from
Gump runs.
-Rahul
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Tidy up test cases
On Thu, May 26, 2011 at 9:24 AM, sebb wrote: > On 23 May 2011 16:22, Rahul Akolkar wrote: >> On Mon, May 23, 2011 at 8:16 AM, sebb wrote: >>> SCXML has had a couple of ongoing Gump failures, which I started to >>> look at again. >>> >> >> Thanks, the initial breakage was from EL trunk changes, if you follow >> this trail (if you've begun to look into it, this probably won't be >> new information): >> >> http://markmail.org/message/v2ioxdq2s7c62mtl >> >> Ofcourse, EL isn't active and I haven't looked into it. > > Progress so far: > > The test case breaks because the condition needed to change states is > not set up. > > In particular the following line in jsp/datamodel-01.xml: > > > > causes the error: > > SEVERE: Attempt to convert String "baz" to type "org.w3c.dom.Node", > but there is no PropertyEditor for that type > > It looks like the handling of assignment statements changes with the > new version of EL. > > I've not yet established what the EL change is that causes the error. > I suppose it's possible that the actual error is in SCXML, and EL code > now reveals it. > Right, but certainly doesn't look like EL is a drop-in replacement -- I don't know if thats what the EL devs were aiming for :-) We are attempting the conversion in the message above, which is possible when using EL 1.0. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Tidy up test cases
On Mon, May 23, 2011 at 11:41 AM, sebb wrote: > On 23 May 2011 16:22, Rahul Akolkar wrote: >> On Mon, May 23, 2011 at 8:16 AM, sebb wrote: >>> [As part of this, I noticed and fixed some minor issues in the Ant build >>> file.] >>> >> >> I understand some of the changes you've made, but can't guarantee they >> will persist as the Ant build file is generated and is regen'ed every >> release cycle. > > I see. In that case perhaps the generate process needs to be fixed. > e.g. IMO it does not make sense to release a build file that does not > specifiy the source and target Java versions or which does not specify > "includeantruntime" > For completion, its generated by the Maven Ant Plugin. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Tidy up test cases
On Mon, May 23, 2011 at 8:16 AM, sebb wrote: > SCXML has had a couple of ongoing Gump failures, which I started to > look at again. > Thanks, the initial breakage was from EL trunk changes, if you follow this trail (if you've begun to look into it, this probably won't be new information): http://markmail.org/message/v2ioxdq2s7c62mtl Ofcourse, EL isn't active and I haven't looked into it. > [As part of this, I noticed and fixed some minor issues in the Ant build > file.] > I understand some of the changes you've made, but can't guarantee they will persist as the Ant build file is generated and is regen'ed every release cycle. > The component currently uses nested test suites (and main() methods) > which are unnecessary. > They also make finding the errors harder, as one has to find which > suite includes the test. > > I'd like to remove all the main methods and all the suites which > merely group other tests. > > OK? > This doesn't bother me (we're not writing new tests or updating this everyday), but if you want to go ahead, thats fine with me. I ask that you also track and port applicable changes from trunk to the J6 branch, when making any changes to [SCXML]. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Revised dormancy policy
+1 -Rahul On Mon, May 16, 2011 at 1:52 PM, Phil Steitz wrote: > I would like to take the proposal made in [1], modified per > discussion on that thread to a VOTE, so we can start implementing > the policy. > > The provisions are as follows: > > 0) To move a component to dormant requires a VOTE. A single -1 > suffices to postpone the action; but a -1 in a dormancy vote is > really a +1 to help sustain or advance the component. Dormancy VOTEs > will remain open for two weeks. > > 1) When a component is voted "dormant": > a) the main web site and site navigation links show the > component as dormant > b) the component site and component JIRA page display a "dormant > disclaimer" (TBD) > c) JIRA remains open (not merged into Commons-Dormant, but JIRA > project page displays disclaimer) > d) svn remains open (but no commits without revival vote) > > 2) To revive a component requires another VOTE resulting in 3 +1s > from ASF committers interested in bringing the zombie back to life. > Revival VOTEs are majority rule. > > votes, please. This VOTE will remain open for at least 72 hours. > > Comments, as well as votes, are welcome from all community members. > I will revise the policy and restart the VOTE if necessary. > > Thanks! > > Phil > > [1] http://markmail.org/message/bbnuxxozsnkapfhr > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] Issue with TransitionTargetComparator
On Mon, May 9, 2011 at 11:16 AM, Yevgen Kogan wrote: > > Dear all, > > the line 90 of the > /commons/proper/scxml/trunk/src/main/java/org/apache/commons/scxml/semantics/TransitionTargetComparator > looks like this: > > State s = (State) iter.next(); > > The cast to State causes an cast exception for my state machine, because some > of my states are derived from Parallel. > > Now my question is, if the cast to State should be replaced with the cast to > TransitionTarget or is it legal to assume that alle TransitionTargets in the > method TransitionTargetComparator.compare(...) are States (it would imply > that my state machine is "brocken" ). > Nested parallels (without intermediate states) are usually redundant, but not illegal, so it may be better to fix the line as you suggest. Please open a ticket in JIRA [1]. Meanwhile, you may either (a) change your state machine to remove such nesting or (b) supply a custom semantics impl to the executor that uses a comparator with the change. -Rahul [1] http://commons.apache.org/scxml/issue-tracking.html > Thanks, > Eugen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCEMENT] Apache Commons Discovery 0.5 released!
On Thu, May 5, 2011 at 10:34 AM, sebb wrote: > I normally send a separate e-mail to announce @ a.o alone. [Might be > worth separating dev and user announces too.] > > This makes it slightly easier to track the bounces (which don't always > reference the original e-mail) as well as reducing the reply-all > scatter. > +1 -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all][proposal] Extend Dormant to include no longer active released components
On Thu, May 5, 2011 at 3:35 PM, Phil Steitz wrote: > As Hen has pointed out a couple of times, we have quite a few > Commons proper components that are no longer under active > development. I would like to propose that we extend the "dormant" > classification on the web site to include components that have had > releases. I am not sure whether we need to distinguish internally > within this group or do svn moves. I will start by proposing just > the minimalist approach: > > 0) To move a component to dormant requires a VOTE. A single -1 > suffices to postpone the action; but a -1 in a dormancy vote is > really a +1 to help sustain or advance the component. > I'd recommend lazy consensus votes that are open 10-ish days / couple of weeks -- this is how we've been making decisions on moving Jakarta bits to Attic. Lazy consensus because enough folks may not be bothered to chime in if its truly dormant, though Commons is different here :-), and long duration because we want to maximize chances of people seeing the vote. -Rahul > 1) When a component is voted "dormant": > a) the main web site and site navigation links show the component > as dormant > b) the component site and component JIRA page display a "dormant > disclaimer" (TBD) > c) JIRA remains open > d) svn remains open (maybe made read only? Could just agree to > no commits.) > > 2) To revive a component requires another VOTE resulting in 3 +1s > from ASF committers interested in bringing the zombie back to life. > > Phil > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCEMENT] Apache Commons Discovery 0.5 released!
On Thu, May 5, 2011 at 8:57 AM, Gary Gregory wrote: > Congratulations to Simone for pushing this release out! > +1 to that sentiment, but not to using reply all and having things like announce@ on CC (even if it bounces :-). -Rahul > Gary > > On May 5, 2011, at 8:26, Simone Tripodi wrote: > >> The Apache Commons team is pleased to announce the >> commons-discovery-0.5 release! >> >> The Apache Commons Discovery component is about discovering, or finding, >> implementations for pluggable interfaces. >> >> Changes in this version include: >> >> >> Fixed Bugs: >> o Enumeration in Service class is broken. Issue: DISCOVERY-3. >> o [discovery] Doesn't work with ClassLoaders that do not support >> getResource() Issue: DISCOVERY-6. >> o Service.providers Enumeration does not catch and discard >> UnsatisfiedLinkErrors and ExceptionInInitializerErrors. Issue: >> DISCOVERY-11. >> o SPI implementation class searching logic has some issues: it >> discards all errors; >> it only considers first className in supplied classNames array. >> Issue: DISCOVERY-12. >> o Problem with Oracle JVM classLoader. Issue: DISCOVERY-13. >> o Enumeration returned by Service.providers has a broken behavior. >> Issue: DISCOVERY-17. >> >> Changes: >> o Discovery failed to load an inner class. Issue: DISCOVERY-7. >> o Documentation of other use cases. Issue: DISCOVERY-9. >> o Moved to Java5 APIs, used Generics. Issue: DISCOVERY-14. >> o Custom org.apache.commons.discovery.log.Log implementation replaced by >> default commons-logging behavior. Issue: DISCOVERY-15. >> o The setLog() methods are not thread-safe and should be deprecated. >> Issue: DISCOVERY-16. >> >> Don't miss to check the Apache Commons component page on >> http://commons.apache.org/discovery/ >> >> Have fun! >> -Simo, on behalf of Apache Commons team >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] project status
On Fri, Apr 8, 2011 at 5:05 PM, Ryan wrote: > What is the current status of the SCXML project? Is there active development > going on? > There is little active development going on, for two reasons: (1) What we have works reasonably in its given state (2) I haven't had much time to continually track changes to the working drafts Having said that, I will make two other points: (a) I do hope to find some time when the SCXML spec goes 1.0 to brings things up to date with that version (anything in between is a bit of a moving target given limited cycles) (b) Others are always welcome to jump in with patches and changes > I work for an organization that will be using SCXML for telephone IVR system > dialplans, and we would like to use Apache SCXML to help us toward this end. > However, I do not want to use a project that has no active development and > is not planning to be stable. > Understandable, though I don't know what you mean by the last bit -- we are certainly not planning to be unstable ;-) In summary: * If you've tried Commons SCXML and it works for you in its current state, use it (past releases will always be available) * If you've tried Commons SCXML and you'd like to add/improve things, open tickets (with or without patches) and see how that goes * If you want to help update Commons SCXML to spec v1.0 (when it comes out) -- all help is welcome -Rahul > Thank you, > Ryan > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [parent] wagon protocols & mvn3
On Sun, Apr 3, 2011 at 5:03 PM, Simone Tripodi wrote: > Hi Rahul! > done, but I meant that in mvn3 the scp protocol doesn't come out of > the box, we need to plug the wagon-ssh extension. > For releasing the discovery, I switched to mvn2, but for future mvn3 > use I'd suggest to add it in the maven-3 profile in the parent pom. OK :-) -Rahul > Have a nice day, all the best! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [parent] wagon protocols & mvn3
On Sun, Apr 3, 2011 at 3:36 PM, Simone Tripodi wrote: > Hi all guys, > due to unsupported 'scp' protocol by default by mvn3[1], I'd suggest > to add, in the 'maven-3' profile in the commons-parent, the wagon-ssh > extension. For now, you could try tweaking the "commons.deployment.protocol" property (see very bottom of parent pom). -Rahul > If there isn't any objection, I can take care of it, just let me know. > In the meanwhile, I'd add the wagon-ssh in the [discovery] pom, is it > fine for you or he have to release the parent first? > Thanks in advance, > Simo > > [1] > https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-TransportProtocols%2528Wagons%2529 > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz wrote: > On 3/19/11 4:54 AM, Simone Tripodi wrote: >> Hi Rahul, >> thanks once again for the wise suggestions, much more than appreciated! >> >> I underestimated the importance of the users over the active >> developers, so I totally agree with you, moving to dormant is >> premature. >> >> I was aware about breaking APIs compatibility, since we had to face >> the same problem also in [pool2], I thought it would have been a good >> idea implementing the sandbox in the o.a.c.digester3[1] package, looks >> like it is compliant to the suggestions you proposed. >> >> I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we >> call a vote before going on? > +1 > I don't think we need a VOTE on this, I would say wait a couple of more days > to make sure we have (lazy) consensus and then just do it. > Not that I care for more process, but I'd like to see 3+ of us say this is the API they'd like to see for digester3. We also generally require votes for getting stuff out of sandbox so a vote may not be a bad idea (even if this isn't a new component, its a new API -- and somewhere in there, the lines are blurred). I'm +0. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
On Wed, Mar 16, 2011 at 2:31 PM, Simone Tripodi wrote: > Hi all mates!!! > I need your support on advising our users that a new version of > Digester is available on sandbox, I already sent more than once an > email on users ML but never got a reply, maybe my name is not so > influent between users or maybe the Digester is not so popular as I > still think... but I wouldn't have wasted the time I invested :P > > So, IMHO there are few points that deserve our attention, such: > > * if the Digester is out of our users' interest, it should be - > sadly! - moved to the Dormant; We've users, though no active developers beyond you -- as long as you're interested I think a move to dormant is premature. > * if the previous tense is wrong: > * just maintain the current implementation in trunk, or > * evaluate if the new Digester3 is a good candidate to replace the > proper one > Third option would be to do both. More below. > I'm sure that together we can find the right way, for those interested > knowing more details, Digester3 docs is on[1] with samples. > Having looked at the samples and API, its clearly not compatible (this is not a statement about its value). I don't think we should use the same Java packages (oac.digester.*) since this isn't a drop-in replacement. However, if you are keen on releasing this (I don't have time to help in near future), an option would be to promote and release the sandbox code while keeping the oac.digester3.* packages. This would mean doing both: (a) retaining current code in 1.x and 2.x branches in case future releases need to be made on those lines and (b) moving sandbox code to trunk as 3.x line (while keeping the oac.digester3.* packages). -Rahul > Looking forward to read from you soon, have a nice day!!! > Simo > > [1] http://commons.apache.org/sandbox/digester3/ > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][SITE] Release Commons Parent 20 based on RC1
+1 -Rahul On Tue, Mar 15, 2011 at 8:15 AM, sebb wrote: > Please may I have your votes for Commons Parent 20? > > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapachecommons-002/org/apache/commons/ > > SVN > https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-20-RC1 > > Commons Parent 20 changes (from 19) > == > - the combination "Commons FOO" is no longer claimed as a trademark > > Commons Parent 20 based on RC1 > == > > [ ] +1 > [ ] -1, because: > > Thanks! > > Vote will remain open for at least 72 hours. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][SITE] Release Commons Skin 3 and Commons Parent 19
+1 to both. -Rahul On Fri, Mar 11, 2011 at 10:18 PM, sebb wrote: > Please may I have your votes for Commons Skin 3 and Commons Parent 19? > > The two have to be tested together because Commons Skin 3 is > referenced from Commons Parent 19. > > If the vote for Commons Skin fails, then Commons Parent fails, but > Commons Skin can be released without Commons Parent, so please vote > separately for each. Thankyou! > > Note: to test this you need to change the POM to reference commons-parent 19. > > As this is not yet in an official repo, you will need to add the > following repository definition to your settings.xml (and use the > profile -PNexus): > > > Nexus > > > > Nexus > > https://repository.apache.org/content/repositories/orgapachecommons-002 > > > > > > Or you can add the section above to your POM temporarily > > Or, if you have downloaded the Commons Parent from the SVN tag, just > use mvn install. > > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapachecommons-002/org/apache/commons/ > > SVN > https://svn.apache.org/repos/asf/commons/proper/commons-skin/tags/commons-skin-3-RC3/ > and > https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-19-RC3/ > > Commons Skin 3 changes (from 3) > = > - commons parent 5 => 18 > - added support for code prettify > - site.css now uses relative url for referencing css files, so offline > sites work better > - added template to support trademark footer; also supports > $relativePath resolution; adds TM overlay support; allows absolute > URLs in banner elements > > Changes since previous vote: > - smaller TM font > - TM overlay now specified by property in pom.xml, not site.xml > section > - TM overlay is disabled by default > > Commons Parent 19 changes (from 18) > == > - Apache Parent Pom 7=> 9 > - maven-antrun-plugin 1.3 => 1.5 > - antrun config: change deprecated to > - site plugin 2.0.1 => 2.2.1 > - surefire 2.7.1 => 2.7.2 > - javadoc 2.5 => 2.7 > - add AL header to site.xml > - use local copy of commons-logo, rather than linking to commons.a.o > - always use absolute link for http://commons.a.o/ > - commons skin 2=>3 > - added prettify css/javascript to improve source code formatting > - license now points to http://www.apache.org/licenses/ as per > branding guidelines > - synchronise common menu items with commons-site > - moved ApacheCon logo under ASF menu, and made it clickable > - added trademark references to page footers > > Changes since previous vote: > - TM overlay no longer added by default > - the bareword "Commons" no longer claimed as a trademark > - updated site plugin to 2.2.1 (2.2 is broken) > > PLEASE VOTE FOR EACH SEPARATELY > > Commons Skin 3 based on RC3 > === > > [ ] +1 > [ ] -1, because: > > Commons Parent 19 based on RC3 > == > > [ ] +1 > [ ] -1, because: > > Thanks! > > Vote will remain open for at least 72 hours. > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox
On Mon, Feb 28, 2011 at 8:35 AM, Simone Tripodi wrote: > Good morning all guys, > in the last month I've invested my spare time on redesigning a new > potential version of the Digester component in Sandbox, according to > what I proposed time ago on dev ML[1]. > The experiment is complete at 95%, is not of course a release but > there are enough tests/samples/docs to start playing with it. > I also sent an email to users ML[2] requesting for feedbacks, > unfortunately no one expressed his opinion yet, but I'll be patient at > least for the next 2-3 weeks before pushing a request again. > > I'd like to ask also your feedbacks and suggestions, in case you would > be interested in a potential promotion on Proper, or it should be > contributed somewhere else like extras, but I hope it will find a > place in commons. > As Rahul proposed, since there are APIs breakage, maybe it should be > taken in consideration as a new component, but at the same time as > Matt suggested, since it processes inputs in the same way, maybe is > just a major release. > > WDT? What are your thoughts about it? Can we see a "before and after" i.e. show API usages on either when parsing the same sample? As an aside, I'd suggest we all start new threads for peripheral discussions i.e. not directly about future of digester (such as suppressing unchecked warnings, we don't want to fill this important thread with that :-). -Rahul > Sorry if it looks like a silly > question but I've never taken part of a sandbox promotion. > Looking forward to hear from you, have a nice day! > Simo > > [1] http://markmail.org/message/5ry2lmfkpxkrqwh6 > [2] http://markmail.org/message/qybp7ra3g5tpeayi > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] semantics of nested history in parallel state
On Tue, Mar 1, 2011 at 6:57 PM, Jacob Beard wrote: > Please keep an eye on the www-voice thread. I think there may still be > problems with the current step algorithm, and I'm drafting a reply to > elaborate on this. > Sure. -Rahul > Thanks, > > Jake > > On Tue, Mar 1, 2011 at 6:50 PM, Rahul Akolkar wrote: >> On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard wrote: >>> Hi, >>> >>> I'm currently working on revising scxml-js so that it implements the >>> semantics defined by the step algorithm of the SCXML specification (as >>> opposed to the mixture of SCXML semantics and Rhapsody semantics which >>> it currently implements). I've run into a part of the step algorithm >>> which is somewhat unclear, and because it may relate to a limitation >>> in the Commons SCXML implementation, I thought I would ask about this >>> on the Commons SCXML list before asking about it on the w3-voice list. >>> >>> Consider the following SCXML document: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> (https://gist.github.com/846316) >>> >>> >>> I believe the step algorithm in the SCXML specification would >>> interpret the document in the following way: >>> >>> addStatesToEnter would at some point be called for parallel state p. >>> addStatesToEnter would then be called recursively for each of p's >>> children: h, A, B. >>> >>> addStatesToEnter would first be called for h. Because this is the >>> first time h was entered, addStatesToEnter will be recursively called >>> for each of the targets of its default transition: A.2 and B.2. A.2 >>> and B.2 will then be added to statesToEnter. >>> >>> addStatesToEnter would then be called for state A. A is a compound >>> state, so addStatesToEnter would then be called for A's initial state: >>> A.1. A.1 would then be added to statesToEnter. >>> >>> The same would occur for B, and so B.1 would be added to statesToEnter. >>> >>> The resulting configuration would then be: p,h,A,B,A.1,A.2,B.1,B.2, >>> which is not a legal configuration, as A and B are both OR states. >>> >>> >>> >>> Is my interpretation of the specification correct, in that the step >>> algorithm would allow this illegal configuration, or am I missing >>> something? >>> >>> >>> >>> I'm asking this question here, rather than on the w3-voice list, >>> because I believe Commons SCXML does not currently support history in >>> parallel: >>> http://mail-archives.apache.org/mod_mbox/commons-user/201001.mbox/%3cce1f2ea81001131340w2aaaf5bfs84b9db2252287...@mail.gmail.com%3E >>> >>> It's not clear whether this is due to possible conflicts in SCXML >>> semantics, or whether this is simply Commons SCXML implementation >>> lagging a bit behind changes in the specification. >>> >> >> >> Its lag. I believe you have your answer on w3-voice, if not, let me >> know and I'll look further. >> >> -Rahul >> >> >>> I'd appreciate any guidance you can offer. Thanks, >>> >>> Jake >>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml] semantics of nested history in parallel state
On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard wrote: > Hi, > > I'm currently working on revising scxml-js so that it implements the > semantics defined by the step algorithm of the SCXML specification (as > opposed to the mixture of SCXML semantics and Rhapsody semantics which > it currently implements). I've run into a part of the step algorithm > which is somewhat unclear, and because it may relate to a limitation > in the Commons SCXML implementation, I thought I would ask about this > on the Commons SCXML list before asking about it on the w3-voice list. > > Consider the following SCXML document: > > > > > > > > > > > > > > > > > > > > > > > > (https://gist.github.com/846316) > > > I believe the step algorithm in the SCXML specification would > interpret the document in the following way: > > addStatesToEnter would at some point be called for parallel state p. > addStatesToEnter would then be called recursively for each of p's > children: h, A, B. > > addStatesToEnter would first be called for h. Because this is the > first time h was entered, addStatesToEnter will be recursively called > for each of the targets of its default transition: A.2 and B.2. A.2 > and B.2 will then be added to statesToEnter. > > addStatesToEnter would then be called for state A. A is a compound > state, so addStatesToEnter would then be called for A's initial state: > A.1. A.1 would then be added to statesToEnter. > > The same would occur for B, and so B.1 would be added to statesToEnter. > > The resulting configuration would then be: p,h,A,B,A.1,A.2,B.1,B.2, > which is not a legal configuration, as A and B are both OR states. > > > > Is my interpretation of the specification correct, in that the step > algorithm would allow this illegal configuration, or am I missing > something? > > > > I'm asking this question here, rather than on the w3-voice list, > because I believe Commons SCXML does not currently support history in > parallel: > http://mail-archives.apache.org/mod_mbox/commons-user/201001.mbox/%3cce1f2ea81001131340w2aaaf5bfs84b9db2252287...@mail.gmail.com%3E > > It's not clear whether this is due to possible conflicts in SCXML > semantics, or whether this is simply Commons SCXML implementation > lagging a bit behind changes in the specification. > Its lag. I believe you have your answer on w3-voice, if not, let me know and I'll look further. -Rahul > I'd appreciate any guidance you can offer. Thanks, > > Jake > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Do Apache Commons SCXML support XInclude and XPath 2.0?
2011/2/23 Gavin Lei : > Hi Rahul, > > Thank you for your answer. It means that we can take some measures to > support XInclude and XPath 2.0 in Commons SCXML. Commons SCXML use > Digester to support XInclude and use JDK's API to support XPath( In my > memory, JDK use Apache Xalan library to support XPath, so there's a > small question, Xalan support XPath 1.0 only, may be Commons SCXML > support XPath 1.0 only ). > I pointed to an Evaluator that uses javax.xml.xpath in the previous email. Similarly, one could author an Evaluator impl that uses Saxon, for example, to get XPath 2.0 support. Evaluators are meant to be pluggable (with corresponding Context impls) in Commons SCXML. > Nowadays, I am developing a Flex ActionScript SCXML engine -- > SCXML4Flex [1], we have finished some basic functions (such as SCXML > document parse job, custom action support ) for it. In the future, > there are still three milestones for this project: XInclude support, > XPath 2.0 support andEvent I/O Processors support. So, you have been > working with SCXML for years, do you have any suggestions about these > features ? > We've talked about XInclude and XPath 2.0 already in this thread. Commons SCXML doesn't provide all the I/O processors yet (in the manner described in the spec), so don't have much to add there. -Rahul > > [1] http://code.google.com/p/scxml4flex/ > > 在 2011年2月24日 上午6:25，Rahul Akolkar 写道： >> 2011/2/23 Gavin Lei : >>> Hi guys, >>> Do Apache Commons SCXML support XInclude and XPath 2.0? Today i want >>> to do some experiments to confirm this, but it seems that Commons >>> SCXML does not support XInclude and XPath 2.0. >>> 1. about XInclude >>> I try to run such a SCXML document in Commons SCXML engine: >>> >>> http://www.w3.org/2001/XInclude";> >>> >>> >>> >>> x = x + 5; >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> datamodel.xml: >>> >>> >>> >>> >>> >>> But it seems that Commons SCXML does not work for me. So, i want to >>> confirm that Commons SCXML support XInclude or not. >>> >> >> >> It (the last release) doesn't, but it won't be difficult to add. The >> last release used Commons Digester for parsing. Since then, Digester >> has added XInclude support, so the actual change now necessary to the >> SCXMLParser class is minimal. >> >> It may be possible to parse documents containing XInclude using the >> new and unreleased parser class (i.e. SCXMLReader in the J6 branch in >> SVN) by passing the appropriate inputs/options to the StAX parser. >> >> >>> 2, about XPath 2.0 >>> In W3C's SCXML recommendation specification, it show that SCXML engine >>> should support XPath 2.0 and XPath 2.0 functions. And i tried a SCXML >>> document with this State in it: >>> >>> http://www.w3.org/2005/xpath-functions";> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> target="newBehavior"/> >>> >>> >>> >>> >>> >>> But it seems that Commons SCXML does not work for me too. I think >>> XInclude and XPath support are both very importmant in SCXML >>> application. So i want to confirm Commons SCXML support these >>> features or not. If yes, how can we use them ? If not, may be we can >>> do something to improve Commons SCXML. Thank You. >>> >> >> >> You may use an XPathEvaluator like the one below and pass in the >> functions you want supported (see 2nd constructor which takes a map, >> for how arbitrary XPath functions support may be added): >> >> http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/main/java/org/apache/commons/scxml/env/xpath/XPathEvaluator.java >> >> -Rahul >> >> >>> -- >>> - >>> Best Regards >>> Gavin Lei (雷银) >>> Email: gavingui2...@gmail.com >>> >> > -- > - > Best Regards > Gavin Lei (雷银) > Email: gavingui2...@gmail.com > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Do Apache Commons SCXML support XInclude and XPath 2.0?
2011/2/23 Gavin Lei : > Hi guys, > Do Apache Commons SCXML support XInclude and XPath 2.0? Today i want > to do some experiments to confirm this, but it seems that Commons > SCXML does not support XInclude and XPath 2.0. > 1. about XInclude > I try to run such a SCXML document in Commons SCXML engine: > > http://www.w3.org/2001/XInclude";> > > > > x = x + 5; > > > > > > > > > > > > > > datamodel.xml: > > > > > > But it seems that Commons SCXML does not work for me. So, i want to > confirm that Commons SCXML support XInclude or not. > It (the last release) doesn't, but it won't be difficult to add. The last release used Commons Digester for parsing. Since then, Digester has added XInclude support, so the actual change now necessary to the SCXMLParser class is minimal. It may be possible to parse documents containing XInclude using the new and unreleased parser class (i.e. SCXMLReader in the J6 branch in SVN) by passing the appropriate inputs/options to the StAX parser. > 2, about XPath 2.0 > In W3C's SCXML recommendation specification, it show that SCXML engine > should support XPath 2.0 and XPath 2.0 functions. And i tried a SCXML > document with this State in it: > > http://www.w3.org/2005/xpath-functions";> > > > > > > > > > > > > > > > But it seems that Commons SCXML does not work for me too. I think > XInclude and XPath support are both very importmant in SCXML > application. So i want to confirm Commons SCXML support these > features or not. If yes, how can we use them ? If not, may be we can > do something to improve Commons SCXML. Thank You. > You may use an XPathEvaluator like the one below and pass in the functions you want supported (see 2nd constructor which takes a map, for how arbitrary XPath functions support may be added): http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/src/main/java/org/apache/commons/scxml/env/xpath/XPathEvaluator.java -Rahul > -- > - > Best Regards > Gavin Lei (雷银) > Email: gavingui2...@gmail.com > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Short description in commit messages (was: svn commit: r1072000)
On Sat, Feb 19, 2011 at 2:22 PM, sebb wrote: > On 18 February 2011 22:54, Phil Steitz wrote: >> On 2/18/11 2:14 PM, sebb wrote: >>> I agree it's helpful to have at least the subject of the JIRA in the >>> log message, but IMO there should be nothing in the log message that >>> is not in the JIRA and/or code comments. >>> >>> The SVN log message should enable reviewers to understand the content >>> of the commit but should otherwise be disposable. SVN log messages are >>> not versioned, so can be permanently overwritten. Also we release >>> source code, and if SVN log messages are necessary to understand the >>> code, then the comments are insufficient. >>> >> I agree that svn log messages should not be necessary to understand >> the code; but they are a very important tool in understanding how >> the revision history works - i.e., what was changed when. The fact >> that they can be modified is a plus - it means we can go back and >> fix errors in the log messages or improve them. > > Or they can be obliterated with no trace ... > I doubt this happens often, and if and when it does, we have oversight via notification of svn:log changes (and permanent archival). >> I am frequently >> thankful of developers who have written good and complete commit >> messages not for understanding how code works, but why it works the >> way it does. > > Such information should not be confined to log messages, partly > because log messages are hard to scan and not guaranteed to be > available, but mainly because the source code should be understandable > on its own. > > External users will generally only see the source code. If there is > important information about how the source code works buried in SVN > log messages, then I think we have failed to produce the best source > code that we can. > We may be talking about different things by now. The original point was (since I made it) -- when I read diffs in email or 'svn log' output, it is easier if I see "FOO-123 Fixed bar to alleviate baz" as against "FOO-123". -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Short description in commit messages (was: svn commit: r1072000)
On Fri, Feb 18, 2011 at 9:06 AM, wrote: > Author: henrib > Date: Fri Feb 18 14:06:47 2011 > New Revision: 1072000 > > URL: http://svn.apache.org/viewvc?rev=1072000&view=rev > Log: > JEXL-83 > Can you please add a short sentence or two to future commit messages about the changes? (in addition to issue # ofcourse). It helps things like 'svn log' quite a bit to have that in the commit message itself. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [configuration] Compilation under Java 1.4
On Wed, Feb 16, 2011 at 3:45 PM, Oliver Heger wrote: > Am 15.02.2011 21:23, schrieb Oliver Heger: >> >> Am 10.02.2011 13:09, schrieb sebb: >>> >>> >>> FYI: >>> >>> Note that the Commons Parent POM was changed some while ago to add >>> profiles java-1.4, java-1.3 etc. which change the Java version used >>> for compile and test without needing to change the JVM used to run >>> Maven itself. >>> >>> See >>> >>> http://commons.apache.org/commons-parent-pom.html#Testing_with_different_Java_versions >>> >> >> Thanks for the pointer. I will try to exclude the affected classes if >> the profile for Java 1.4 is active. >> > > Just an update: I have added a profile which excludes the problematic > classes when building under JDK 1.4. With the current version of the pom it > is possible to run the following command successfully: > > mvn clean package -Pjava-1.4 > > However, what does not work is the following: If you first build without the > profile (using Java 1.5+), you cannot simply run > > mvn test -Pjava-1.4 > > (i.e. simply running tests without compiling). Test execution is aborted > immediately with a bad class version error, although I excluded the classes > in the configuration of the surefire plug-in. No idea why this is the case. > The sources are already compiled using the higher JDK by then (and mvn test won't clean that compile run). -Rahul > Oliver > >> Oliver >> >>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [attributes] Gump failure after qdox update
On Fri, Feb 11, 2011 at 3:55 AM, Stefan Bodewig wrote:
> On 2011-02-11, Gump wrote:
>
>> [javac]
>> /srv/gump/public/workspace/apache-commons/attributes/compiler/src/java/org/apache/commons/attributes/compiler/AttributeCompiler.java:245:
>> incompatible types
>> [javac] found : com.thoughtworks.qdox.model.JavaPackage
>> [javac] required: java.lang.String
>> [javac] packageName = javaClass.getPackage ();
>> [javac] ^
>
> This started when I upgraded Gump's version of qdox from 1.6 to 1.12
> ('cause FOP needed the newer version).
>
> IIUC there hasn't been any change in attributes for two years so I'm not
> sure what to do with it. Try to adapt attributes to a newer qdox?
> Provide the old qdox to attributes in Gump so it can build even though
> no other project in Gump needs it? Remove attributes from Gump?
>
> Any ideas?
>
If no one shows interest in helping you with this, then I think we can
move attributes from proper to dormant and remove it from Gump.
-Rahul
> Stefan
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [sandbox] new sandbox component
On Mon, Jan 31, 2011 at 3:22 PM, Phil Steitz wrote: > On Mon, Jan 31, 2011 at 3:12 PM, Gary Gregory > wrote: >>> -Original Message- >>> From: Luc Maisonobe [mailto:luc.maison...@free.fr] >>> Sent: Monday, January 31, 2011 14:52 >>> To: Commons Developers List >>> Subject: Re: [sandbox] new sandbox component >>> >>> Le 31/01/2011 20:13, Phil Steitz a écrit : >>> > On 1/31/11 1:59 PM, Luc Maisonobe wrote: >>> >> Le 31/01/2011 17:46, Gary Gregory a écrit : >>> >>> Does that really fit in [math] or would it be better in a new component >>> like a [geometry]? >>> >> Good idea, thanks Gary, I'll start with geometry as the name. We can >>> >> decide later if we include it in [math] or not. It will at least depend >>> >> on [math]. >>> >> >>> > Hey, last I checked geometry was a field within math :) >>> >>> Yes, and its the part the new code will depend on. >>> So should I stick to BSP ? I was wondering if I can do some nice acronym >>> that would sound like commons-BoSPhore (this was also a pun as Bosphore >>> can be considered a splitting line between Europe and Asia ... >>> >>> Luc >> >> While I like to have fun to make up names, for smaller components (as >> opposed to a server), l like obvious names. [Math] is obvious. [BSP] is not >> crystal clear but [Math-BSP] is. >> >> I always scratch my head when I read: '[ANNOUNCE] Project Zazibar releases >> version 2.3' and nowhere in the announcement is a hint of what project >> Zanzibar is. >> >> [Math-...] makes it obvious that it is closely related to [Math]. But it's >> not as much fun as Project Ka-Pow. >> > So far, we have mostly steered clear of cutesy, meaningless names in > Commons. Personally, I would prefer that we keep it that way. +1 -Rahul > The > "old charter" [1], which I guess is now somehow "deprecated" actually > requires "boring functional names." > > Phil > > [1] http://commons.apache.org/oldcharter.html > >> Gary >> >>> >>> > >>> > Phil >>> >> Luc >>> >> >>> >>> Gary >>> >>> >>> -Original Message- >>> From: luc.maison...@free.fr [mailto:luc.maison...@free.fr] >>> Sent: Monday, January 31, 2011 11:23 >>> To: Commons Developers List >>> Subject: [sandbox] new sandbox component >>> >>> Hi all, >>> >>> I have a bunch of code lying around to deal with BSP trees (useful in >>> different kinds of geometry modeling) and I would like to start a new >>> sandbox component to improve it and maybe merge it back to [math] if >>> useful >>> or let it grow as a standalone component. >>> >>> Do you agree with the idea ? How do I start a new sandbox component ? >>> >>> best regards, >>> Luc >>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Releasing commons-parent
On Fri, Jan 28, 2011 at 1:57 PM, Gary Gregory wrote: >> -Original Message- >> From: Gary Gregory [mailto:ggreg...@seagullsoftware.com] >> Sent: Friday, January 28, 2011 13:56 >> To: Commons Developers List >> Subject: Releasing commons-parent >> >> Well, I am digging around for instructions on publishing commons-parent and >> I am not sure if what I am seeing on various apache pages applies to >> commons-parent which is not the same kind of project as other commons >> projects. >> >> Any tips please? > > I should have asked, is it as simple as calling mvn deploy:deploy > > ? > Use the release plugin, scroll down to "Releasing commons-parent pom" on this page: http://wiki.apache.org/commons/CreatingReleases -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vote][sandbox] Proposal for Digester3 sandbox
On Mon, Jan 24, 2011 at 11:38 AM, Simone Tripodi wrote: > Hi Matt!!! > I always appreciate a feedback from you! I just implemented a spike on > my local workspace so I still don't have idea if the API beakage will > be so deep, I'll wait for more feedbacks before creating the sandbox, > to see if there are objections. BTW thanks a lot for your thoughts and > contribution! As I said elsethread, no objections at all for a sandbox spike (how could there be any :-). -Rahul > Moreover you too indirectly inspired me to start this work, when you > started implementing the new proxy features, with the static type safe > DSL :P > Have a nice day, all the best, > Simo :) > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Jan 24, 2011 at 5:10 PM, Matt Benson wrote: >> Speaking as a non-user of Digester, it would seem that as long as a new >> version can process the same XML configs, and retains the ability to plug >> in/adapt extensions written against v2, breakage of other APIs (which should >> be minimal in such a library) isn't terribly important. Again, this is >> spoken from a position of ignorance, so feel free to tell me how and why I'm >> wrong. >> >> $0.02, >> Matt >> >> On Jan 24, 2011, at 4:01 AM, Simone Tripodi wrote: >> >>> That's very good Rahul, >>> being yourself also a Digester users, it should be easier for me >>> having you to give a guideline :) >>> Have a nice day! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Mon, Jan 24, 2011 at 4:08 AM, Rahul Akolkar >>> wrote: >>>> On Sun, Jan 23, 2011 at 9:47 PM, Simone Tripodi >>>> wrote: >>>>> Hi Rahul! :) >>>>> good point, I think that this is yet another good reason to work on >>>>> sandbox before, I'll try to stay close as much as possible to the >>>>> current Digester concept, my idea/purpose/intensions are providing a >>>>> new Digester and not replacing it. >>>> >>>> >>>> Great, lets put ourselves in the shoes of existing digester users >>>> (indeed, I am one). >>>> >>>> If that doesn't sound like fun, the rewrite can always be proposed as >>>> a new component :-) >>>> >>>> -Rahul >>>> >>>> >>>>> Of course, suggestions/participation/feedbacks/guidelines are always >>>>> accepted, many thanks in advance!!! >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> On Mon, Jan 24, 2011 at 3:25 AM, Rahul Akolkar >>>>> wrote: >>>>>> On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi >>>>>> wrote: >>>>>>> Hi Rahul!!! :) >>>>>>> thanks for your feedbacks!!! this time I would like to experiment in >>>>>>> the sandbox an almost complete rewrite of Digester, simplifying the >>>>>>> actual design centralizing the configuration - and loosing >>>>>>> retro-compatibility. Moreover I would like doing a strong code >>>>>>> polishing, removing deprecated APIs at first stage. >>>>>>> >>>>>> >>>>>> >>>>>> If we're losing compatibility in the core component APIs due to a >>>>>> major rewrite, it may be better as a new component rather than the >>>>>> next major release. >>>>>> >>>>>> -Rahul >>>>>> >>>>>> >>>>>>> The idea can, of course, be ported also on the current Digester >>>>>>> implementation, so once the sandbox will be completed we could apply >>>>>>> the new feature also on 2.X and at the same time think about a >>>>>>> possible 3.X. >>>>>>> WDYT? >>>>>>> Have a nice day, all the best, >>>>>>> Simo >>>>>>> >>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>> http://www.99soft.org/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar >>>>>>> wro
Re: [vote][sandbox] Proposal for Digester3 sandbox
On Mon, Jan 24, 2011 at 11:10 AM, Matt Benson wrote: > Speaking as a non-user of Digester, it would seem that as long as a new > version can process the same XML configs, and retains the ability to plug > in/adapt extensions written against v2, breakage of other APIs (which should > be minimal in such a library) isn't terribly important. Again, this is > spoken from a position of ignorance, so feel free to tell me how and why I'm > wrong. > Barring well thought out exceptions (such as glaring bugs), old code should continue to work. Parsing the same XML isn't the issue, parsing the same XML using the same APIs to deliver the same result is. If the core rules and rules registration APIs change, then it might as well be called Commons Foo. As you're aware, at Commons, we tend to be bound to our core component API decisions (more than other places perhaps) -- for the users, this can be seen as a feature. -Rahul > $0.02, > Matt > > On Jan 24, 2011, at 4:01 AM, Simone Tripodi wrote: > >> That's very good Rahul, >> being yourself also a Digester users, it should be easier for me >> having you to give a guideline :) >> Have a nice day! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Mon, Jan 24, 2011 at 4:08 AM, Rahul Akolkar >> wrote: >>> On Sun, Jan 23, 2011 at 9:47 PM, Simone Tripodi >>> wrote: >>>> Hi Rahul! :) >>>> good point, I think that this is yet another good reason to work on >>>> sandbox before, I'll try to stay close as much as possible to the >>>> current Digester concept, my idea/purpose/intensions are providing a >>>> new Digester and not replacing it. >>> >>> >>> Great, lets put ourselves in the shoes of existing digester users >>> (indeed, I am one). >>> >>> If that doesn't sound like fun, the rewrite can always be proposed as >>> a new component :-) >>> >>> -Rahul >>> >>> >>>> Of course, suggestions/participation/feedbacks/guidelines are always >>>> accepted, many thanks in advance!!! >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Mon, Jan 24, 2011 at 3:25 AM, Rahul Akolkar >>>> wrote: >>>>> On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi >>>>> wrote: >>>>>> Hi Rahul!!! :) >>>>>> thanks for your feedbacks!!! this time I would like to experiment in >>>>>> the sandbox an almost complete rewrite of Digester, simplifying the >>>>>> actual design centralizing the configuration - and loosing >>>>>> retro-compatibility. Moreover I would like doing a strong code >>>>>> polishing, removing deprecated APIs at first stage. >>>>>> >>>>> >>>>> >>>>> If we're losing compatibility in the core component APIs due to a >>>>> major rewrite, it may be better as a new component rather than the >>>>> next major release. >>>>> >>>>> -Rahul >>>>> >>>>> >>>>>> The idea can, of course, be ported also on the current Digester >>>>>> implementation, so once the sandbox will be completed we could apply >>>>>> the new feature also on 2.X and at the same time think about a >>>>>> possible 3.X. >>>>>> WDYT? >>>>>> Have a nice day, all the best, >>>>>> Simo >>>>>> >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://www.99soft.org/ >>>>>> >>>>>> >>>>>> >>>>>> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar >>>>>> wrote: >>>>>>> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi >>>>>>> wrote: >>>>>>>> Hi all guys, >>>>>>>> I would like to propose a new sandbox to experiment a fresh, >>>>>>>> different, new set of Digester APIs that strongly uses a DSL for rules >>>>>>>> configuration. >>>>>>>> As described in the original proposal[1], the idea comes from a James >>>>>>>> Carman's comment on an old Digester issue, so his >>>>>>>> help/guidance/mentoring would be more than appreciated. >>>>>>>> Please cast your vote, if there are no objections I would like to >>>>>>>> start this work in the sandbox and try to promote as TLP with your >>>>>>>> help/mentoring/involvement. >>>>>>> >>>>>>> >>>>>>> This would be in addition to the existing digester APIs? I think we >>>>>>> want to be compatible so don't know if it makes sense to remove/change >>>>>>> existing APIs. >>>>>>> >>>>>>> The sandbox is always open for experimentation, no objections there. >>>>>>> >>>>>>> -Rahul >>>>>>> >>>>>>> >>>>>>>> I really hope this could be point of your interest that makes you >>>>>>>> curious enough to participate! >>>>>>>> Have a nice day, all the best, >>>>>>>> Simo >>>>>>>> >>>>>>>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6 >>>>>>>> >>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>> http://www.99soft.org/ >>>>>>>> >>>>>>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vote][sandbox] Proposal for Digester3 sandbox
On Sun, Jan 23, 2011 at 9:47 PM, Simone Tripodi wrote: > Hi Rahul! :) > good point, I think that this is yet another good reason to work on > sandbox before, I'll try to stay close as much as possible to the > current Digester concept, my idea/purpose/intensions are providing a > new Digester and not replacing it. Great, lets put ourselves in the shoes of existing digester users (indeed, I am one). If that doesn't sound like fun, the rewrite can always be proposed as a new component :-) -Rahul > Of course, suggestions/participation/feedbacks/guidelines are always > accepted, many thanks in advance!!! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Jan 24, 2011 at 3:25 AM, Rahul Akolkar > wrote: >> On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi >> wrote: >>> Hi Rahul!!! :) >>> thanks for your feedbacks!!! this time I would like to experiment in >>> the sandbox an almost complete rewrite of Digester, simplifying the >>> actual design centralizing the configuration - and loosing >>> retro-compatibility. Moreover I would like doing a strong code >>> polishing, removing deprecated APIs at first stage. >>> >> >> >> If we're losing compatibility in the core component APIs due to a >> major rewrite, it may be better as a new component rather than the >> next major release. >> >> -Rahul >> >> >>> The idea can, of course, be ported also on the current Digester >>> implementation, so once the sandbox will be completed we could apply >>> the new feature also on 2.X and at the same time think about a >>> possible 3.X. >>> WDYT? >>> Have a nice day, all the best, >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar >>> wrote: >>>> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi >>>> wrote: >>>>> Hi all guys, >>>>> I would like to propose a new sandbox to experiment a fresh, >>>>> different, new set of Digester APIs that strongly uses a DSL for rules >>>>> configuration. >>>>> As described in the original proposal[1], the idea comes from a James >>>>> Carman's comment on an old Digester issue, so his >>>>> help/guidance/mentoring would be more than appreciated. >>>>> Please cast your vote, if there are no objections I would like to >>>>> start this work in the sandbox and try to promote as TLP with your >>>>> help/mentoring/involvement. >>>> >>>> >>>> This would be in addition to the existing digester APIs? I think we >>>> want to be compatible so don't know if it makes sense to remove/change >>>> existing APIs. >>>> >>>> The sandbox is always open for experimentation, no objections there. >>>> >>>> -Rahul >>>> >>>> >>>>> I really hope this could be point of your interest that makes you >>>>> curious enough to participate! >>>>> Have a nice day, all the best, >>>>> Simo >>>>> >>>>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6 >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vote][sandbox] Proposal for Digester3 sandbox
On Sun, Jan 23, 2011 at 9:11 PM, Simone Tripodi wrote: > Hi Rahul!!! :) > thanks for your feedbacks!!! this time I would like to experiment in > the sandbox an almost complete rewrite of Digester, simplifying the > actual design centralizing the configuration - and loosing > retro-compatibility. Moreover I would like doing a strong code > polishing, removing deprecated APIs at first stage. > If we're losing compatibility in the core component APIs due to a major rewrite, it may be better as a new component rather than the next major release. -Rahul > The idea can, of course, be ported also on the current Digester > implementation, so once the sandbox will be completed we could apply > the new feature also on 2.X and at the same time think about a > possible 3.X. > WDYT? > Have a nice day, all the best, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sun, Jan 23, 2011 at 11:08 PM, Rahul Akolkar > wrote: >> On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi >> wrote: >>> Hi all guys, >>> I would like to propose a new sandbox to experiment a fresh, >>> different, new set of Digester APIs that strongly uses a DSL for rules >>> configuration. >>> As described in the original proposal[1], the idea comes from a James >>> Carman's comment on an old Digester issue, so his >>> help/guidance/mentoring would be more than appreciated. >>> Please cast your vote, if there are no objections I would like to >>> start this work in the sandbox and try to promote as TLP with your >>> help/mentoring/involvement. >> >> >> This would be in addition to the existing digester APIs? I think we >> want to be compatible so don't know if it makes sense to remove/change >> existing APIs. >> >> The sandbox is always open for experimentation, no objections there. >> >> -Rahul >> >> >>> I really hope this could be point of your interest that makes you >>> curious enough to participate! >>> Have a nice day, all the best, >>> Simo >>> >>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6 >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vote][sandbox] Proposal for Digester3 sandbox
On Sun, Jan 23, 2011 at 1:23 PM, Simone Tripodi wrote: > Hi all guys, > I would like to propose a new sandbox to experiment a fresh, > different, new set of Digester APIs that strongly uses a DSL for rules > configuration. > As described in the original proposal[1], the idea comes from a James > Carman's comment on an old Digester issue, so his > help/guidance/mentoring would be more than appreciated. > Please cast your vote, if there are no objections I would like to > start this work in the sandbox and try to promote as TLP with your > help/mentoring/involvement. This would be in addition to the existing digester APIs? I think we want to be compatible so don't know if it makes sense to remove/change existing APIs. The sandbox is always open for experimentation, no objections there. -Rahul > I really hope this could be point of your interest that makes you > curious enough to participate! > Have a nice day, all the best, > Simo > > [1] http://markmail.org/message/5ry2lmfkpxkrqwh6 > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Lang 2.6 based on RC2
On Thu, Jan 13, 2011 at 6:31 PM, Niall Pemberton wrote: > I have prepared a second release candidate for the release of Lang 2.6 > > Details of the bug fixes and enhancements in the release are here: > > http://people.apache.org/~niallp/lang-2.6-rc2/RELEASE-NOTES.txt > http://people.apache.org/~niallp/lang-2.6-rc2/site/changes-report.html > > [X] +1 Yes go ahead an release based on RC2 > [ ] -1 No, because... -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons Lang 2.6 based on RC1
On Tue, Jan 11, 2011 at 8:46 PM, Niall Pemberton wrote: > I would like to do a Lang 2.6 release. I have back-ported compatible > bug fixes and enhancements from the trunk to the 2.x branch, details > of which are here: > > http://people.apache.org/~niallp/lang-2.6-rc1/RELEASE-NOTES.txt > http://people.apache.org/~niallp/lang-2.6-rc1/site/changes-report.html > > [X] +1 Yes go ahead an release based on RC1 > [ ] -1 No, because... -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: SCXML : send & transition doesn't work when they are in the same state.
This is a post for the user list, but please see below first ... On Fri, Nov 26, 2010 at 1:03 PM, Michael musset wrote: > Hi, > > > I'm having a problem in my scxml project : > > > > http://www.ecma.ch/standards/ecma-323/csta";> > > > > > > > > > > the send tag is recuperate properly by the the eventdispatcher ( I need what > is inside the send tag) , but I can't manage to change state into the > STATE_1. > And If I remove the all ... tag , the transition is working, > I manage to change state into the STATE_1. > > > So what is wrong? I'm using JexlEvaluator and JexlContext for my engine. > We'll need to know what your EventDispatcher implementation is doing that might disrupt processing the original event, which is why the payload guard condition may no longer hold for the transition you expect to be taken. Lets continue on the Commons User list, see: http://commons.apache.org/mail-lists.html -Rahul > > > Thanks in advance for the help !!! > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse]Hi
On Thu, Nov 4, 2010 at 6:41 PM, Bilel Messaoud wrote: > Hi im student and i have a project to create scxml editor so i used emf and > gef now i tried to use Translators but really i was blocked can i show u my > sources and can u help me im blocked and it really stress me > thx I'm not clear on the question: If you're asking how to run the scxml-eclipse plugin from source, please see the guide here [1]. If you've made changes to the plugin source, and have questions, you may ask here but note that the lone developer of that plugin is no longer very active here. If its something else, please first try the user list instead. -Rahul [1] http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/guide/run-source-code.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons:download-page
On Thu, Nov 4, 2010 at 9:13 AM, Ralph Goers wrote: > > commons:download-page doesn't seem to work correctly with mvn release:prepare > and release:perform. If you manually invoke it before the release the files > will be for the SNAPSHOT before the release. If you run it after then they > will be for the next SNAPSHOT version. The only way to get the correct > version is to run the command and then manually edit the file before > performing the release. It probably needs to be added to the commons version > of the release plugin. > Before, using the correct value for the property: http://commons.apache.org/commons-build-plugin/download-page.html -Rahul > Ralph > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons IO 2.0 based on RC5
+1 -Rahul On Thu, Oct 14, 2010 at 10:14 PM, Niall Pemberton wrote: > I have prepared Commons IO 2.0 RC5. The main changes since RC4 was to > rename the FilesystemObserver/Monitor to > FileAlterationObserver/Monitor and improvements to the test coverage. > > The RC3 changes were improvements to some tests which were causing > intermittent failures in Gump & Continuum and JavaDoc improvements. > For details about Continuum builds/failures, see: > http://people.apache.org/~niallp/io-2.0/IOFailures.html > > The distro is here: > http://people.apache.org/~niallp/io-2.0-rc5/ > > Release Notes: > http://people.apache.org/~niallp/io-2.0-rc5/RELEASE-NOTES.txt > > Site: > http://people.apache.org/~niallp/io-2.0-rc5/site/ > > Maven Stuff: > http://people.apache.org/~niallp/io-2.0-rc5/maven/ > > Some Notes: > > * There is one error on the clirr report - which is a false positive > (a generic method that is erased) > http://people.apache.org/~niallp/io-2.0-rc4/site/clirr-report.html > * Links to the JavaDoc versions on the site don't work (they will when > its deployed to the right location) > > Thanks > > Niall > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-exec-1.1 based on RC1
On Sun, Oct 10, 2010 at 3:40 PM, Siegfried Goeschl wrote: > Hi folks, > > I would like to call a vote for releasing commons-exec-1.1 based on RC1. > > [X] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SCXML] Invoke & get data
Lets continue on the user list if needed. Response inline below.
On Wed, Sep 29, 2010 at 3:54 PM, Michael musset wrote:
> Hi,
>
> i would like to do that :
>
>
>
>
>
>
> and be able to get what's is inside the CDATA balise from this :
>
> public class protocol implements Invoker {
>
> public void invoke(String source, Map params) throws InvokerException {
>
> }
>
>
> it seems that params only works with that :
>
>
>
>
>
>
> i have already try to add content balise, but i got that :
> ATTENTION: Ignoring element in namespace
>
>
Yes, as the message indicates, is not yet implemented. If
you want, you can open a JIRA [1] enhancement to track this.
You should be able to use to similar effect as content by
defining the content in the invoke's parent state's datamodel. Along
these lines:
The value for the "content" key in the params map then will contain
the Node from which the CDATA content can be obtained.
Alternatively, you may also set datamodel variables programmatically
if that suits the application better.
-Rahul
[1] http://commons.apache.org/scxml/issue-tracking.html
>
>
> do you have an idea to get data from CDATA balise
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] next release roadmap
On Tue, Sep 28, 2010 at 11:13 AM, sebb wrote: > On 28 September 2010 15:46, Rahul Akolkar wrote: >> On Mon, Sep 27, 2010 at 12:30 PM, Simone Tripodi >> wrote: >>> Hi all guys, >>> first of all thanks everybody mentored me during the path of the 2.1 >>> release, especially Rahul and Sebastian, always ready to provide a >>> valid help, I appreciate it very much :) >>> >>> I'd like to discuss with you what I'd like to do in the next future: >>> >>> * fix the site issues: we have broken links that have to be fixed; >> >> >> Idea was to setup svn:externals on src/site/xdoc along these lines: >> >> commons-digester-2.1 >> http://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER_2_1/src/site/xdoc/ >> >> Would've been better if there was a "guide" directory so we don't pull >> in non-guide xdoc. For old releases, we have previously only >> maintained these three items rather than entire sites: Guide, Javadoc, >> Release Notes. >> > > So is the idea to rebuild the current set of guides etc. with the > current menu items? > Yes, that way the LHS site menu continues to work for older release guides as well as SVN latest guide as everything gets built into the m2 site correctly. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] next release roadmap
On Mon, Sep 27, 2010 at 12:30 PM, Simone Tripodi wrote: > Hi all guys, > first of all thanks everybody mentored me during the path of the 2.1 > release, especially Rahul and Sebastian, always ready to provide a > valid help, I appreciate it very much :) > > I'd like to discuss with you what I'd like to do in the next future: > > * fix the site issues: we have broken links that have to be fixed; Idea was to setup svn:externals on src/site/xdoc along these lines: commons-digester-2.1 http://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER_2_1/src/site/xdoc/ Would've been better if there was a "guide" directory so we don't pull in non-guide xdoc. For old releases, we have previously only maintained these three items rather than entire sites: Guide, Javadoc, Release Notes. > * auto-loading the annotations digester loader by scanning the > classpath, filtering classes with a sofisticate filtering method I > already proposed (with no success) time ago for [Lang] Could be seen as more of an applicable concern (rather than a library one). You're right that it probably should be contributed elsewhere. > * JSON support: I already did an experiment[1] that allows using the > Digester to parse JSON structures and map to beans (and it's faster > than Google-Gson :P) > [digester] started off as XML -> Java so this seems like scope creep. But its upto the current [digester] developers (you and others who may be interested in this). -Rahul > At that point I'm open to discuss with you what are your thoughts > about the last 2 points, so we can start put black on white and > prototyping code. > Many thanks in advance, have a nice day, > Simo > > [1] http://digester-annotations.googlecode.com/svn/trunk/json/ > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [infra] site deploying
On Sun, Sep 26, 2010 at 7:54 AM, sebb wrote: > On 26 September 2010 06:30, Rahul Akolkar wrote: >> On Sat, Sep 25, 2010 at 12:59 PM, Simone Tripodi >> wrote: >>> Thanks both Antonio and Phil :) >>> >>> @Phil: absolutely right, but that concerns the main site, what I was >>> worried about is the 2.1 specific release site. I already deployed the >>> 2.2 site, you can see them on http://commons.apache.org/digester/ >>> It seems everything looks good, btw if you couls send some feedback >>> after a quick review it would be much more than appreciated, thanks in >>> advance!!! >>> >> >> >> Given the way the site menu works, there are now a number of broken links. >> >> The 2.1 guide should actually be part of the deployed site so the >> menus continue to work. Now that we have a more elaborate guide (in >> terms of number of site pages), perhaps we should just pull specific >> release guides in via svn externals. > > Not sure how that would work, as the generated documention is not in SVN? > By pulling in the guide xdoc for a release from the release tag -- will try such a setup for the site when I get a chance. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [infra] site deploying
On Sat, Sep 25, 2010 at 12:59 PM, Simone Tripodi wrote: > Thanks both Antonio and Phil :) > > @Phil: absolutely right, but that concerns the main site, what I was > worried about is the 2.1 specific release site. I already deployed the > 2.2 site, you can see them on http://commons.apache.org/digester/ > It seems everything looks good, btw if you couls send some feedback > after a quick review it would be much more than appreciated, thanks in > advance!!! > Given the way the site menu works, there are now a number of broken links. The 2.1 guide should actually be part of the deployed site so the menus continue to work. Now that we have a more elaborate guide (in terms of number of site pages), perhaps we should just pull specific release guides in via svn externals. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [infra] site deploying
On Sat, Sep 25, 2010 at 10:44 AM, Phil Steitz wrote: > On 9/25/10 5:41 AM, Antonio Petrelli wrote: >> >> 2010/9/25 Simone Tripodi: >>> >>> Hi again guys, >>> sorry the Digester 2.1 release is taking too much time but I'm still >>> assembling all the puzzle's pieces :P >>> What I miss now is how the site on >>> >>> http://people.apache.org/builds/commons/digester/2.1/RC2/site/ >>> >>> has to be moved/copied/referenced on >>> >>> http://commons.apache.org/digester/commons-digester-2.1/ >> >> ssh to people.apache.org and copy from: >> /www/people.apache.org/builds/commons/digester/2.1/RC2/site/ >> to: >> /www/commons.apache.org/digester/commons-digester-2.1/ >> > > No. In Commons, the deployed site should be versioned 2.2-SNAPSHOT. > Right, cp -r of the staged site won't work very well here. -Rahul > It is confusing and IMO unnecessary for us to include the site in the RC, > since it is not actually part of the release, but we have traditionally done > that. > > See the post-release steps (5 - 7) here: > http://commons.apache.org/releases/release.html > > First, update the POM to 2.2-SNAPSHOT. Do the other stuff. Generate the > site locally using mvn site and then deploy it using mvn site:deploy > > The latter can be used at any time to deploy the updated web site. > > Phil > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse] creating modeling diagram wih SCXML
2010/9/22 Xun Long Gui : > Sorry, i can not open the following url in China > It contains these reminders: * Please don't forget to use email subject prefixes (such as [scxml-eclipse] here) * Usage questions and/or responses should go to user list * Best to ask poster to resend email to mailing list themselves (rather than adding the list as CC in reply) -Rahul > 2010/9/23 Rahul Akolkar >> >> 2010/9/22 Xun Long Gui : >> > Ok, i will go to check it >> > >> >> >> Long - Again, please see: >> >> http://markmail.org/message/5y6sy6kjbcdwnaoa >> >> -Rahul > > > > -- > Best Regards > > Gui Xun Long (桂训龙) > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse] creating modeling diagram wih SCXML
2010/9/22 Xun Long Gui : > Ok, i will go to check it > Long - Again, please see: http://markmail.org/message/5y6sy6kjbcdwnaoa -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Digester 2.1 based on RC2
On Sun, Sep 19, 2010 at 4:55 AM, Simone Tripodi wrote: > Hi all guys, > on behalf of the Digester committers I'd like to invite you to vote > the 2.1 release of the commons-digester, based on the RC2 > > - > > [X] +1 release it > [ ] +0 OK, but... > [ ] -0 Would really like to see... > [ ] -1 no, do not release it because... > > - -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Version classes
On Wed, Sep 15, 2010 at 8:57 AM, Torsten Curdt wrote:
> IMO the thread showed that there are enough ways to get to that
> information today.
> I would not bother and call for the vote.
>
+1 to not bothering for digester 2.1.
-Rahul
> On Wed, Sep 15, 2010 at 14:54, Simone Tripodi
> wrote:
>> I'm going to call a vote for a new Digester release, shall this new
>> stuff be included in the release?
>> thanks in advance,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Sep 15, 2010 at 2:41 PM, Jochen Wiedmann
>> wrote:
James Carman wrote:
>>>
We use a method like this:
public static String versionOf(Class c) {
final String version = c.getPackage().getImplementationVersion();
return StringUtils.isEmpty(version) ? "n/a" : version;
}
So, if you want to know what version of Hibernate you're using, you'd do:
versionOf(org.hibernate.Session.class);
>>>
>>> Implementation note: getPackage() must be checked against null.
>>>
>>> Jochen
>>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse] creating modeling diagram
2010/9/12 Xun Long Gui : > Welcome for your feedback, it will help us to improve this project > Suggestions: * Please use email subject prefixes (I've added one here) * Usage questions and/or responses should go to user list * Ask poster to resend to mailing list themselves -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Digester 2.1 based on RC1
On Sat, Sep 11, 2010 at 6:43 AM, Simone Tripodi wrote: > > Release notes: > > http://people.apache.org/builds/commons/digester/2.1/RC1/RELEASE-NOTES.txt > Since readability is important for release notes, I'll nitpick: * Line width is inconsistent * s/meta data-based/meta-data based/ * s/run-time/runtime/ * s/This is the first Digester release oriented to be built by Apache Maven only./This is the first Digester release that provides an Apache Maven 2 build only. The Apache Maven 1 and Apache Ant builds have been removed./ > Site: > > http://people.apache.org/builds/commons/digester/2.1/RC1/site/index.html > We should advertise the new annotations stuff more. I suggest: * Adding a fourth bullet (or better, a separate para) mentioning the annotations work in the "The Digester Component" section on top of the home page * Mention in a sentence that 2.1 adds annotations support in "Releases" section of home page The Javadoc (SVN latest) link may need a leading slash in the site.xml. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Digester 2.1 based on RC1
On Sun, Sep 12, 2010 at 11:33 AM, Simone Tripodi wrote: > Thanks a lot for the clarifications Rahul!!! :) I'd also add its best to wait a few days (3+) before rolling the next RC to allow time for any additional feedback. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Digester 2.1 based on RC1
On Sun, Sep 12, 2010 at 7:20 AM, sebb wrote: > On 12 September 2010 08:09, Simone Tripodi wrote: >> Hi Seb, >> thanks for the feedbacks, my fault: I misunderstood the tag creation, >> I manually forced the -RCn postfix :( So now 2 questions to increase >> my knowledge: >> >> 1) shall the /DIGESTER_2_1_RC1/ tag be deleted? I'd say 'yes' but >> waiting for your confirmation. > > If it no longer has any use, it can be deleted. > > In this case the tag was used for a vote, so I'd leave deletion until > after the release process completes. > The tag may be useful for comparison purposes. > Yes, there is no rush to delete. I tend to leave all RC tags in SVN (as you can tell by looking at the tags directory). >> 2) if an RCn fails, when releasing an RCn+1, the tag dir has o be >> deleted and recreated, right? > > Ideally tags are a fixed version and are never recreated. > Indeed. > So I would create the new tag, and later delete the old tag. > Caveat being retain the tag for the successful RC since you're using the release plugin (for bits). -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Digester 2.1 based on RC1
On Sat, Sep 11, 2010 at 11:20 AM, sebb wrote:
> On 11 September 2010 11:43, Simone Tripodi wrote:
>> Hi all guys,
>> on behalf of the Digester committers I'd like to invite you to vote
>> the 2.1 release of the commons-digester.
>>
>> Tag:
>>
>> https://svn.apache.org/repos/asf/commons/proper/digester/tags/DIGESTER_2_1_RC1/
>>
>> Release notes:
>>
>> http://people.apache.org/builds/commons/digester/2.1/RC1/RELEASE-NOTES.txt
>>
>> Site:
>>
>> http://people.apache.org/builds/commons/digester/2.1/RC1/site/index.html
>
> Fixed a minor typo - missing "(" - not a blocker.
>
>> Binaries:
>>
>> http://people.apache.org/builds/commons/digester/2.1/RC1/staged/commons-digester/commons-digester/2.1-RC1/
>
> SIgniing key is listed in public databases, but does not appear to be in:
>
> https://svn.apache.org/repos/asf/commons/trunks-proper/KEYS
>
> This needs to be updated as per the instructions contained in it.
>
> The entries in pom.xml refer to /tags/DIGESTER_2_1_RC1.
> However, if the vote succeeds, the tag should be renamed to remove the
> _RC1 suffix - and the scm entries will then be invalid.
>
For this, I leave the successful RC tag and the final tag around. IMO
thats good enough.
> There are similar problems with the Specification-Version: and
> Implementation-Version: in the MANIFEST files.
>
> Also, the directory names include RC1.
>
> Given that the RC version is defined here:
>
> RC1
>
> perhaps
>
> 2.1-RC1
>
> should be
>
> 2.1
>
> Not sure if this works with the Maven release plugin.
>
Here is what I do with the release plugin (using soon to come RC2 as example):
* When prompted for the version, use 2.1
* When prompted for the tag, use DIGESTER_2_1_RC2
Voting on the exact bits leads to the first bullet, that this isn't
the actual release until it passes muster leads to the second.
is updated manually before each RC.
-Rahul
> The .asc.md5 and .asc.sha1 files ought to be deleted before files are
> released to Maven Central. Just delete them from the staging area.
>
> Sorry, but IMO this warrants -1 because of the RCn version problems.
>
>> Votes, please. This vote will close in 72 hours (14 Sept, 11:00am GMT).
>>
>> Thanks in advance.
>> Simo
>>
>> -
>>
>> [ ] +1 release it
>> [ ] +0 OK, but...
>> [ ] -0 Would really like to see...
>> [ ] -1 no, do not release it because...
>>
>> -
>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] RC1 blocked while deploying :(
On Fri, Sep 10, 2010 at 6:27 PM, Simone Tripodi
wrote:
> Hi all guys,
> the RC1 is driving me crazy... once resolved the gpg issues, following
> the wiki guide[1] Rahul ans Seb suggested, once launched "mvn -Prc
> release:perform" when going to deploy artifacts, the build was
> blocked:
>
> [INFO] [INFO] [deploy:deploy {execution: default-deploy}]
> [INFO]
> [INFO]
> [INFO] Note that too many successive login failures will result in further
> [INFO] logins from your IP address being blocked. If this happens, contact
> [INFO] , mentioning your IP address so that it can
> [INFO] be unblocked.
> [INFO]
> [INFO]
>
> Even if I try to insert my apache password, nothing happens, the
> process seems to be suspended... any idea/hints on it?
You'd get the above on auth success to people, so shouldn't need to
enter password then (I use an ssh agent). I usually get a progress
indicator on the uploads after that.
-Rahul
> Many thanks in advance,
> Simo
>
> [1] http://wiki.apache.org/commons/CreatingReleases
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Fri, Sep 10, 2010 at 11:53 AM, sebb wrote: > On 10 September 2010 08:30, Simone Tripodi wrote: >> Hi Seb, >> thanks for your feedbacks. The problem I have is that even if I omit >> the password waiting for the prompt, once the builds arrives ad the >> gpg:sign execution, it is completely blocked :( >> I'm using gpg 1.4.9, shall I have to upgrade to 2? > If your questions are purely related to Maven or its plugins, you may have better luck (and response time) on the Maven list. -Rahul > Current is 1.4.10. > > Gpg2 behaves very differently for passwords - it uses a background > process that caches the password for a while. > > Unfortunately, gpg2 does not play well with secret keys on a USB > stick, see: http://jira.codehaus.org/browse/MGPG-30 > > For testing purposes, I created a dummy key and added both keyname and > password as a profile in my local settings file. It's then easy to use > the test-deploy profile to check that the correct items are created > and signed. > > For example, I just tried: > > mvn -Prc deploy -Ptest-deploy -PkeyTest > > and it created and signed the Maven and non-Maven artifacts OK. >> Many thanks in advance, have a nice day, >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Thu, Sep 9, 2010 at 9:10 PM, sebb wrote: >>> On 9 September 2010 19:54, Simone Tripodi wrote: >>>> Hi all guys, >>>> I'm trying to push an RC release, but the gpg plugin execution is >>>> blocked when signing arifacts :( Follow below my attempts: >>>> >>>> mvn release:prepare -DdryRun=true -Darguments=-Dgpg.keyname=\ >>>> -Dgpg.passphrase= >>>> mvn release:prepare -DdryRun=true -Dgpg.passphrase= (the keyname >>>> is defined as preferred in the gpg.conf) >>>> mvn release:prepare -DdryRun=true (tried to insert gpg.passphrase in the >>>> prompt) >>>> >>>> Do you have any idea why? Many thanks in advance, >>>> Simo >>> >>> I use a profile in my settings.xml which defines the keyname, so I >>> don't have to remember the hex string. >>> One can also define gpg.homedir and gpg.executable (if required) >>> >>> The password you can omit - it should be prompted for, but how depends >>> on whether you are using gpg1 or gpg2. >>> >>> For testing gpg signing, you can use the new "test-deploy" profile. >>> >>> Don't you need to use mvn deploy ? >>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Mon, Sep 6, 2010 at 10:03 PM, Simone Tripodi >>>> wrote: >>>>> Hi Rahul, >>>>> don't worry I won't publish the site before the release; about the >>>>> Menu reorganization I like the b) too, it is much more coherent with >>>>> previous releases. >>>>> Thanks a lot, have a nice day, >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> On Mon, Sep 6, 2010 at 6:23 PM, Rahul Akolkar >>>>> wrote: >>>>>> On Mon, Sep 6, 2010 at 9:49 AM, Simone Tripodi >>>>>> wrote: >>>>>>> Hi all, Rahul, >>>>>>> what about the latest deployed website? >>>>>> >>>>>> >>>>>> Looks good overall, though I haven't taken a fine-toothed comb to it. >>>>>> >>>>>> >>>>>>> Can I proceed modifying the >>>>>>> homepage in order to propose a release? >>>>>> >>>>>> >>>>>> Sure, but please don't deploy it after those changes until the release >>>>>> is done. Before posting the vote, the site is previewed w/ the rc >>>>>> profile (-Prc) in the site-deploy command -- this will deploy the site >>>>>> to the pao/commons/builds area where the other artifacts for the vote >>>>>> will get posted as well. >>>>>> >>>>>> WRT the new additions to the LHS menu, currently we have (indentation >>>>>> implies nesting): >>>>>> >>>>>> Developers Guide (SVN latest) >>>>>> Core APIs >>>>>&g
Re: [Digester] working toward a release
On Mon, Sep 6, 2010 at 9:49 AM, Simone Tripodi wrote:
> Hi all, Rahul,
> what about the latest deployed website?
Looks good overall, though I haven't taken a fine-toothed comb to it.
> Can I proceed modifying the
> homepage in order to propose a release?
Sure, but please don't deploy it after those changes until the release
is done. Before posting the vote, the site is previewed w/ the rc
profile (-Prc) in the site-deploy command -- this will deploy the site
to the pao/commons/builds area where the other artifacts for the vote
will get posted as well.
WRT the new additions to the LHS menu, currently we have (indentation
implies nesting):
Developers Guide (SVN latest)
Core APIs
Plugins
Substitution
XML Rules
Annotations
FAQ
I see two options for the 2.1 release:
(a) Use the above (but change SVN latest to 2.1)
(b) Use the following:
Release 2.1 (Current)
Guide
Core APIs
Plugins
Substitution
XML Rules
Annotations
FAQ
Javadoc
Release Notes
Release 2.0
... (current content for 2.0 menu)
I think (b) will work better as it aligns with menu for previous
releases -- note the FAQ indentation in (b) BTW as its different --
WDYT?
-Rahul
> Thanks in advance, all the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Sun, Sep 5, 2010 at 12:46 AM, Rahul Akolkar
> wrote:
>> On Sat, Sep 4, 2010 at 3:11 PM, Simone Tripodi
>> wrote:
>>> Hi Rahul,
>>> thanks a lot for your feedbacks, actions have been completed following
>>> your suggestions.
>>> my final 2 questions:
>>> - I didn't find any reference on wiki about
>>> ${commons.deployment.protocol}... can we have a private chat?
>>
>>
>> Sure, though it helps to have things in the list archives for the next
>> person in line, so the responses are best when archived :-)
>>
>> The deployment protocol bit is for wagon and defaults to scp (see
>> parent pom). If you want to use some other (for example, scpexe with
>> PuTTY), then it can be changed via an active profile in
>> ~/.m2/settings.xml. If you've used the m2 release plugin before, you
>> probably don't need to do anything new for Commons.
>>
>>
>>> - Is it the case to migrate the group id to org.apache.commons?
>>
>>
>> No, not for 2.1 (archives have this topic at length).
>>
>> -Rahul
>>
>>
>>> Many thanks in advance, namaste
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] NPE when generating JIRA report
On Sun, Sep 5, 2010 at 10:54 AM, Simone Tripodi wrote: > DONE!!! > the scp has been successfully completed :) > Now waiting to see the update site online :P If you set the browser proxy server to minotaur-2.apache.org [140.211.11.10], you won't have to wait. Which is what I did, and its good to see the new xdoc guide (rather than package.html content) -- I'd say its a lot more consumable now. Cheers, -Rahul > Namaste, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Apachecon US slot open
On Sun, Sep 5, 2010 at 10:46 AM, Phil Steitz wrote: > One of our speaker volunteers has had to cancel, so we have a speaker slot > open in the Commons track. The conference is in Atlanta, November 1-5 and > the Commons track is on Thursday, the 4th. > > Any volunteers? > Too bad I'm away for the W3C TPAC that week (would've liked to be there). -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] NPE when generating JIRA report
On Sun, Sep 5, 2010 at 10:39 AM, Simone Tripodi wrote: > Hi Rahul, > sure, but I'd suggest to add the 2.1 and remove the 1.8 not at this > stage, that we're just publishing the snapshot site. WDYT? Yes, indeed, thats what I meant (post release). Please go ahead with mvn site-deploy :-) -Rahul > Thanks in advance, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sun, Sep 5, 2010 at 4:31 PM, Rahul Akolkar wrote: >> On Sun, Sep 5, 2010 at 10:25 AM, Simone Tripodi >> wrote: >>> Hi Rahul, >>> thanks, just tried with the 2.3 version and it worked!!! Now trying >>> the assemblies and other plugins... >>> In the meanwhile, do you think I can run mvn site-deploy to publish >>> the current site? >> >> >> Yes, that'd be good as a preview before the release. >> >> We should remove the 1.8 release from the LHS menu (so post release, >> we'd have 1.8.1, 2.0 and 2.1 there). >> >> -Rahul >> >> >>> Thanks in advance, >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Sun, Sep 5, 2010 at 4:14 PM, Rahul Akolkar >>> wrote: >>>> On Sun, Sep 5, 2010 at 6:18 AM, Simone Tripodi >>>> wrote: >>>>> Hi all guys, >>>>> while attempting to run the mvn site-deploy command I got an NPE when >>>>> generating the JIRA report; even if not blocking I stopped the >>>>> execution, can anyone please suggest me how to fix it? >>>>> Follows below the stacktace, thanks in advance!!! >>>> >>>> >>>> Searched and found MCHANGES-126 [1]. Bumped plugin to latest version >>>> 2.3 in r992789 [2]. Site builds for me now. >>>> >>>> It'd be good to check if all plugins are using the best version >>>> possible before release. >>>> >>>> -Rahul >>>> >>>> [1] http://jira.codehaus.org/browse/MCHANGES-126 >>>> [2] http://svn.apache.org/viewvc?view=revision&revision=992789 >>>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] NPE when generating JIRA report
On Sun, Sep 5, 2010 at 10:25 AM, Simone Tripodi wrote: > Hi Rahul, > thanks, just tried with the 2.3 version and it worked!!! Now trying > the assemblies and other plugins... > In the meanwhile, do you think I can run mvn site-deploy to publish > the current site? Yes, that'd be good as a preview before the release. We should remove the 1.8 release from the LHS menu (so post release, we'd have 1.8.1, 2.0 and 2.1 there). -Rahul > Thanks in advance, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sun, Sep 5, 2010 at 4:14 PM, Rahul Akolkar wrote: >> On Sun, Sep 5, 2010 at 6:18 AM, Simone Tripodi >> wrote: >>> Hi all guys, >>> while attempting to run the mvn site-deploy command I got an NPE when >>> generating the JIRA report; even if not blocking I stopped the >>> execution, can anyone please suggest me how to fix it? >>> Follows below the stacktace, thanks in advance!!! >> >> >> Searched and found MCHANGES-126 [1]. Bumped plugin to latest version >> 2.3 in r992789 [2]. Site builds for me now. >> >> It'd be good to check if all plugins are using the best version >> possible before release. >> >> -Rahul >> >> [1] http://jira.codehaus.org/browse/MCHANGES-126 >> [2] http://svn.apache.org/viewvc?view=revision&revision=992789 >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [scxml-eclipse] User Feedback
2010/9/5 Xun Long Gui : > Yeah, I will add this part, but i think it will take me a while, i will > graduate this winter, these days, i was working for my graduate pater, so > may be you should wait for a while, sorry for that :-( > The other option always available would be for someone else to jump in and make the necessary changes. I may not have time soon for this, but Jake or Chris if you want to take a look, feel free to have at it. Starting point to get going is probably this page [1]. -Rahul [1] http://commons.apache.org/sandbox/gsoc/2010/scxml-eclipse/guide/run-source-code.html > 2010/9/5 Jacob Beard > >> Hi Long, >> >> I just wanted to follow up quickly and find out the current status on the >> issues that were raised here. Specifically, is it possible to add >> executable >> content to transitions in scxml-eclipse? >> >> Please let me know. Thanks, >> >> Jake >> >> 2010/8/8 Jacob Beard >> >> > Hi Long, >> > >> > I should mention that I had missed this part of the specification as >> > well, and I only recently discovered it while trying to determine how >> > best to express static reactions with SCXML. I'm currently updating >> > scxml-js to support this. >> > >> > Jake >> > >> > On 10-08-08 10:12 PM, Xun Long Gui wrote: >> > > Hi Jake, >> > > Thanks for your reply. It seems that we should re-define transition EMF >> > data >> > > model for this tool, rebuild the tool from the base. I will read SCXML >> > > transition specification carefully and carry on the rebuild job >> > > >> > > 在 2010年8月9日 上午9:22，Jacob Beard 写道： >> > > >> > > >> > >> Hi, Long, >> > >> >> > >> Replies below: >> > >> >> > >> On 10-08-08 09:06 PM, Xun Long Gui wrote: >> > >> >> > >>> I do not think we can create a transition without a target, target is >> a >> > >>> necessary element for a transition. >> > >>> >> > >>> >> > >> The spec says that the target attribute on transition is not required. >> > >> In that case, I think the semantics are similar to a Static Reaction, >> as >> > >> defined in the paper describing the Rhapsody semantics of statecharts. >> > >> From the spec: >> > >> >> > >> The identifier(s) of the state or parallel region to transition to. If >> > >> it is omitted, the transition will not cause a change in the state >> > >> configuration when it is executed. The executable content contained in >> > >> the transition will still be executed, so the transition will function >> > >> as a simple event handler. If the target is present and equal to the >> > >> state containing the transition element, the transition will cause the >> > >> state machine to leave and then re-enter this state. >> > >> >> > >> From: http://www.w3.org/TR/scxml/#transition >> > >> >> > >>> To feature 1 and 3 in Chris's commends, we can achieve them, not a >> big >> > >>> thing. What do you mean about "showstoppers" bug ? >> > >>> >> > >>> >> > >> What I mean is that I think these things are critical to usability. >> > >> >> > >> Jake >> > >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] NPE when generating JIRA report
On Sun, Sep 5, 2010 at 6:18 AM, Simone Tripodi wrote: > Hi all guys, > while attempting to run the mvn site-deploy command I got an NPE when > generating the JIRA report; even if not blocking I stopped the > execution, can anyone please suggest me how to fix it? > Follows below the stacktace, thanks in advance!!! Searched and found MCHANGES-126 [1]. Bumped plugin to latest version 2.3 in r992789 [2]. Site builds for me now. It'd be good to check if all plugins are using the best version possible before release. -Rahul [1] http://jira.codehaus.org/browse/MCHANGES-126 [2] http://svn.apache.org/viewvc?view=revision&revision=992789 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Sat, Sep 4, 2010 at 3:11 PM, Simone Tripodi wrote:
> Hi Rahul,
> thanks a lot for your feedbacks, actions have been completed following
> your suggestions.
> my final 2 questions:
> - I didn't find any reference on wiki about
> ${commons.deployment.protocol}... can we have a private chat?
Sure, though it helps to have things in the list archives for the next
person in line, so the responses are best when archived :-)
The deployment protocol bit is for wagon and defaults to scp (see
parent pom). If you want to use some other (for example, scpexe with
PuTTY), then it can be changed via an active profile in
~/.m2/settings.xml. If you've used the m2 release plugin before, you
probably don't need to do anything new for Commons.
> - Is it the case to migrate the group id to org.apache.commons?
No, not for 2.1 (archives have this topic at length).
-Rahul
> Many thanks in advance, namaste
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: XML Schema and Java 1.5
Wrong list. On Sat, Sep 4, 2010 at 7:32 AM, Benson Margulies wrote: > I'm tired of Java 1.4. Are there users of XML Schema still stuck there? > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Fri, Sep 3, 2010 at 3:34 PM, Simone Tripodi wrote: > Sorry, > forgot to ask your opinion on dropping the STATUS.html[1] file that > seems has not been updated anymore since 1.7 release... WDYT? Yup, lets scrap that. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Fri, Sep 3, 2010 at 3:32 PM, Simone Tripodi wrote: > Hi again Rahul, all, > just to ask opinions about other details: I'd move the checkstyle > stuff (checkstyle.xml and file-header.txt), on the project root, to a > proper src/test/checkstyle dir to keep the root dir as much clean as > possible, removing verification tools configuration and keep metadata > build only. WDYT? If we are going to move those, perhaps src/main/config is a better location (and thats what some other Commons components that don't have those files at project root use). -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Fri, Sep 3, 2010 at 10:54 AM, Simone Tripodi wrote: > Hi Rahul, > thanks a lot!!! I just need to fix the svn cp we discussed in the > other thread, write the release notes and I'll be ready to calla a > vote. Two suggestions: * Digester release notes have been written by hand (rather than generating them as mentioned on the wiki) -- look to prior releases for examples. * I'd deploy the latest site here [1] (mvn site-deploy) first and wait for feedback given there have been a number of site changes. That way you won't have to spin another RC to fix any site tweaks. -Rahul [1] http://commons.apache.org/digester/ > I'll use the m2 rc profile, I'm already used to do it with the release > plugin and found it comfortable. > Have a nice day,m > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Fri, Sep 3, 2010 at 3:14 PM, Rahul Akolkar wrote: >> On Fri, Sep 3, 2010 at 1:40 AM, Simone Tripodi >> wrote: >>> Hi Rahul, >>> thanks for your feedbacks!!! :) >>> At that point I'd try to call a vote for a new release, WDYT? Can you >>> point me please at some wiki page where described the release >>> procedure? >> >> >> Depends who is cutting the release. We have atleast three flavors: >> >> * Use Nexus [1] >> * Use the m2 rc profile [2] >> * A manual scp of artifacts to people >> >> I use the rc profile which effectively amounts to doing this once the >> prep is done, to post the RC: >> >> mvn -Prc release:prepare >> mvn -Prc release:perform >> mvn -Prc site-deploy >> >> You can read [2] for all the details. >> >> -Rahul >> >> [1] http://wiki.apache.org/commons/UsingNexus >> [2] http://wiki.apache.org/commons/CreatingReleases >> >> >> >>> Many thanks in advance, have a nice day! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Fri, Sep 3, 2010 at 1:40 AM, Simone Tripodi wrote: > Hi Rahul, > thanks for your feedbacks!!! :) > At that point I'd try to call a vote for a new release, WDYT? Can you > point me please at some wiki page where described the release > procedure? Depends who is cutting the release. We have atleast three flavors: * Use Nexus [1] * Use the m2 rc profile [2] * A manual scp of artifacts to people I use the rc profile which effectively amounts to doing this once the prep is done, to post the RC: mvn -Prc release:prepare mvn -Prc release:perform mvn -Prc site-deploy You can read [2] for all the details. -Rahul [1] http://wiki.apache.org/commons/UsingNexus [2] http://wiki.apache.org/commons/CreatingReleases > Many thanks in advance, have a nice day! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Digester] working toward a release
On Thu, Sep 2, 2010 at 4:54 PM, Simone Tripodi wrote: > Hi again, > I've been fixing PMD-CPD-Checkstyle errors, by now PMD warnings could > be considered trivial since they're detected on Deprecated > methods/constructor, there is a CPD warning I'd like to fix: > > File Line > org/apache/commons/digester/SetNextRule.java 198 > org/apache/commons/digester/SetRootRule.java 191 > > SetNextRule[1] class looks like to SetRootRule[2], what do you think > about adding an abstract class that generalizes the behavior of both > classes? We can leave those as-is, thats not a newly flagged CPD output. In theory, an abstract class where the method may be called on the root, (top -1) or any stack index in between seems the generic base class functionality. However, in practice, root and (top - 1) are most common and the duplication we see isn't too bad or new either. -Rahul > Thanks in advance, have a nice day!!! > Simo > > [1] > https://svn.apache.org/repos/asf/commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/SetNextRule.java > [2] > https://svn.apache.org/repos/asf/commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/SetRootRule.java > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [digester] svn commit: r991743
On Thu, Sep 2, 2010 at 2:03 PM, Simone Tripodi wrote: > Gosh, apologizes :( > do we have any chance to retrieve it from an older revision then move? One could: * svn rm this one (without history). * svn cp in a pegged version into a working copy -- 991691 seems to be where the rest came from (so 'svn cp https://svn.apache.org/old/p...@991691 .'), then review and ci. I usually create a patch before svn ci during such reorgs, examining a patch beforehand helps to catch any such glitches (easier than fixing later). -Rahul > Thanks in advance, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Thu, Sep 2, 2010 at 7:03 PM, Rahul Akolkar wrote: >> On Wed, Sep 1, 2010 at 6:44 PM, wrote: >>> Author: simonetripodi >>> Date: Wed Sep 1 22:44:15 2010 >>> New Revision: 991743 >>> >>> URL: http://svn.apache.org/viewvc?rev=991743&view=rev >>> Log: >>> moved main src to the default maven archetype dir structure >>> >>> Added: >>> commons/proper/digester/trunk/src/main/ >>> commons/proper/digester/trunk/src/main/java/ >>> commons/proper/digester/trunk/src/main/java/org/ >>> - copied from r991631, commons/proper/digester/trunk/src/java/org/ >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/handlers/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/handlers/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/internal/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/internal/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/providers/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/providers/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/reflect/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/reflect/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/rules/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/rules/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/spi/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/spi/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/utils/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/utils/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/parser/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/parser/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/plugins/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/plugins/package-info.java >>> >>> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/plugins/strategies/package-info.java >>> - copied unchanged from r991691, >>> commons/proper/digester/trunk/src/java/org/apache/commons/digester/plugins/strategies/package-info.java >>>
Re: [digester] svn commit: r991743
On Wed, Sep 1, 2010 at 6:44 PM, wrote: > Author: simonetripodi > Date: Wed Sep 1 22:44:15 2010 > New Revision: 991743 > > URL: http://svn.apache.org/viewvc?rev=991743&view=rev > Log: > moved main src to the default maven archetype dir structure > > Added: > commons/proper/digester/trunk/src/main/ > commons/proper/digester/trunk/src/main/java/ > commons/proper/digester/trunk/src/main/java/org/ > - copied from r991631, commons/proper/digester/trunk/src/java/org/ > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/handlers/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/handlers/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/internal/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/internal/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/providers/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/providers/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/reflect/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/reflect/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/rules/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/rules/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/spi/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/spi/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/annotations/utils/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/annotations/utils/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/parser/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/parser/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/plugins/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/plugins/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/plugins/strategies/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/plugins/strategies/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/substitution/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/substitution/package-info.java > > commons/proper/digester/trunk/src/main/java/org/apache/commons/digester/xmlrules/package-info.java > - copied unchanged from r991691, > commons/proper/digester/trunk/src/java/org/apache/commons/digester/xmlrules/package-info.java > commons/proper/digester/trunk/src/main/resources/ > commons/proper/digester/trunk/src/main/resources/org/ > commons/proper/digester/trunk/src/main/resources/org/apache/ > commons/proper/digester/trunk/src/main/resources/org/apache/commons/ > > commons/proper/digester/trunk/src/main/resources/org/apache/commons/digester/ > > commons/proper/digester/trunk/src/main/resources/org/apache/commons/digester/xmlrules/ > > commons/proper/digester/trunk/src/main/resources/org/apache/commons/digester/xmlrules/digester-rules.dtd > (with props) Looks like the above file wasn't svn moved in the process (we seem to have lost the history on the above dtd). -Rahul > commons/proper/digester/trunk/src/main/resources/overview.html > - copied unchanged from r991711, > commons/proper/digester/trunk/src/java/overview.html > Removed: > commons/proper/digester/trunk/src/java/org/ > commons/proper/digester/tr
Re: [Digester] working toward a release
On Thu, Sep 2, 2010 at 1:54 AM, Simone Tripodi wrote: > Hi all, > just to give you a brief recap of the completed actions: > - tests have been migrated to JUnit 4; > - project structure has been moved to default Maven archetype structure; > - ant build & config have been removed; > - whole documentation has been moved to site, in the xdoc format. > Great :-) > There still is the 'examples' dir that's using ant to build the small > subprojects, what do you think on moving them too to a maven build? I don't think thats a requirement for the next release. I also don't think we want to introduce a multi-module m2 build for digester, so best to keep that build on its own (even if moved to m2) as it is now. In effect -- if someone wants to do it, sure. -Rahul > Thanks in advance, have a nice day :) > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Sep 1, 2010 at 2:27 PM, Simone Tripodi > wrote: >> Unfortunately they are just components mocks used in proper unit >> tests, they don't contain test methods, so 1) should be the better >> solution. >> Thanks Seb! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Wed, Sep 1, 2010 at 12:50 PM, sebb wrote: >>> On 1 September 2010 09:24, Simone Tripodi wrote: >>>> Hi guys, >>>> migrating to Junit4 I met a small issue that can be easily resolved in >>>> more that 1 way, I'd like to discuss with you how we want doing it: >>>> >>>> Tests in error: >>>> initializationError(org.apache.commons.digester.xmlrules.TestDigesterRulesSource) >>>> initializationError(org.apache.commons.digester.plugins.TestObject) >>>> initializationError(org.apache.commons.digester.TestObjectCreationFactory) >>>> initializationError(org.apache.commons.digester.xmlrules.TestObject) >>>> >>>> These classes are not unit test at all but rather classes to support >>>> tests, but because of the name pattern, surefire tries to execute them >>>> as unit test, but Junit4 fails because no test methods are present in >>>> these classes. >>>> >>>> AFAIK we can fix it in 2 ways: >>>> >>>> 1) renaming all the class name; >>>> 2) adding fake test methods >>>> >>>> I'm for 1, what do you suggest to proceed? >>> >>> Or one can: >>> >>> 3) Add exclusions to the POM. >>> - just added for completeness, as I prefer 1) >>> >>> However, if there is a useful test that can be added to a support >>> class, then 2) is the way to go. >>> >>>> Thanks in advance, best regards! >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>> >>>> >>>> >>>> On Wed, Sep 1, 2010 at 7:38 AM, Simone Tripodi >>>> wrote: >>>>> Thanks a lot guys, >>>>> now the scope is much more clear to me. I'll proceed according to what >>>>> we agreed. >>>>> Have a nice day!!! >>>>> Simo >>>>> >>>>> http://people.apache.org/~simonetripodi/ >>>>> http://www.99soft.org/ >>>>> >>>>> >>>>> >>>>> On Wed, Sep 1, 2010 at 12:22 AM, sebb wrote: >>>>>> On 31 August 2010 22:54, Rahul Akolkar wrote: >>>>>>> On Tue, Aug 31, 2010 at 2:45 PM, Simone Tripodi >>>>>>> wrote: >>>>>>>> Hi guys, >>>>>>>> one more question: what about keeping or removing the Test >>>>>>>> classes/methods that just declare the Suite? AFAIK are not more >>>>>>>> needed... >>>>>>> >>>>>>> >>>>>>> Don't have a strong opinion -- if someone wants to do it. >>>>>> >>>>>> Forgot to say I'm +1 on removing these. >>>>>> >>>>>> Just need to be careful in case there is a suite which is used to >>>>>> ensure that certain tests are run in a particular order. >>>>>> >>>>>> Otherwise, the main() and suite() methods are unnecessary, and it's >>>>>> too easy to add a test class and forget to add the class to the suite. >>>>>> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
