I have created the label version "OFBIZ 9.3" and scheduled on that all mentioned issues. Using the prefix "OFBIZ" we could distinguish it from the framework only releases that we should decide how to identify.
For a better use of the roadmap panel: https://issues.apache.org/jira/browse/OFBIZ?report=com.atlassian.jira.plugin.system.project:roadmap-panel it may be the case of removing the release SVN trunk because it lists too many issues on it and the page is really huge. Could we assume that NO VERSION specified means SVN Trunk ? Please schedule any other issue you think should be included in the 9.3 release using the "Fix version" field. Thank you, -Bruno 2009/1/16 Jacques Le Roux <[email protected]> > For security we should better refer to > https://issues.apache.org/jira/browse/OFBIZ-1525 where all is centralized > I will also finish and commit > https://issues.apache.org/jira/browse/OFBIZ-1923 soon > > Jacques > > > From: "David E Jones" <[email protected]> > >> >> What do we still have that is up in the air for refactoring, cleanups, >> and enhancements? I know quite a few have been worked on recently but I'm >> not sure of their exact status, but here are some that come to mind: >> >> 1. UI label cleanups: Marco/Jacques, mostly done except for a couple of >> specialpurpose components? >> 2. Double -> BigDecimal: Scott/David, good chunk done but not the whole >> project yet >> 3. simple-method, widget attribute consistency: David/Jacques, all XSDs >> and Java updated, still a few app files that need cleaning up but the >> framework is mostly done >> 4. portal framework and my portal: Bruno/Hans, this seems to be pretty >> far along but some refinement and decisions about how to work with >> framework versus apps needs to be done including the possibility of having >> a MyPortal webapp that is part of the framework and that applications, >> specialpurpose, and hot-deploy components can make portlets available for, >> plus pre-build portlet sets by role too, so that end-users can pick and >> choose based on what is deployed with inherent support in the framework (by >> the way, I think this is cool, it is kind of like a new framework feature >> with a common tool applications can use, kind of like many of the nicer OS >> X features where there is a clear line between the OS and apps but the OS >> provides many things to allow a consistent user experience between >> multiples apps, etc) >> 5. visual themes in manager apps and ecommerce: Bruno/Adrian/others, >> pretty far along, basics done yet? this is another cool feature and I like >> the UI enhancement experiments that are starting to go along with this and >> will hopefully lead is do a very nice default theme at some point in the >> near future >> >> Other things? I know I must be missing a few... >> >> On a side note, below is a running wish list I've been keeping and slowly >> working on for the last year or so. We don't need to wait for these for a >> framework release, and most of the ones related to cleanups are complete >> now and so off the list (GenericDelegator stuff, simple-method/widget >> stuff, etc). Just some food for thought that I suppose is on this topic. >> Still, these are just ideas and things I'd like to work on (because I'd >> like to have them for use in day-to-day work or I think they are important >> in some way) and without actual work going on they are fairly meaningless >> (ideas are cheap and easy to come by, actualization of them is not). >> >> That said... we may want to work on some security issues before another >> release branch... >> >> -David >> >> ========================================= >> - ETL tool for mapping relational and Map/List/etc data, probably as >> operations in simple-methods (it is already pretty good for this, but more >> need to more in abstract and then apply to simple-methods and see if/what >> changes are needed) >> >> - XML consume operations for simple-method (and possibly XML produce too, >> though perhaps not because data prep can be done in simple-method and then >> FTL is a great way to template out the XML to produce) >> >> - Drools support >> >> - XSS prevention tools: >> https://issues.apache.org/jira/browse/OFBIZ-260 >> http://jira.undersunconsulting.com/browse/OFBIZ-559 >> https://issues.apache.org/jira/browse/OFBIZ-1193 >> https://issues.apache.org/jira/browse/OFBIZ-1476 >> Perhaps use service engine filters for ALL incoming data and by default >> do not allow HTML; all service in fields that should allow HTML will have >> to disable this filter manually, so it will require a bit of work. >> >> - other security issues: >> https://issues.apache.org/jira/browse/OFBIZ-1959 >> >> - IDE plugin for eclipse that uses artifact info stuff >> >> - artifact info stuff for ftl files, groovy scripts >> >> - AJAX form/etc widget stuff, especially a dynamic tree for the tree >> widget and better dynamic widgets in the form widget for various things >> >> - docs: reference (based on training videos), "support", training, >> example narration >> ========================================= >> >> >> On Jan 15, 2009, at 7:51 AM, Adrian Crum wrote: >> >> I agree with much of what David said. >>> >>> Personally, I feel the R4 branch timing was too early. There were some >>> major refactorings going on at the time, and those refactorings were >>> completed shortly after the R4 branch - which made R4 obsolete almost >>> immediately. At the time I didn't have much interest in maintaining the R4 >>> branch. >>> >>> Things are different this time around. As David mentioned, there has >>> been a lot of commit activity lately. Much of the work I've done in the >>> last few months has been making preparations for a new release branch. From >>> my perspective, if we hold off a bit on new major changes and let the dust >>> settle a little, the current trunk would be ready for another release >>> branch. This time around I'm committed to help maintain it. >>> >>> -Adrian >>> >>> David E Jones wrote: >>> >>>> Thanks for your comments Scott. I was going to write something almost >>>> as fatalistic. The reality really is that there were very few fixes that >>>> went directly into the release4.0 branch, and I don't think any of those >>>> made it into the trunk. There were lots of fixes from the trunk that went >>>> into the release branch thanks to (as Scott mentioned) a few committers >>>> who >>>> kept an eye on that. Those who are interested in a release branch seem to >>>> have different motives and intents than those using the trunk, which is >>>> fine, but is not very self-sustaining, hence my comments here: >>>> http://docs.ofbiz.org/display/OFBADMIN/Apache+OFBiz+Getting+Started >>>> So, let's get real: release branches attract users but don't attract >>>> committers or contributions. Some of those users may eventually become >>>> committers or contributors and move to the trunk in order to do so. So, >>>> really (to use a cliche: I've said it before and I'll say it again) doing >>>> releases in any form is mostly a marketing activity. >>>> Releases are certainly of value to the project, and of course to the >>>> people and organizations who use the releases, and those who get an >>>> introduction to OFBiz and are attracted to it because of a release of some >>>> form. Back to reality though, in a community driven project there is no >>>> central organization to fund the effort, and most OFBiz contributors and >>>> committers contribute based on what clients request or on issues they want >>>> to help with. >>>> Not to say that it is impossible, there are certainly many open source >>>> projects that do so on a regular basis. As I've thought about this over >>>> the >>>> years the only feeble conclusion I can come up with is that those projects >>>> have defined functionality sets that they can target and plan for. This is >>>> something that is easier to do with framework level tools, which is one of >>>> the reasons I've been trying to push for a focus on the framework. >>>> However, >>>> even there it has been tough to get people to propose things and plan... >>>> however significant cleanups and enhancements have happened and it >>>> actually is getting into pretty good shape for release so it can stand on >>>> its own. >>>> For the applications and such it's a bit tougher... the scope is large >>>> and difficult to agree on, especially given the variety of organizations >>>> and individuals that use OFBiz and contribute back and by doing so make >>>> OFBiz what it is. To help everyone get on the same page I've started an >>>> effort to define some business processes that can drive more requirements >>>> and designs to help the refine OFBiz and give us some targets to shoot >>>> for: >>>> >>>> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index >>>> Now, stepping back a little, we don't HAVE to do this in order to do a >>>> release. And again being honest with ourselves, without such a thing it >>>> doesn't matter too much _when_ we create the release branch... it's really >>>> quite arbitrary. >>>> So yes, a lot of thought and planning and numerous attempts (many just >>>> going very slowly...) to move in this direction are happening. >>>> For the next release branch, there was recent discussion about it and a >>>> decision to do it as I recall, it's now a question of when and not if. And >>>> the when (also from memory, sorry) was intended to be about 2 years from >>>> the date of the release4.0 branch, and that is just a few weeks from now. >>>> There are lots of great cleanup efforts going on and unless something >>>> serious is up in the air in a few weeks, the release branch will happen. >>>> I only hope it will be of value to a number of people and that good >>>> will come from it. >>>> This is one aspect of OFBiz that I don't think is terribly successful, >>>> and past trends are somewhat frustrating, but I still think it is a good >>>> thing and so we work for it and keep trying. Someday I'm hoping various >>>> people from the community will rally and create a really great stable >>>> release that shines and works like it's supposed to. >>>> Comments from volunteers and pundits (ie the peanut gallery) welcome. >>>> -David >>>> On Jan 14, 2009, at 8:12 PM, Scott Gray wrote: >>>> >>>>> Hi Bruno >>>>> It sounds reasonable in theory but the reality is that merging bug >>>>> fixes >>>>> into a branch takes a great deal of time on an ongoing basis. I don't >>>>> recall seeing a single bug fixing patch being contributed by any of >>>>> the >>>>> community at large, the work was maintained by a couple of committers >>>>> and NO >>>>> ONE else. >>>>> >>>>> The whole reason IMO that the v4 release branch never became an actual >>>>> release was because virtually no one in the community showed any real >>>>> interest in it. >>>>> >>>>> Personally I think the best thing for the project right now would be >>>>> remove >>>>> any mention of the v4 branch from the main page and any other docs, so >>>>> that >>>>> people don't mistakenly get the impression that it is the best path >>>>> for them >>>>> to take. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> 2009/1/14 Bruno Busco <[email protected]> >>>>> >>>>> oops, >>>>>> sorry to have posted this to the USER ML, I apologize, it was >>>>>> intended, of course, as a DEV discussion. >>>>>> >>>>>> -Bruno >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: Bruno Busco <[email protected]> >>>>>> Date: 2009/1/14 >>>>>> Subject: Re: locale error in simple method >>>>>> To: [email protected] >>>>>> >>>>>> >>>>>> I think that Vince's situation is very common. >>>>>> >>>>>> Whenever you get your ofbiz put in production (or a sort of) you get >>>>>> really "apprensive" and try to not update your working box. >>>>>> This makes hard also to get bug fixes only from the trunk. >>>>>> >>>>>> Could we think to try to have a new release branch? >>>>>> I mean a branch where only bug fix are merged from the trunk? >>>>>> I know that this has been discussed many times but we should give it >>>>>> a >>>>>> try. The framework-only release could be still something in the >>>>>> agenda >>>>>> and should not be affected by the existence of the new complete >>>>>> release branch. >>>>>> >>>>>> The last release branch (4.0) seems now too far from the trunk head >>>>>> and we often suggest not to use it any more. This is fine because we >>>>>> want people on the "living edge" of the code but then we will get >>>>>> them >>>>>> in the "should I update or not?" situation. >>>>>> >>>>>> Having a new release branch we will have most people living there and >>>>>> contributing back bug-fix patch or bug reports that will still be >>>>>> used >>>>>> in the trunk. >>>>>> >>>>>> I see many new features coming into the trunk and this is really >>>>>> great >>>>>> but, may be, many more would come if who is going to commit them >>>>>> knows >>>>>> that the community could always rely on an unaffetced "stable" >>>>>> branch. >>>>>> >>>>>> -Bruno >>>>>> >>>>>> >>>>>> 2009/1/14 Vince M. Clark <[email protected]>: >>>>>> >>>>>>> I don't waste my time with 4.0. >>>>>>> >>>>>>> Preaching doesn't bother me. I'm used to it and have done a bit >>>>>>> myself. >>>>>>> >>>>>>> But to be clear, I'm very collaborative, and am not holding anything >>>>>>> back >>>>>>> >>>>>> from the community. This particular instance I have not upgraded >>>>>> because it >>>>>> is production (sort of) and I have had difficulty upgrading other >>>>>> instances >>>>>> recently because of some seed data issues, and possibly other >>>>>> reasons. >>>>>> Basically related to some of the new stuff like visual themes. >>>>>> >>>>>>> >>>>>>> I will try my custom service against a current download of trunk to >>>>>>> >>>>>> verify that it isn't just a version issue. >>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "David E Jones" <[email protected]> >>>>>>> To: [email protected] >>>>>>> Sent: Tuesday, January 13, 2009 6:06:06 PM (GMT-0700) America/ Denver >>>>>>> Subject: Re: locale error in simple method >>>>>>> >>>>>>> >>>>>>> Is that the trunk rev or in the release4.0 branch? >>>>>>> >>>>>>> Either way it's a few months old (looks like 23 Jul 2008)... it >>>>>>> would >>>>>>> take a fair amount of time for someone to go back and try to >>>>>>> reproduce >>>>>>> the error on that revision. Have you considered updating to a newer >>>>>>> version of OFBiz? >>>>>>> >>>>>>> Just as an FYI, I usually recommend that people working from the >>>>>>> trunk >>>>>>> really collaborate with the community, an that usually means needing >>>>>>> to update at least once per day (or at the _very_ least a couple of >>>>>>> times per week) until the development part of each cycle is done (ie >>>>>>> before doing integration or business level testing, if that means >>>>>>> anything for your process). >>>>>>> >>>>>>> There are lots of reasons for this, and what you're running into is >>>>>>> perhaps the most important: by sticking with that revision you're >>>>>>> basically going it alone and choosing not to collaborate with the >>>>>>> community, which makes it hard for others in the community to >>>>>>> collaborate with you. The same is true for the practice of changing >>>>>>> things in the OFBiz framework or core parts of different >>>>>>> applications >>>>>>> and not contributing it back to the project. The project suffers a >>>>>>> little, but the project will do fine as there are LOTS of people >>>>>>> contributing back. Who really suffers is the end-user organization >>>>>>> that has to foot the bill of maintaining these things instead of >>>>>>> sharing that with the community. >>>>>>> >>>>>>> Sorry for the preaching, but on the other hand thanks for the soap >>>>>>> box >>>>>>> to stand on for a little sermon. >>>>>>> >>>>>>> -David >>>>>>> >>>>>>> >>>>>>> On Jan 13, 2009, at 4:34 PM, Vince M. Clark wrote: >>>>>>> >>>>>>> Thanks David. Rev is 679168 >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "David E Jones" <[email protected]> >>>>>>>> To: [email protected] >>>>>>>> Sent: Tuesday, January 13, 2009 5:36:35 PM (GMT-0700) America/ >>>>>>>> Denver >>>>>>>> Subject: Re: locale error in simple method >>>>>>>> >>>>>>>> >>>>>>>> Stepping back even more... which version/revision of OFBiz are you >>>>>>>> using? >>>>>>>> >>>>>>>> Based on what you wrote, with the browser submitting a form to the >>>>>>>> OFBiz web server, as long as it is going through the ControlServlet >>>>>>>> and you are calling the service you described through a request- map >>>>>>>> -> >>>>>>>> event tag, then it should work the same way as anything else in >>>>>>>> OFBiz. >>>>>>>> >>>>>>>> Unless something is broken somewhere then OFBiz should be getting a >>>>>>>> locale no matter what, even if it is the system default locale. It >>>>>>>> looks like somehow that isn't making it into the service call (you >>>>>>>> could verify that by adding a log tag in your simple-method to >>>>>>>> print >>>>>>>> the ${locale} string). That's part of the reason I'm about the >>>>>>>> revision you are using... it could be a real issue that most of us >>>>>>>> aren't seeing if you're not using a recent trunk revision. >>>>>>>> >>>>>>>> Of, if the assumptions in the 2nd paragraph above are not correct >>>>>>>> (ie >>>>>>>> you are calling things differently) then there could be issues >>>>>>>> there >>>>>>>> as well. >>>>>>>> >>>>>>>> -David >>>>>>>> >>>>>>>> >>>>>>>> On Jan 13, 2009, at 3:59 PM, Vince M. Clark wrote: >>>>>>>> >>>>>>>> >>>>>>>>> First a disclaimer (plea for mercy). I am an ERP person, not a web >>>>>>>>> or UI person. So all this http, session, context stuff is rather >>>>>>>>> confusing to me. >>>>>>>>> >>>>>>>>> I've been digging on this issue and want to make sure something is >>>>>>>>> very clear because I think it may have something to do with the >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> OfBiz is NOT rendering any screens for me. I'm using it as kind of >>>>>>>>> a >>>>>>>>> "cheap" web service. I have a static html web form served by >>>>>>>>> Apache >>>>>>>>> web server. The form action calls OfBiz, and then I redirect back >>>>>>>>> to >>>>>>>>> a static html page. So OfBiz just accepts the request, processes >>>>>>>>> it, >>>>>>>>> and redirects. No screen rendering whatsoever by OfBiz. >>>>>>>>> >>>>>>>>> I'm pointing this out because of one of the comments I found in a >>>>>>>>> java class (which of course I cannot find now) that said something >>>>>>>>> about if locale was not in the context then the browser (or maybe >>>>>>>>> session) default would be used. >>>>>>>>> >>>>>>>>> So to simplify (or maybe over simplify) my question, is there >>>>>>>>> something I should be doing in my simple method to put locale in >>>>>>>>> the >>>>>>>>> context before I call createLead. Also, can someone give me a tip >>>>>>>>> on >>>>>>>>> how to iterate through whatever is in the context and write it out >>>>>>>>> to the log so I can see it. >>>>>>>>> >>>>>>>>> >>
