Re: widgetVerbose
I am going to feel bad if I don't add my 2 cents to this thread :-)
I agree with Jacques that the formatting of boundary comments should be output
specific (i.e no output for CSV etc...) instead of always rendering as html
comments.
As regards the logic to determine if comments should be enabled or not, I don't
have a strong opinion because I have always used this feature in a very rough
way (enable all or disable all); however I can understand the we may want to
avoid that (when widget.properties.enableBoundaryComments == false) the
comments are enabled by passing a URL parameter to the screen.
Kind regards,
Jacopo
On Sep 15, 2011, at 4:18 PM, Jacques Le Roux wrote:
Someone I work with suggested:
I have to point out though that I kind of agree with the way David put it in
that the false setting could have a priority, i.e. it's like in security
permissions where deny has precedence over allow, so if you set it in
widget.properties to false then you're sure comments will never be enabled
anywhere... security-wise it makes sense despite the comment about qc...
Maybe something like this? (compromise between the two)
if (widget.properties.enableBoundaryComments == false
|| web.xml.enableBoundaryComments == false
|| context.enableBoundaryComments == false) {
return false;
} else { // This is the solution Scott wrote, but use overriding settings
only for null and true values
if (context.enableBoundaryComments != null) return
context.enableBoundaryComments;
if (web.xml.enableBoundaryComments != null) return
web.xml.enableBoundaryComments;
if (widget.properties.enableBoundaryComments != null) return
widget.properties.enableBoundaryComments;
return false;
}
Could probably rewrite that to be less redundant but you get the idea...
jleroux: I quickly reformated my own way ;o), It seems a good idea to me,
what do you think?
Also my colleague also wrote:
Only thing I have to add is that I didn't see anyone address the issue that
HTML comments are outputted for CSV (because there's no csv element and you
have to use html) element. No matter what widget.verbose is set to, there
should never be HTmL comments outputted for csv. so this only addresses half
the bugs...
We have no patches so far...
Jacques
Dimitri Unruh wrote:
+1
Dimitri Unruh
Consultant AEW
Lynx-Consulting GmbH
Johanniskirchplatz 6
33615 Bielefeld
Deutschland
Fon: +49 521 5247-0
Fax: +49 521 5247-250
Mobil: +49 160 90 57 55 13
Company and Management Headquarters:
Lynx-Consulting GmbH, Johanniskirchplatz 6, 33615 Bielefeld, Deutschland
Fon: +49 521 5247-0, Fax: +49 521 5247-250, www.lynx.de
Court Registration: Amtsgericht Bielefeld HRB 35946
Chief Executive Officers: Karsten Noss, Dirk Osterkamp
http://www.lynx.de/haftungsausschluss
Wir laden Sie herzlich ein:
DSAG-Jahreskongress
Datum: 11. - 13. Oktover 2011, Congress Center Leipzig, Halle 2 Stand B01
Besuchen Sie uns an unserem Stand und freuen Sie sich auf einen intensiven
Informations- und Erfahrungsaustausch rund um das
Thema Mobility!
Am 13.09.2011 um 14:35 schrieb Bilgin Ibryam bibr...@gmail.com:
On Tue, Sep 13, 2011 at 9:54 AM, Adrian Crum
adrian.c...@sandglass-software.com wrote:
Thanks Scott - those are my feelings exactly.
I like the way the design worked previously, and changing it because a user
might accidentally leave the comments enabled in production seems silly.
That is a user's QC problem, not a widget comment design problem.
-Adrian
+ 1
Bilgin
Re: discussion: video rentals
Hi Hans, I have read the threads and the blog posts, and considering the requirements: * the need to maintain (serialized) inventory items and ship/receive them * the need to depreciate the items as assets I am wondering if you have considered the design of: * using product/inventory items (mostly) as in standard OFBiz (add to cart products then reserve,pick,ship inventory items then return product/item) * using fixed assets only for the depreciation Without looking at the details (and I guess I may be missing some of them) this seems to me a simpler approach that would have caused a smaller impact in the existing code. Kind regards, Jacopo On Sep 27, 2011, at 4:59 AM, Hans Bakker wrote: Thanks Adrian and Paul for the valuable comments. Taking all comments into account, we will do the following: (most is already done) 1. a single product can refer to one or more assets. (as is now) 2. An asset can refer to a single inventory item. (is added) 3. With this product type, the assetid will be shown on the orderitem, picklist and shipping slip which also will show the RA# (return auth #) 4. the item can be received in the facility - receive return option. more info at: http://www.antwebsystems.com/control/ViewBlogArticle?contentId=91048 Regards, Hans On Fri, 2011-09-23 at 12:20 +0700, Hans Bakker wrote: Now we can have rental products where the asset can be rented In this product type the product is a group of video rentals of the same rental price referring to many video assets. However now we also want to categorize these assets in order to display them on the e-commerce website. Is adding a fixedAssetid field to the ProductCategoryMember entity a solution? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates.
Re: discussion: video rentals
Hi Hans, I can't see what in my notes would prevent from doing this, since you have already added the fixedAssetId to the InventoryItem entity (as a side note, I would have preferred the other way round, i.e. if the field inventoryItemId was added to the FixedAsset entity)? Regards, Jacopo On Oct 5, 2011, at 6:01 AM, Hans Bakker wrote: Hi Jacopo, thanks for you comment. I did look into this but decided to not duplicate data in the system. In the case where assets for maintenance and depreciation is not connected with a serialized inventory item we will have a number of fields duplicated (cost, serial number etc) and we do not know where the asset is stored in inventory when not in use. Regards, Hans On Mon, 2011-10-03 at 12:35 +0200, Jacopo Cappellato wrote: Hi Hans, I have read the threads and the blog posts, and considering the requirements: * the need to maintain (serialized) inventory items and ship/receive them * the need to depreciate the items as assets I am wondering if you have considered the design of: * using product/inventory items (mostly) as in standard OFBiz (add to cart products then reserve,pick,ship inventory items then return product/item) * using fixed assets only for the depreciation Without looking at the details (and I guess I may be missing some of them) this seems to me a simpler approach that would have caused a smaller impact in the existing code. Kind regards, Jacopo On Sep 27, 2011, at 4:59 AM, Hans Bakker wrote: Thanks Adrian and Paul for the valuable comments. Taking all comments into account, we will do the following: (most is already done) 1. a single product can refer to one or more assets. (as is now) 2. An asset can refer to a single inventory item. (is added) 3. With this product type, the assetid will be shown on the orderitem, picklist and shipping slip which also will show the RA# (return auth #) 4. the item can be received in the facility - receive return option. more info at: http://www.antwebsystems.com/control/ViewBlogArticle?contentId=91048 Regards, Hans On Fri, 2011-09-23 at 12:20 +0700, Hans Bakker wrote: Now we can have rental products where the asset can be rented In this product type the product is a group of video rentals of the same rental price referring to many video assets. However now we also want to categorize these assets in order to display them on the e-commerce website. Is adding a fixedAssetid field to the ProductCategoryMember entity a solution? -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates. -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates.
Re: svn commit: r1167015 - in /ofbiz/trunk: applications/accounting/entitydef/ applications/order/config/ applications/order/data/ applications/order/entitydef/ applications/order/script/org/ofbiz/ord
It would be nice if the code could be enhanced so that the new
ASSET_USAGE_OUT_IN type and the old ASSET_USAGE are children of a common type,
e.g.:
ASSET
|___ ASSET_USAGE
|
|___ ASSET_USAGE_OUT_IN
and then, when specific behavior is required, the
EntityTypeUtil.hasParentType(...) is used.
For example, instead of:
if (ASSET_USAGE.equals(_product.getString(productTypeId))) {
this.itemType = RENTAL_ORDER_ITEM; // will create additional
workeffort/asset usage records
} else if (ASSET_USAGE_OUT_IN.equals(_product.getString(productTypeId))) {
this.itemType = RENTAL_ORDER_ITEM;
} ...
the code could be:
if (EntityTypeUtil.hasParentType(delegator, ProductType, productTypeId,
_product.getString(productTypeId), parentTypeId, ASSET_USAGE)) {
this.itemType = RENTAL_ORDER_ITEM; // will create additional
workeffort/asset usage records
} else if (EntityTypeUtil.hasParentType(delegator, ProductType,
productTypeId, _product.getString(productTypeId), parentTypeId,
ASSET_USAGE_OUT_IN)) {
this.itemType = RENTAL_ORDER_ITEM;
} ...
and instead of code like:
if (ASSET_USAGE.equals(_product.getString(productTypeId)) ||
ASSET_USAGE_OUT_IN.equals(_product.getString(productTypeId))) {
// will create additional workeffort/asset usage records...
} ...
the code could be like:
if (EntityTypeUtil.hasParentType(delegator, ProductType, productTypeId,
_product.getString(productTypeId), parentTypeId, ASSET)) {
// will create additional workeffort/asset usage records...
} ...
The existing code already works in this way for marketing packages.
The main advantage is that it is easier to extend the system by adding a new
product type that automatically inherits the behaviour of the parent type (it
will be just a matter to add a new children type) and then add specific
behavior only where needed.
Jacopo
On Sep 9, 2011, at 8:40 AM, hans...@apache.org wrote:
Author: hansbak
Date: Fri Sep 9 06:40:28 2011
New Revision: 1167015
URL: http://svn.apache.org/viewvc?rev=1167015view=rev
Log:
New product type: Fixed Asset Usage For Rental of an asset which is shipped
from and returned to inventory. Including Junit test and demo data. More
explanation will follow in a blog on the 'what is new page'
Short term plans for official releases
Hi to all contributors. With this email I just want to check if we are interested in issuing one or more official releases soon (this or next month). If we are, I will be more than happy to support the process as usual. Here is what we could release: * the first stable release of the 11.04 series (branch): Apache OFBiz 11.04; (the code freeze was done in April 2011) * the first bug fix release of the 10.04 series (branch): Apache OFBiz 10.04.01; (the last release, 10.04, was released in January 2011) * the second bug fix release of the 09.04 series (branch): Apache OFBiz 09.04.02; (the last release, 09.04.01, was released in January 2011) Then, as Jacques suggested in another thread, we could (possibly as part of the announce we will do for the release and in the project's download page) clearly mention the release that is no longer supported by the community (i.e. 4.0). Of course, we will do one release at a time and we could prepare a tentative schedule (like one release per month); or simply wait for the releases of some branches. What do you all think? Regards, Jacopo Reference: http://ofbiz.apache.org/download.html
Re: Short term plans for official releases
Thank you Jacques, please see my note below: On Oct 5, 2011, at 3:55 PM, Jacques Le Roux wrote: Maybe we should make more clear somewhere that releases like 10.04.01 or 09.04.02 are only tagged revisions in respective branches (or did I miss some places where this is clearly explained?). In other words only branches are still evolving when releases are freezed. This is explainedin the official download page (where releases are published): http://ofbiz.apache.org/download.html but of course we could improve the information there; I was thinking to better separate the latest release 10.04 from the older ones and also, inside a series, decrease the fonts of the older releases. Kind regards, Jacopo
Steve Jobs, 1955-2011
Thanks
Re: Short term plans for official releases
Jacques, all, I did a series of changes (rev. 1180638) to the text and formatting of the Download page and now it should be easier to understand what to download and how things are structured; I have tried to incorporate your feedback. When you can, please have a look (and a double look to typos and grammar). Kind regards, Jacopo On Oct 8, 2011, at 5:13 PM, jacques.le.r...@spamcop.net wrote: Thanks Jacopo, I had the feeling I was missing something. I plenty agree with your suggestions. Could we not had a word on this page about live branches (vs freezed/zipped releases) and a link to repo (vs downloads mirrors)? I'm currently in vacation for a week, so I will not work on this soon... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques, please see my note below: On Oct 5, 2011, at 3:55 PM, Jacques Le Roux wrote: Maybe we should make more clear somewhere that releases like 10.04.01 or 09.04.02 are only tagged revisions in respective branches (or did I miss some places where this is clearly explained?). In other words only branches are still evolving when releases are freezed. This is explainedin the official download page (where releases are published): http://ofbiz.apache.org/download.html but of course we could improve the information there; I was thinking to better separate the latest release 10.04 from the older ones and also, inside a series, decrease the fonts of the older releases. Kind regards, Jacopo
Re: Short term plans for official releases
Hi Jacques, On Oct 16, 2011, at 11:52 PM, Jacques Le Roux wrote: Jacopo, I have just added this sentence to https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan#ReleasePlan-GeneralReleasePolicies * Because it needs too much work, at some point older releases will not be supported by the community (trunk patches not backported) I have also noticed this sentence (just before the one I added) * Each new release tag and pre-built package will be represented by a third position version number change (since February 2009 seems that we will prefer to use the revision number for that) I like the idea of adding the revision number rather than a third position version number, maybe it's not worth changing now but we could stick with it for future releases? (It relates to this thead http://markmail.org/message/3xhnpbbmceg5hdg7) We could, but the release name convention we are using has been already changed too many times (and we ended up with a bad one imo) so my preference would be to postpone any decision to change it another time unless we all want and agree upon a much better one. About the download page, looks good to me, some questions: *Something is not clear to me Apache OFBiz 10.04 This release contains all the features of the trunk up to April 2010 and since then has been stabilized with bug fixes. So it means that the zip is automatically updated from the repo (when changed) and always last revision accessible to mirrors, right? Same for 09.04.01, I guess? No we cannot do this: all the files from the download page must be official releases (i.e. voted for release by the PMC). As regards the 10.04, the release date is mentioned in the next sentence: It is our current stable release, and has been officially released in January 2011. As regards 09.04.01, the release date is mentione here: Apache OFBiz 09.04.01 is the current and latest release of the 09.04 series; it is a bug fix release, issued in January 2011 * Under the Snapshots section, I'd like to add some words about svn repo, trunk and releases branches. Do you think it makes sense (it's not releases but could interest, make quicker links for developers) No please, do not add download links etc because all the information if this page should only contain official files; in fact the snapshot section is already an exception to this rule that for now it is acceptable. But you may add a sentence to point the user to the https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html page... even if we may even want to consider to remove the snapshot section at all from the download page, and add a link to the snapshot page from the https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html instead. Jacopo Thanks Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Jacques, all, I did a series of changes (rev. 1180638) to the text and formatting of the Download page and now it should be easier to understand what to download and how things are structured; I have tried to incorporate your feedback. When you can, please have a look (and a double look to typos and grammar). Kind regards, Jacopo On Oct 8, 2011, at 5:13 PM, jacques.le.r...@spamcop.net wrote: Thanks Jacopo, I had the feeling I was missing something. I plenty agree with your suggestions. Could we not had a word on this page about live branches (vs freezed/zipped releases) and a link to repo (vs downloads mirrors)? I'm currently in vacation for a week, so I will not work on this soon... Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Thank you Jacques, please see my note below: On Oct 5, 2011, at 3:55 PM, Jacques Le Roux wrote: Maybe we should make more clear somewhere that releases like 10.04.01 or 09.04.02 are only tagged revisions in respective branches (or did I miss some places where this is clearly explained?). In other words only branches are still evolving when releases are freezed. This is explainedin the official download page (where releases are published): http://ofbiz.apache.org/download.html but of course we could improve the information there; I was thinking to better separate the latest release 10.04 from the older ones and also, inside a series, decrease the fonts of the older releases. Kind regards, Jacopo
Re: Short term plans for official releases
Hi Jacques, On Oct 18, 2011, at 10:10 AM, Jacques Le Roux wrote: The same (than Bruno) was also asked later by Ruth later (in another thread) BTW... What don't you like in the release name convention? The Ubuntu way? It is not a big deal but, since we have very few releases an old traditional sequence would have worked fine imo. Now we have 09.04 but people are confused because they may think there is also a 09.03 or it is not obvious that 09.04 is greater than 4. And last point, it is not that clear that 09.04 means 2009.04... But at this point it is fine and imo having one convention and sticking to it is much better than changing it. Jacopo
Re: Short term plans for official releases
Hi Jacques, it sounds like a good idea; I would like to suppress the mention to Ubuntu and simply describe the naming convention we use. Kind regards, Jacopo On Oct 19, 2011, at 8:19 AM, Jacques Le Roux wrote: Hi Jacopo, Maybe we could add an explanation on top of the download page, to make things more clear. From https://cwiki.apache.org/confluence/display/OFBADMIN/Release+Plan#ReleasePlan-GeneralReleasePolicies We could say Release branches are created once per year, so far in April . We use the same release numbering scheme than Ubuntu (for instance, 9.4 means released in 2009.April). Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi Jacques, On Oct 18, 2011, at 10:10 AM, Jacques Le Roux wrote: The same (than Bruno) was also asked later by Ruth later (in another thread) BTW... What don't you like in the release name convention? The Ubuntu way? It is not a big deal but, since we have very few releases an old traditional sequence would have worked fine imo. Now we have 09.04 but people are confused because they may think there is also a 09.03 or it is not obvious that 09.04 is greater than 4. And last point, it is not that clear that 09.04 means 2009.04... But at this point it is fine and imo having one convention and sticking to it is much better than changing it. Jacopo
Re: discussion: be able to add tags
Hi Hans, On Nov 26, 2011, at 12:32 AM, Hans Bakker wrote: Hi All, We have the need to be able to add pre-approved tags to products, content and workeffort. My guess is that you are implementing a backend workflow to approve products/contents/workefforts before they are allowed to be sold/published/used in production. in my opinion the three entities should be treated separately: * products: my preference is to use ProductCategory (with a new special productCategoryTypeId), the products in the category are the pre-approved ones; the advantages of this approach are: you can configure the system to have a different pre-approval for each catalog, or each product store, or simply one per product; the ProductCategoryMember.comments field could be used to store comments from the approver etc... * content: use the existing data model (ContentApproval etc...) * workeffort: use workeffort statuses (or WorkEffortReview etc...) Kind regards, Jacopo We have a similar function already in the system with keywords. However this is not pre-approved and less formal. I think we still can use this function as long as we can distinguish the tags and the keywords. There fore I would like to propose to add a field to the keyword entities: 'keywordType' with initially the type 'Tag' and empty or 'keyword' for the current function. The keywordType itself and the tags can be defined in the entity Enumeration. Your opinions please? Regards, Hans
Re: discussion: be able to add tags
On Nov 29, 2011, at 7:39 AM, Hans Bakker wrote: My guess is that you are implementing a backend workflow to approve products/contents/workefforts before they are allowed to be sold/published/used in production. Then i explained myself badly. The approval of the tags is important, not the approval of the products content or workeffort. Tags are intended to be used for grouping and selection only, like keywords but more organized and be able to improve searching combining the 2 possibilities. Ah I see now, I actually misunderstood your initial mail: so in this context pre-approval means a pre-defined list of tags that can be selected, for example from a drop down field. If my understanding is right then yes, I think that what you proposed is a good solution: adding a new enumeration type (or entity like KeywordType) and then a new field to the various *Keyword entities you want to extend. If the field is null or equals to KEYWORD (or similar) then the system treats the record as it currently does; if the field is set to the new type then your new logic is used. Kind regards, Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Hans, could you please be more specific on the errors/failures you are getting? It seems I was able to run successfully all the tests. Jacopo On Dec 13, 2011, at 3:41 PM, Hans Bakker wrote: Yes a good idea: https://issues.apache.org/jira/browse/OFBIZ-4624 Regards, Hans On 12/13/2011 09:21 PM, Erwan de FERRIERES wrote: Hans, could you create an associated Jira issue, so this won't be forgotten ? Thanks, 2011/12/13hans...@apache.org: Author: hansbak Date: Tue Dec 13 11:04:57 2011 New Revision: 1213650 URL: http://svn.apache.org/viewvc?rev=1213650view=rev Log: commented out accounting auto tests which did not work for a long time Modified: ofbiz/trunk/applications/accounting/testdef/accountingtests.xml Modified: ofbiz/trunk/applications/accounting/testdef/accountingtests.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/testdef/accountingtests.xml?rev=1213650r1=1213649r2=1213650view=diff == --- ofbiz/trunk/applications/accounting/testdef/accountingtests.xml (original) +++ ofbiz/trunk/applications/accounting/testdef/accountingtests.xml Tue Dec 13 11:04:57 2011 @@ -29,7 +29,8 @@ test-case case-name=accounting-testsjunit-test-suite class-name=org.ofbiz.accounting.test.FinAccountTests//test-case -test-case case-name=auto-accounting-transaction-tests +!-- commented out for now...test data seems to be missing and i wondered if theyu ever worked, went back to rev: 903431 and ever there the same problem -- +!-- test-case case-name=auto-accounting-transaction-tests simple-method-test location=component://accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml/ -/test-case +/test-case-- /test-suite
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Hans,
did you run ant run-install before ant run-tests?
I suspect that you are getting this error because in your db the order
DEMO10091 is not found.
Jacopo
On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote:
Hi Jacopo,
this is what is reported:
Error Message
ERROR: Could not complete the Test case for Purchase Invoices: editing,
adding taxes and shipping charges and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map named
[serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
00:11:52.971(java.sql.Timestamp)][lastU
pdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter is
missing: [IN] [setInvoiceStatus.invoiceId]]
Stacktrace
junit.framework.AssertionFailedError: ERROR: Could not complete the Test case
for Purchase Invoices: editing, adding taxes and shipping charges and posting
to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map named
[serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
0
0:11:52.971(java.sql.Timestamp)][lastUpdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter is
missing: [IN] [setInvoiceStatus.invoiceId]]
at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:93)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310)
at org.ofbiz.base.start.Start.start(Start.java:289)
at org.ofbiz.base.start.Start.main(Start.java:119)
Regards,
Hans
On 12/13/2011 10:52 PM, Jacopo Cappellato wrote:
Hans,
could you please be more specific on the errors/failures you are getting?
It seems I was able to run successfully all the tests.
Jacopo
On Dec 13, 2011, at 3:41 PM, Hans Bakker wrote:
Yes a good idea:
https://issues.apache.org/jira/browse/OFBIZ-4624
Regards,
Hans
On 12/13/2011 09:21 PM, Erwan de FERRIERES wrote:
Hans,
could you create an associated Jira issue, so this won't be forgotten ?
Thanks,
2011/12/13
hans...@apache.org
:
Author: hansbak
Date: Tue Dec 13 11:04:57 2011
New Revision: 1213650
URL:
http://svn.apache.org/viewvc?rev=1213650view=rev
Log:
commented out accounting auto tests which did not work for a long time
Modified:
ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Modified: ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/testdef/accountingtests.xml?rev=1213650r1=1213649r2=1213650view=diff
==
--- ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
(original)
+++ ofbiz/trunk/applications/accounting/testdef/accountingtests.xml Tue
Dec 13 11:04:57 2011
@@ -29,7 +29,8 @@
test-case case-name=accounting-testsjunit-test-suite
class-name=org.ofbiz.accounting.test.FinAccountTests//test-case
-test-case case-name=auto-accounting-transaction-tests
+!-- commented out for now...test data seems to be missing and i
wondered if theyu ever worked, went back to rev: 903431 and ever there
the same problem --
+!-- test-case case-name=auto-accounting-transaction-tests
simple-method-test
location=component://accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml/
-/test
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Hi Hans,
please see inline:
On Dec 14, 2011, at 8:55 AM, Hans Bakker wrote:
Hi Jacopo,
thank you for looking into this.
yes sure i did run ./ant run-install
The test below needs some OrderItemBilling records for order DEMO10091 which
specifies an invoiceId.
these records are however not there and therefore the invoiceId is missing.
I can also not find them anywhere in demo or test data
I think the invoice (and OrderItemBilling record) is created by the chain of
events caused by the test before that one: testAcctgTransOnPoReceipts
(receipt--shipment--invoice)
Then i disabled only the test below, and then all following tests in the same
file are failing.
Of course they are, because the tests in that group rely on each other.
Then I went back to a much earlier revision where the tests are failing
tooA revision where i found them working is 892749 from 2009-12-21 . So
they seem to be working before...
did you try to run the ./ant run-tests locally ? It looks like buildbot is
missing these tests
Yes, I tested the tests locally:
ant clean-all
ant run-install
ant run-tests
Jacopo
Regards,
Hans
On 12/14/2011 01:56 PM, Jacopo Cappellato wrote:
Hans,
did you run ant run-install before ant run-tests?
I suspect that you are getting this error because in your db the order
DEMO10091 is not found.
Jacopo
On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote:
Hi Jacopo,
this is what is reported:
Error Message
ERROR: Could not complete the Test case for Purchase Invoices: editing,
adding taxes and shipping charges and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
00:11:52.971(java.sql.Timestamp)][lastU
pdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
Stacktrace
junit.framework.AssertionFailedError: ERROR: Could not complete the Test
case for Purchase Invoices: editing, adding taxes and shipping charges and
posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
0
0:11:52.971(java.sql.Timestamp)][lastUpdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:93)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310)
at org.ofbiz.base.start.Start.start(Start.java:289)
at org.ofbiz.base.start.Start.main(Start.java:119)
Regards,
Hans
On 12/13/2011 10:52 PM, Jacopo Cappellato wrote:
Hans,
could you please be more specific on the errors/failures you are getting?
It seems I was able to run successfully all the tests.
Jacopo
On Dec 13, 2011, at 3:41 PM, Hans Bakker wrote:
Yes a good idea:
https://issues.apache.org/jira/browse/OFBIZ-4624
Regards,
Hans
On 12/13/2011 09:21 PM, Erwan de FERRIERES wrote:
Hans,
could you create an associated Jira issue, so this won't be forgotten ?
Thanks,
2011/12/13
hans...@apache.org
:
Author: hansbak
Date: Tue Dec 13 11:04:57 2011
New Revision: 1213650
URL:
http://svn.apache.org/viewvc
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Thanks Jacques, but I am running my tests locally and I get a 100% success rate:
[java] 2011-12-14 09:44:22,120 (main) [ TestRunContainer.java:158:INFO ]
[JUNIT] Pass: true | # Tests: 531 | # Failed: 0 # Errors: 0
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:161:INFO ]
[JUNIT] - ERRORS -
[JUNIT]
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:164:INFO ]
None
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:174:INFO ]
[JUNIT] --
[JUNIT]
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:175:INFO ]
[JUNIT] FAILURES
[JUNIT]
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:178:INFO ]
None
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:188:INFO ]
[JUNIT] --
[JUNIT]
Jacopo
On Dec 14, 2011, at 9:24 AM, Jacques Le Roux wrote:
Did you guys read my messages?
http://svn.apache.org/viewvc?rev=1212749view=rev
Do you look at buildbot history? It's then obvious that the last non failing
revision, before Hans 's revert, was r1212147 and it began to fail at r1212266
Do you need more help?
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
Hi Jacopo,
thank you for looking into this.
yes sure i did run ./ant run-install
The test below needs some OrderItemBilling records for order DEMO10091 which
specifies an invoiceId.
these records are however not there and therefore the invoiceId is missing.
I can also not find them anywhere in demo or test data
Then i disabled only the test below, and then all following tests in the
same file are failing. Then I went back to a much earlier revision where the
tests are failing tooA revision where i found them working is 892749
from 2009-12-21 . So they seem to be working before...
did you try to run the ./ant run-tests locally ? It looks like buildbot is
missing these tests
Regards,
Hans
On 12/14/2011 01:56 PM, Jacopo Cappellato wrote:
Hans,
did you run ant run-install before ant run-tests?
I suspect that you are getting this error because in your db the order
DEMO10091 is not found.
Jacopo
On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote:
Hi Jacopo,
this is what is reported:
Error Message
ERROR: Could not complete the Test case for Purchase Invoices: editing,
adding taxes and shipping charges and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
00:11:52.971(java.sql.Timestamp)][lastU
pdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
Stacktrace
junit.framework.AssertionFailedError: ERROR: Could not complete the Test
case for Purchase Invoices: editing, adding taxes and shipping charges and
posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
0
0:11:52.971(java.sql.Timestamp)][lastUpdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
at org.ofbiz.testtools.SimpleMethodTest.run
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Oops sorry, copied the wrong text; however all the tests are successful:
Summary
Tests FailuresErrors Success rateTime
879 0 0 100.00% 215.841
including the ones in accounting:
Class accountingtests
NameTests Errors FailuresTime(s) Time
Stamp
accountingtests 17 0 0 8.868
2011-12-14T08:43:16
Jacopo
On Dec 14, 2011, at 9:47 AM, Jacopo Cappellato wrote:
Thanks Jacques, but I am running my tests locally and I get a 100% success
rate:
[java] 2011-12-14 09:44:22,120 (main) [ TestRunContainer.java:158:INFO
] [JUNIT] Pass: true | # Tests: 531 | # Failed: 0 # Errors: 0
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:161:INFO
] [JUNIT] - ERRORS -
[JUNIT]
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:164:INFO
] None
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:174:INFO
] [JUNIT] --
[JUNIT]
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:175:INFO
] [JUNIT] FAILURES
[JUNIT]
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:178:INFO
] None
[java] 2011-12-14 09:44:22,121 (main) [ TestRunContainer.java:188:INFO
] [JUNIT] --
[JUNIT]
Jacopo
On Dec 14, 2011, at 9:24 AM, Jacques Le Roux wrote:
Did you guys read my messages?
http://svn.apache.org/viewvc?rev=1212749view=rev
Do you look at buildbot history? It's then obvious that the last non failing
revision, before Hans 's revert, was r1212147 and it began to fail at
r1212266
Do you need more help?
Jacques
From: Hans Bakker mailingl...@antwebsystems.com
Hi Jacopo,
thank you for looking into this.
yes sure i did run ./ant run-install
The test below needs some OrderItemBilling records for order DEMO10091
which specifies an invoiceId.
these records are however not there and therefore the invoiceId is missing.
I can also not find them anywhere in demo or test data
Then i disabled only the test below, and then all following tests in the
same file are failing. Then I went back to a much earlier revision where
the tests are failing tooA revision where i found them working is
892749 from 2009-12-21 . So they seem to be working before...
did you try to run the ./ant run-tests locally ? It looks like buildbot is
missing these tests
Regards,
Hans
On 12/14/2011 01:56 PM, Jacopo Cappellato wrote:
Hans,
did you run ant run-install before ant run-tests?
I suspect that you are getting this error because in your db the order
DEMO10091 is not found.
Jacopo
On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote:
Hi Jacopo,
this is what is reported:
Error Message
ERROR: Could not complete the Test case for Purchase Invoices: editing,
adding taxes and shipping charges and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
00:11:52.971(java.sql.Timestamp)][lastU
pdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
Stacktrace
junit.framework.AssertionFailedError: ERROR: Could not complete the Test
case for Purchase Invoices: editing, adding taxes and shipping charges
and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Hi Hans,
any update on this?
Thanks,
Jacopo
On Dec 14, 2011, at 9:37 AM, Jacopo Cappellato wrote:
Hi Hans,
please see inline:
On Dec 14, 2011, at 8:55 AM, Hans Bakker wrote:
Hi Jacopo,
thank you for looking into this.
yes sure i did run ./ant run-install
The test below needs some OrderItemBilling records for order DEMO10091 which
specifies an invoiceId.
these records are however not there and therefore the invoiceId is missing.
I can also not find them anywhere in demo or test data
I think the invoice (and OrderItemBilling record) is created by the chain of
events caused by the test before that one: testAcctgTransOnPoReceipts
(receipt--shipment--invoice)
Then i disabled only the test below, and then all following tests in the
same file are failing.
Of course they are, because the tests in that group rely on each other.
Then I went back to a much earlier revision where the tests are failing
tooA revision where i found them working is 892749 from 2009-12-21 . So
they seem to be working before...
did you try to run the ./ant run-tests locally ? It looks like buildbot is
missing these tests
Yes, I tested the tests locally:
ant clean-all
ant run-install
ant run-tests
Jacopo
Regards,
Hans
On 12/14/2011 01:56 PM, Jacopo Cappellato wrote:
Hans,
did you run ant run-install before ant run-tests?
I suspect that you are getting this error because in your db the order
DEMO10091 is not found.
Jacopo
On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote:
Hi Jacopo,
this is what is reported:
Error Message
ERROR: Could not complete the Test case for Purchase Invoices: editing,
adding taxes and shipping charges and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
00:11:52.971(java.sql.Timestamp)][lastU
pdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
Stacktrace
junit.framework.AssertionFailedError: ERROR: Could not complete the Test
case for Purchase Invoices: editing, adding taxes and shipping charges and
posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
0
0:11:52.971(java.sql.Timestamp)][lastUpdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required parameter
is missing: [IN] [setInvoiceStatus.invoiceId]]
at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:93)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310)
at org.ofbiz.base.start.Start.start(Start.java:289)
at org.ofbiz.base.start.Start.main(Start.java:119)
Regards,
Hans
On 12/13/2011 10:52 PM, Jacopo Cappellato wrote:
Hans,
could you please be more specific on the errors/failures you are getting?
It seems I was able to run successfully all the tests.
Jacopo
On Dec 13, 2011, at 3:41 PM, Hans Bakker wrote:
Yes a good idea:
https://issues.apache.org/jira/browse/OFBIZ-4624
Regards,
Hans
On 12/13/2011 09:21 PM, Erwan de FERRIERES wrote:
Hans,
could you create an associated Jira issue, so this won't be forgotten ?
Thanks,
2011/12/13
hans
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
No problem: can I re-enable the tests in the meantime?
Jacopo
On Dec 15, 2011, at 2:30 PM, Hans Bakker wrote:
At the moment pretty busy with other things, will have time this weekend or
next week,
On 12/15/2011 08:28 PM, Jacopo Cappellato wrote:
Hi Hans,
any update on this?
Thanks,
Jacopo
On Dec 14, 2011, at 9:37 AM, Jacopo Cappellato wrote:
Hi Hans,
please see inline:
On Dec 14, 2011, at 8:55 AM, Hans Bakker wrote:
Hi Jacopo,
thank you for looking into this.
yes sure i did run ./ant run-install
The test below needs some OrderItemBilling records for order DEMO10091
which specifies an invoiceId.
these records are however not there and therefore the invoiceId is missing.
I can also not find them anywhere in demo or test data
I think the invoice (and OrderItemBilling record) is created by the chain
of events caused by the test before that one: testAcctgTransOnPoReceipts
(receipt--shipment--invoice)
Then i disabled only the test below, and then all following tests in the
same file are failing.
Of course they are, because the tests in that group rely on each other.
Then I went back to a much earlier revision where the tests are failing
tooA revision where i found them working is 892749 from 2009-12-21 .
So they seem to be working before...
did you try to run the ./ant run-tests locally ? It looks like buildbot is
missing these tests
Yes, I tested the tests locally:
ant clean-all
ant run-install
ant run-tests
Jacopo
Regards,
Hans
On 12/14/2011 01:56 PM, Jacopo Cappellato wrote:
Hans,
did you run ant run-install before ant run-tests?
I suspect that you are getting this error because in your db the order
DEMO10091 is not found.
Jacopo
On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote:
Hi Jacopo,
this is what is reported:
Error Message
ERROR: Could not complete the Test case for Purchase Invoices: editing,
adding taxes and shipping charges and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
00:11:52.971(java.sql.Timestamp)][lastU
pdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required
parameter is missing: [IN] [setInvoiceStatus.invoiceId]]
Stacktrace
junit.framework.AssertionFailedError: ERROR: Could not complete the Test
case for Purchase Invoices: editing, adding taxes and shipping charges
and posting to GL
[file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml#testAcctgTransOnEditPoInvoice
] process [problem invoking the [setInvoiceStatus] service with the map
named [serviceCtx] containing
[{userLogin=[GenericEntity:UserLogin][createdStamp,2011-12-13
00:10:24.573(java.sql.Timestamp)][createdTxStamp,2011-12-13
00:10:24.348(java.sql.Timestamp)][currentPassword,null()][disabledDateTime,null()][enabled,N(java.lang.String)][externalAuthId,null()][hasLoggedOut,null()][isSystem,Y(java.lang.String)][lastCurrencyUom,null()][lastLocale,null()][lastTimeZone,null()][lastUpdatedStamp,2011-12-13
0
0:11:52.971(java.sql.Timestamp)][lastUpdatedTxStamp,2011-12-13
00:11:52.86(java.sql.Timestamp)][partyId,system(java.lang.String)][passwordHint,null()][requirePasswordChange,null()][successiveFailedLogins,null()][userLdapDn,null()][userLoginId,system(java.lang.String)],
statusId=INVOICE_READY, locale=en_US}]: The following required
parameter is missing: [IN] [setInvoiceStatus.invoiceId]]
at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:93)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310)
at org.ofbiz.base.start.Start.start(Start.java:289)
at org.ofbiz.base.start.Start.main(Start.java:119)
Regards,
Hans
On 12/13/2011 10:52 PM, Jacopo Cappellato wrote:
Hans,
could you please be more specific on the errors/failures you are
getting?
It seems I was able to run successfully all the tests.
Jacopo
On Dec 13, 2011, at 3:41 PM, Hans Bakker wrote:
Yes a good idea
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
:100) at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146) at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230) at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310) at org.ofbiz.base.start.Start.start(Start.java:289) at org.ofbiz.base.start.Start.main(Start.java:119) Assertion failed: [invoiceTotal=36.43] equals [amount=36] as BigDecimal junit.framework.AssertionFailedError: Assertion failed: [invoiceTotal=36.43] equals [amount=36] as BigDecimal at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:100) at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146) at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230) at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310) at org.ofbiz.base.start.Start.start(Start.java:289) at org.ofbiz.base.start.Start.main(Start.java:119) Assertion failed: [invoiceTotal=127.09] equals [amount=127] as BigDecimal junit.framework.AssertionFailedError: Assertion failed: [invoiceTotal=127.09] equals [amount=127] as BigDecimal at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:100) at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146) at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230) at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310) at org.ofbiz.base.start.Start.start(Start.java:289) at org.ofbiz.base.start.Start.main(Start.java:119) Assertion failed: [invoiceTotal=179.97] equals [amount=179] as BigDecimal junit.framework.AssertionFailedError: Assertion failed: [invoiceTotal=179.97] equals [amount=179] as BigDecimal at org.ofbiz.testtools.SimpleMethodTest.run(SimpleMethodTest.java:100) at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146) at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230) at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310) at org.ofbiz.base.start.Start.start(Start.java:289) at org.ofbiz.base.start.Start.main(Start.java:119) HTH Jacques From: Adrian Crum adrian.c...@sandglass-software.com I agree with Scott. A number of us have tried running the tests with no problem, so it must be a local issue. Let's get them enabled again. -Adrian On 12/15/2011 10:56 PM, Scott Gray wrote: My vote would be to re-enable them regardless, the whole point of the tests is to ensure stability and disabling tests that (allegedly) fail does nothing to further that goal. The correct approach is to find the commit that caused the failure and make a lot of noise to that committer. I'm pretty sure that everyone agrees that we have a responsibility as committers to ensure that we won't cause the tests to fail. Regards Scott On 15/12/2011, at 6:46 AM, Jacopo Cappellato wrote: No problem: can I re-enable the tests in the meantime? Jacopo On Dec 15, 2011, at 2:30 PM, Hans Bakker wrote: At the moment pretty busy with other things, will have time this weekend or next week, On 12/15/2011 08:28 PM, Jacopo Cappellato wrote: Hi Hans, any update on this? Thanks, Jacopo On Dec 14, 2011, at 9:37 AM, Jacopo Cappellato wrote: Hi Hans, please see inline: On Dec 14, 2011, at 8:55 AM, Hans Bakker wrote: Hi Jacopo, thank you for looking into this. yes sure i did run ./ant run-install The test below needs some OrderItemBilling records for order DEMO10091 which specifies an invoiceId. these records are however not there and therefore the invoiceId is missing. I can also not find them anywhere in demo or test data I think the invoice (and OrderItemBilling record) is created by the chain of events caused by the test before that one: testAcctgTransOnPoReceipts (receipt--shipment--invoice) Then i disabled only the test below, and then all following tests in the same file are failing. Of course they are, because the tests in that group rely on each other. Then I went back to a much earlier revision where the tests are failing tooA revision where i found them working is 892749 from 2009-12-21 . So they seem to be working before... did you try to run the ./ant run-tests locally ? It looks like buildbot is missing these tests Yes, I tested the tests locally: ant clean-all ant run-install ant run-tests Jacopo Regards, Hans On 12/14/2011 01:56 PM, Jacopo Cappellato wrote: Hans, did you run ant run-install before ant run-tests? I suspect that you are getting this error because in your db the order DEMO10091 is not found. Jacopo On Dec 13, 2011, at 4:56 PM, Hans Bakker wrote: Hi Jacopo, this is what is reported: Error Message ERROR: Could not complete the Test case for Purchase Invoices: editing, adding taxes and shipping charges and posting to GL [file:/data/jenkins/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Jacques, Hans,
could you please try if with the below modifications the tests are successful?
Thanks,
Jacopo
Index: applications/accounting/testdef/accountingtests.xml
===
--- applications/accounting/testdef/accountingtests.xml (revision 1215052)
+++ applications/accounting/testdef/accountingtests.xml (working copy)
@@ -30,7 +30,7 @@
test-case case-name=accounting-testsjunit-test-suite
class-name=org.ofbiz.accounting.test.FinAccountTests//test-case
!-- commented out for now...test data seems to be missing and i wondered
if theyu ever worked, went back to rev: 903431 and ever there the same problem
--
-!-- test-case case-name=auto-accounting-transaction-tests
+test-case case-name=auto-accounting-transaction-tests
simple-method-test
location=component://accounting/script/org/ofbiz/accounting/test/AutoAcctgTransTests.xml/
-/test-case--
+/test-case
/test-suite
Index: build.xml
===
--- build.xml (revision 1215052)
+++ build.xml (working copy)
@@ -28,6 +28,7 @@
property name=memory.max.param value=-Xmx512M/
property name=pos.memory.max.param value=-Xmx512M/
property name=memory.maxpermsize.param value=-XX:MaxPermSize=512m/
+property name=user.language.param value=-Duser.language=en/
available file=applications/build.xml property=applications.present/
available file=specialpurpose/build.xml
property=specialpurpose.present/
@@ -844,6 +845,7 @@
jvmarg value=${memory.initial.param}/
jvmarg value=${memory.max.param}/
jvmarg value=${memory.maxpermsize.param}/
+jvmarg value=${user.language.param}/
arg value=test/
env key=LC_ALL value=C/
/java
On Dec 16, 2011, at 8:59 AM, Jacopo Cappellato wrote:
ok, this is useful... it is a locale related issue and I am working on it.
Jacopo
On Dec 16, 2011, at 5:45 AM, Jacques Le Roux wrote:
Hi,
on XP 32bits here (*French context*), using
java version 1.6.0_29
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) Client VM (build 20.4-b02, mixed mode, sharing)
with
svn up (r1215035)
ant clean-all run-install run-tests I get
BUILD FAILED
D:\workspace\ofbizClean\build.xml:857: Test run was unsuccessful
Tests Failures Errors Success rate Time
869 17 0 98.04% 401.827
Note: failures are anticipated and checked for with assertions while errors
are unanticipated.
Details:
baseteststestWithVerbosityFailurenested UEL integration(return BigDecimal)
expected:...,234,567 but was:... 234 567,...
junit.framework.ComparisonFailure: nested UEL integration(return BigDecimal)
expected:...,234,567 but was:... 234 567,...
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.doFseTest(FlexibleStringExpanderTests.java:136)
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.fseTest(FlexibleStringExpanderTests.java:196)
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.everythingTest(FlexibleStringExpanderTests.java:338)
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.testWithVerbosity(FlexibleStringExpanderTests.java:264)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310)
at org.ofbiz.base.start.Start.start(Start.java:289)
at org.ofbiz.base.start.Start.main(Start.java:119)
1.031 baseteststestQuietlyFailurenested UEL integration(return BigDecimal)
expected:...,234,567 but was:... 234 567,...
junit.framework.ComparisonFailure: nested UEL integration(return BigDecimal)
expected:...,234,567 but was:... 234 567,...
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.doFseTest(FlexibleStringExpanderTests.java:136)
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.fseTest(FlexibleStringExpanderTests.java:196)
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.everythingTest(FlexibleStringExpanderTests.java:338)
at
org.ofbiz.base.util.string.test.FlexibleStringExpanderTests.testQuietly(FlexibleStringExpanderTests.java:268)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:230)
at org.ofbiz.base.start.Start.startStartLoaders(Start.java:310)
at org.ofbiz.base.start.Start.start(Start.java:289)
at org.ofbiz.base.start.Start.main(Start.java:119)
0.219 baseteststestFlexibleMapAccessorFailurefoo:get expected:The total is
$12,345,678.90. but was:The total is 12 345 678,90
$US.
junit.framework.AssertionFailedError: foo:get expected: but was:
at
org.ofbiz.base.test.GenericTestCaseBase.assertEquals(GenericTestCaseBase.java:343
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Adrian, I doubt that that code is executed when run-tests is called. Jacopo On Dec 16, 2011, at 11:14 AM, Adrian Crum wrote: Jacopo, Setting the language on the command line should not have any effect because OFBiz sets the language when it starts up. See the ofbiz.locale.default setting in start.properties. I can duplicate the test failures by changing that setting to some other locale. That is why I thought it is a local issue - the tests are based on OOTB settings, and if you change the settings the tests will fail. -Adrian On 12/16/2011 9:12 AM, Jacopo Cappellato wrote: Jacques, Hans, could you please try if with the below modifications the tests are successful? Thanks, Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
I am pretty sure it happens because of the locale in your pc: I guess you are not using en, right? Jacopo On Dec 16, 2011, at 11:27 AM, Hans Bakker wrote: tests fail here with OOTB settings On 12/16/2011 05:14 PM, Adrian Crum wrote: Jacopo, Setting the language on the command line should not have any effect because OFBiz sets the language when it starts up. See the ofbiz.locale.default setting in start.properties. I can duplicate the test failures by changing that setting to some other locale. That is why I thought it is a local issue - the tests are based on OOTB settings, and if you change the settings the tests will fail. -Adrian On 12/16/2011 9:12 AM, Jacopo Cappellato wrote: Jacques, Hans, could you please try if with the below modifications the tests are successful? Thanks, Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Hans, please also confirm that the tests are failing even after you have disabled accounting tests... Thanks, Jacopo On Dec 16, 2011, at 11:27 AM, Hans Bakker wrote: tests fail here with OOTB settings On 12/16/2011 05:14 PM, Adrian Crum wrote: Jacopo, Setting the language on the command line should not have any effect because OFBiz sets the language when it starts up. See the ofbiz.locale.default setting in start.properties. I can duplicate the test failures by changing that setting to some other locale. That is why I thought it is a local issue - the tests are based on OOTB settings, and if you change the settings the tests will fail. -Adrian On 12/16/2011 9:12 AM, Jacopo Cappellato wrote: Jacques, Hans, could you please try if with the below modifications the tests are successful? Thanks, Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
No, I meant to say that I am pretty sure that the code that sets the locale is not executed when the tests are run... I am investigating into this now Jacopo On Dec 16, 2011, at 12:39 PM, Adrian Crum wrote: Huh? Start.java is not executed when run-tests is called??!! -Adrian On 12/16/2011 11:15 AM, Jacopo Cappellato wrote: Adrian, I doubt that that code is executed when run-tests is called. Jacopo On Dec 16, 2011, at 11:14 AM, Adrian Crum wrote: Jacopo, Setting the language on the command line should not have any effect because OFBiz sets the language when it starts up. See the ofbiz.locale.default setting in start.properties. I can duplicate the test failures by changing that setting to some other locale. That is why I thought it is a local issue - the tests are based on OOTB settings, and if you change the settings the tests will fail. -Adrian On 12/16/2011 9:12 AM, Jacopo Cappellato wrote: Jacques, Hans, could you please try if with the below modifications the tests are successful? Thanks, Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Yes, right, a few minutes ago I have committed the fix you suggested. I doubt it will fix the issue Jacques reported... but that may be unrelated to locale Jacques, is there any chance that you have some local modifications? Jacopo On Dec 16, 2011, at 3:17 PM, Adrian Crum wrote: There is no need to investigate - I wrote that code and I can assure you the locale and time zone is always set when OFBiz starts. The problem is an incorrect (or missing) setting in one of the properties files - see my previous reply to Jacques. -Adrian On 12/16/2011 1:43 PM, Jacopo Cappellato wrote: No, I meant to say that I am pretty sure that the code that sets the locale is not executed when the tests are run... I am investigating into this now Jacopo On Dec 16, 2011, at 12:39 PM, Adrian Crum wrote: Huh? Start.java is not executed when run-tests is called??!! -Adrian On 12/16/2011 11:15 AM, Jacopo Cappellato wrote: Adrian, I doubt that that code is executed when run-tests is called. Jacopo On Dec 16, 2011, at 11:14 AM, Adrian Crum wrote: Jacopo, Setting the language on the command line should not have any effect because OFBiz sets the language when it starts up. See the ofbiz.locale.default setting in start.properties. I can duplicate the test failures by changing that setting to some other locale. That is why I thought it is a local issue - the tests are based on OOTB settings, and if you change the settings the tests will fail. -Adrian On 12/16/2011 9:12 AM, Jacopo Cappellato wrote: Jacques, Hans, could you please try if with the below modifications the tests are successful? Thanks, Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Hi Jacques,
I suspect this is a problem with the end of line... are you running on Windows?
Could you please try if the patch below fixes the test?
Thanks,
Jacopo
Index: framework/base/src/org/ofbiz/base/util/test/UtilIOTests.java
===
--- framework/base/src/org/ofbiz/base/util/test/UtilIOTests.java
(revision 1215052)
+++ framework/base/src/org/ofbiz/base/util/test/UtilIOTests.java
(working copy)
@@ -39,6 +39,7 @@
@SourceMonitored
public class UtilIOTests extends GenericTestCaseBase {
+private String lineSeparator = System.getProperty(line.separator);
private static final byte[] trademarkBytes = new byte[] {
(byte) 0xE2, (byte) 0x84, (byte) 0xA2
};
@@ -152,7 +153,7 @@
}
public void testReadWriteObject() throws Exception {
-checkBasicReadWriteObject(Boolean.TRUE, java.lang.Boolean:true\n);
+checkBasicReadWriteObject(Boolean.TRUE, java.lang.Boolean:true +
lineSeparator);
checkBasicReadWriteObject(Byte.valueOf(1), java.lang.Byte:1\n);
checkBasicReadWriteObject(Double.valueOf(1.0),
java.lang.Double:1.0\n);
checkBasicReadWriteObject(Float.valueOf(1.0),
java.lang.Float:1.0\n);
On Dec 16, 2011, at 5:51 PM, Jacques Le Roux wrote:
Same Boolean issue as expected
Jacques
From: Jacques Le Roux jacques.le.r...@les7arts.com
OK Guys,
I will check that tonight...
Thanks for the effort!
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
I believe the base test failures are a timing issue, but I can't be sure
because I haven't looked into it thoroughly. I am
confident they have nothing to do with locale, however.
-Adrian
On 12/16/2011 2:25 PM, Jacopo Cappellato wrote:
Yes, right, a few minutes ago I have committed the fix you suggested.
I doubt it will fix the issue Jacques reported... but that may be
unrelated to locale Jacques, is there any chance that you
have some local modifications?
Jacopo
On Dec 16, 2011, at 3:17 PM, Adrian Crum wrote:
There is no need to investigate - I wrote that code and I can assure you
the locale and time zone is always set when OFBiz
starts. The problem is an incorrect (or missing) setting in one of the
properties files - see my previous reply to Jacques.
-Adrian
On 12/16/2011 1:43 PM, Jacopo Cappellato wrote:
No, I meant to say that I am pretty sure that the code that sets the
locale is not executed when the tests are run... I am
investigating into this now
Jacopo
On Dec 16, 2011, at 12:39 PM, Adrian Crum wrote:
Huh? Start.java is not executed when run-tests is called??!!
-Adrian
On 12/16/2011 11:15 AM, Jacopo Cappellato wrote:
Adrian,
I doubt that that code is executed when run-tests is called.
Jacopo
On Dec 16, 2011, at 11:14 AM, Adrian Crum wrote:
Jacopo,
Setting the language on the command line should not have any effect
because OFBiz sets the language when it starts up. See
the ofbiz.locale.default setting in start.properties.
I can duplicate the test failures by changing that setting to some
other locale. That is why I thought it is a local issue -
the tests are based on OOTB settings, and if you change the settings
the tests will fail.
-Adrian
On 12/16/2011 9:12 AM, Jacopo Cappellato wrote:
Jacques, Hans,
could you please try if with the below modifications the tests are
successful?
Thanks,
Jacopo
Re: svn commit: r1213650 - /ofbiz/trunk/applications/accounting/testdef/accountingtests.xml
Thanks Jacques... are you sure it is happening at the same line (156) and not
in the next (157) that it is still using the hardcoded '\n'?
Jacopo
On Dec 17, 2011, at 8:22 AM, Jacques Le Roux wrote:
Hi Jacopo,
Unfortunately not: same error, pretty vicious thing, sorry no time to help
today :/
Jacques
From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
Hi Jacques,
I suspect this is a problem with the end of line... are you running on
Windows? Could you please try if the patch below fixes the test?
Thanks,
Jacopo
Index: framework/base/src/org/ofbiz/base/util/test/UtilIOTests.java
===
--- framework/base/src/org/ofbiz/base/util/test/UtilIOTests.java (revision
1215052)
+++ framework/base/src/org/ofbiz/base/util/test/UtilIOTests.java (working
copy)
@@ -39,6 +39,7 @@
@SourceMonitored
public class UtilIOTests extends GenericTestCaseBase {
+private String lineSeparator = System.getProperty(line.separator);
private static final byte[] trademarkBytes = new byte[] {
(byte) 0xE2, (byte) 0x84, (byte) 0xA2
};
@@ -152,7 +153,7 @@
}
public void testReadWriteObject() throws Exception {
-checkBasicReadWriteObject(Boolean.TRUE, java.lang.Boolean:true\n);
+checkBasicReadWriteObject(Boolean.TRUE, java.lang.Boolean:true +
lineSeparator);
checkBasicReadWriteObject(Byte.valueOf(1), java.lang.Byte:1\n);
checkBasicReadWriteObject(Double.valueOf(1.0),
java.lang.Double:1.0\n);
checkBasicReadWriteObject(Float.valueOf(1.0),
java.lang.Float:1.0\n);
On Dec 16, 2011, at 5:51 PM, Jacques Le Roux wrote:
Same Boolean issue as expected
Jacques
From: Jacques Le Roux jacques.le.r...@les7arts.com
OK Guys,
I will check that tonight...
Thanks for the effort!
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
I believe the base test failures are a timing issue, but I can't be sure
because I haven't looked into it thoroughly. I am
confident they have nothing to do with locale, however.
-Adrian
On 12/16/2011 2:25 PM, Jacopo Cappellato wrote:
Yes, right, a few minutes ago I have committed the fix you suggested.
I doubt it will fix the issue Jacques reported... but that may be
unrelated to locale Jacques, is there any chance that you
have some local modifications?
Jacopo
On Dec 16, 2011, at 3:17 PM, Adrian Crum wrote:
There is no need to investigate - I wrote that code and I can assure
you the locale and time zone is always set when OFBiz
starts. The problem is an incorrect (or missing) setting in one of the
properties files - see my previous reply to Jacques.
-Adrian
On 12/16/2011 1:43 PM, Jacopo Cappellato wrote:
No, I meant to say that I am pretty sure that the code that sets the
locale is not executed when the tests are run... I am
investigating into this now
Jacopo
On Dec 16, 2011, at 12:39 PM, Adrian Crum wrote:
Huh? Start.java is not executed when run-tests is called??!!
-Adrian
On 12/16/2011 11:15 AM, Jacopo Cappellato wrote:
Adrian,
I doubt that that code is executed when run-tests is called.
Jacopo
On Dec 16, 2011, at 11:14 AM, Adrian Crum wrote:
Jacopo,
Setting the language on the command line should not have any effect
because OFBiz sets the language when it starts up. See
the ofbiz.locale.default setting in start.properties.
I can duplicate the test failures by changing that setting to some
other locale. That is why I thought it is a local issue -
the tests are based on OOTB settings, and if you change the
settings the tests will fail.
-Adrian
On 12/16/2011 9:12 AM, Jacopo Cappellato wrote:
Jacques, Hans,
could you please try if with the below modifications the tests are
successful?
Thanks,
Jacopo
Re: svn commit: r1220622 - in /ofbiz/trunk: applications/manufacturing/data/ applications/order/src/org/ofbiz/order/order/ applications/order/src/org/ofbiz/order/shoppingcart/ applications/order/webap
Yep,
the problem was the line:
-ProductFeatureCategory productFeatureCategoryId=IMAGE
description=Image/
+ProductFeatureCategory productFeatureCategoryI=IMAGE
description=Image/
I have fixed it.
Even without reviewing this big commit, this kind of errors (that imply that
very few tests were done) makes me feel nervous about the quality of the code
committed.
Jacopo
On Dec 19, 2011, at 9:24 AM, Adrian Crum wrote:
This commit is throwing a lot of exceptions during data loading. See the
buildbot report.
-Adrian
On 12/19/2011 6:40 AM, hans...@apache.org wrote:
Author: hansbak
Date: Mon Dec 19 06:40:18 2011
New Revision: 1220622
URL: http://svn.apache.org/viewvc?rev=1220622view=rev
Log:
new producttype: configurable product service, using inventory
Modified:
ofbiz/trunk/applications/manufacturing/data/ManufacturingExampleData.xml
ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderServices.java
ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutHelper.java
ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/ShoppingCart.java
ofbiz/trunk/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/Product.groovy
ofbiz/trunk/applications/order/webapp/ordermgr/entry/catalog/productsummary.ftl
ofbiz/trunk/applications/product/data/ProductTypeData.xml
ofbiz/trunk/applications/product/script/org/ofbiz/shipment/issuance/IssuanceServices.xml
ofbiz/trunk/applications/product/script/org/ofbiz/shipment/receipt/ShipmentReceiptServices.xml
ofbiz/trunk/applications/product/src/org/ofbiz/product/config/ProductConfigWrapper.java
ofbiz/trunk/applications/product/src/org/ofbiz/product/product/ProductWorker.java
ofbiz/trunk/specialpurpose/ecommerce/data/DemoProduct.xml
Modified:
ofbiz/trunk/applications/manufacturing/data/ManufacturingExampleData.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/manufacturing/data/ManufacturingExampleData.xml?rev=1220622r1=1220621r2=1220622view=diff
==
--- ofbiz/trunk/applications/manufacturing/data/ManufacturingExampleData.xml
(original)
+++ ofbiz/trunk/applications/manufacturing/data/ManufacturingExampleData.xml
Mon Dec 19 06:40:18 2011
@@ -45,6 +45,11 @@ under the License.
FixedAsset fixedAssetId=DEMO_PROD_EQUIPMT_2 fixedAssetName=Demo
Production Equipment Two fixedAssetTypeId=PRODUCTION_EQUIPMENT
dateAcquired=2005-01-01 00:01:00.0 expectedEndOfLife=2010-01-01
calendarId=DEMO_CALENDAR salvageValue=50 purchaseCost=1000
purchaseCostUomId=USD/
FixedAssetGeoPoint fixedAssetId=DEMO_PROD_EQUIPMT_2
geoPointId=9000 fromDate=2009-01-09 00:00:00.000/
+FixedAsset fixedAssetId=DEMO_BOOK_GROUP
fixedAssetTypeId=GROUP_EQUIPMENT fixedAssetName=Demo Book Group/
+FixedAssetGeoPoint fixedAssetId=DEMO_BOOK_GROUP geoPointId=9000
fromDate=2011-08-02 00:00:00.000/
+FixedAsset fixedAssetId=DEMO_BOOK fixedAssetName=Demo Book
fixedAssetTypeId=PRODUCTION_EQUIPMENT parentFixedAssetId=DEMO_BOOK_GROUP
calendarId=DEMO_CALENDAR purchaseCost=200 purchaseCostUomId=USD/
+FixedAssetGeoPoint fixedAssetId=DEMO_BOOK geoPointId=9000
fromDate=2011-08-02 00:00:00.000/
+
FixedAssetDepMethod depreciationCustomMethodId=STR_LINE_DEP_FORMULA
fixedAssetId=DEMO_PROD_EQUIPMT_1/
FixedAssetDepMethod depreciationCustomMethodId=DBL_DECL_DEP_FORMULA
fixedAssetId=DEMO_PROD_EQUIPMT_2/
/entity-engine-xml
Modified:
ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderServices.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderServices.java?rev=1220622r1=1220621r2=1220622view=diff
==
---
ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderServices.java
(original)
+++
ofbiz/trunk/applications/order/src/org/ofbiz/order/order/OrderServices.java
Mon Dec 19 06:40:18 2011
@@ -1138,7 +1138,7 @@ public class OrderServices {
String productId = (String) orderItem.get(productId);
GenericValue product =
delegator.getRelatedOne(Product, orderItem);
-
if(SERVICE_PRODUCT.equals(product.get(productTypeId))){
+
if(SERVICE_PRODUCT.equals(product.get(productTypeId)) ||
AGGREGATEDSERV_CONF.equals(product.get(productTypeId))){
String inventoryFacilityId = null;
if
(Y.equals(productStore.getString(oneInventoryFacility))) {
inventoryFacilityId =
productStore.getString(inventoryFacilityId);
Modified:
ofbiz/trunk/applications/order/src/org/ofbiz/order/shoppingcart/CheckOutHelper.java
URL:
Re: remove ant from ofbiz
Hi Hans, what I don't like is that this will add a new system requirement for the user. Why not upgrading the embedded version instead? Jacopo On Dec 22, 2011, at 4:23 AM, Hans Bakker wrote: Hi community, the version of Ant distributed with ofbiz is pretty old and has some disadvantages: 1. does not support the failonerror=true on te patch command 2. difficult command line when using apply-ofbiz-patches: ../../ant apply-ofbiz-patches i tested using the ant version 1.8.2 and it seems to work fine. why not remove it and use the standard ant install? could still have the ant command to redirect to the external ant opinions please? regards, Hans
Re: buildbot failure in ASF Buildbot on ofbiz-trunk
Hi Jacques, the failure could be related to the year switch... this happens every year and it needs some updates to demo fiscal periods to fix; or you could try with a patch like: Index: applications/accounting/data/DemoGlSetupData.xml === --- applications/accounting/data/DemoGlSetupData.xml(revision 1226294) +++ applications/accounting/data/DemoGlSetupData.xml(working copy) @@ -398,7 +398,7 @@ CustomTimePeriod organizationPartyId=Company customTimePeriodId=6012 periodTypeId=FISCAL_QUARTER fromDate=2010-04-01 thruDate=2010-07-01 isClosed=N periodNum=3 periodName=2010/Q2 parentPeriodId=6010/ CustomTimePeriod organizationPartyId=Company customTimePeriodId=6013 periodTypeId=FISCAL_QUARTER fromDate=2010-07-01 thruDate=2010-10-01 isClosed=N periodNum=4 periodName=2010/Q3 parentPeriodId=6010/ CustomTimePeriod organizationPartyId=Company customTimePeriodId=6014 periodTypeId=FISCAL_QUARTER fromDate=2010-10-01 thruDate=2011-01-01 isClosed=N periodNum=5 periodName=2010/Q4 parentPeriodId=6010/ -CustomTimePeriod organizationPartyId=Company customTimePeriodId=6015 periodTypeId=FISCAL_YEAR fromDate=2011-01-01 thruDate=2012-01-01 isClosed=N periodNum=1 periodName=2011/ +CustomTimePeriod organizationPartyId=Company customTimePeriodId=6015 periodTypeId=FISCAL_YEAR fromDate=2011-01-01 thruDate=2020-01-01 isClosed=N periodNum=1 periodName=2011/ CustomTimePeriod organizationPartyId=Company customTimePeriodId=6016 periodTypeId=FISCAL_QUARTER fromDate=2011-01-01 thruDate=2011-04-01 isClosed=N periodNum=2 periodName=2011/Q1 parentPeriodId=6015/ CustomTimePeriod organizationPartyId=Company customTimePeriodId=6017 periodTypeId=FISCAL_QUARTER fromDate=2011-04-01 thruDate=2011-07-01 isClosed=N periodNum=3 periodName=2011/Q2 parentPeriodId=6015/ CustomTimePeriod organizationPartyId=Company customTimePeriodId=6018 periodTypeId=FISCAL_QUARTER fromDate=2011-07-01 thruDate=2011-10-01 isClosed=N periodNum=4 periodName=2011/Q3 parentPeriodId=6015/ that should fix the issue once for all... but I didn't test it yet and so there may be other changes required; but if you are looking into the issue it may be useful, if not I will review the issue tomorrow. Kind regards Jacopo On Jan 1, 2012, at 12:31 PM, Jacques Le Roux wrote: It's only 4 BigDecimal comparaisons issues in tests, I'm looking at it... Jacques From: build...@apache.org The Buildbot has detected a new failure on builder ofbiz-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-trunk/builds/2460 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: isis_ubuntu Build Reason: scheduler Build Source Stamp: [branch ofbiz/trunk] 1226223 Blamelist: jleroux BUILD FAILED: failed compile_1 sincerely, -The Buildbot
Re: svn commit: r1226367 - in /ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test: AutoInvoiceTests.xml AutoPaymentTests.xml
Jacques, I am going to commit a different fix that should make the tests good for the years to come. Jacopo On Jan 2, 2012, at 9:29 AM, jler...@apache.org wrote: Author: jleroux Date: Mon Jan 2 08:29:59 2012 New Revision: 1226367 URL: http://svn.apache.org/viewvc?rev=1226367view=rev Log: This should fix invopice and payment tests following r1055057, thanks for the idea Adrian! Modified: ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoInvoiceTests.xml ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoPaymentTests.xml Modified: ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoInvoiceTests.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoInvoiceTests.xml?rev=1226367r1=1226366r2=1226367view=diff == --- ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoInvoiceTests.xml (original) +++ ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoInvoiceTests.xml Mon Jan 2 08:29:59 2012 @@ -184,8 +184,8 @@ under the License. /entity-one set field=getAcctgTransEntriesAndTransTotalMap.userLogin from-field=userLogin/ set field=getAcctgTransEntriesAndTransTotalMap.organizationPartyId value=Company/ -set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodStartDate value=2011-01-01 16:55:01.0 type=Timestamp/ -set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodEndDate value=2011-12-31 16:55:01.0 type=Timestamp/ +set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodStartDate value=2012-01-01 16:55:01.0 type=Timestamp/ +set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodEndDate value=2012-12-31 16:55:01.0 type=Timestamp/ set field=getAcctgTransEntriesAndTransTotalMap.glAccountId value=21/ call-service service-name=getAcctgTransEntriesAndTransTotal in-map-name=getAcctgTransEntriesAndTransTotalMap result-to-field result-name=debitTotal field=payableDebitTotal/ @@ -252,8 +252,8 @@ under the License. /entity-one set field=getAcctgTransEntriesAndTransTotalMap.userLogin from-field=userLogin/ set field=getAcctgTransEntriesAndTransTotalMap.organizationPartyId value=Company/ -set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodStartDate value=2011-01-01 16:55:01.0 type=Timestamp/ -set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodEndDate value=2011-12-31 16:55:01.0 type=Timestamp/ +set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodStartDate value=2012-01-01 16:55:01.0 type=Timestamp/ +set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodEndDate value=2012-12-31 16:55:01.0 type=Timestamp/ set field=getAcctgTransEntriesAndTransTotalMap.glAccountId value=21/ call-service service-name=getAcctgTransEntriesAndTransTotal in-map-name=getAcctgTransEntriesAndTransTotalMap result-to-field result-name=debitTotal field=payableDebitTotal/ Modified: ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoPaymentTests.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoPaymentTests.xml?rev=1226367r1=1226366r2=1226367view=diff == --- ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoPaymentTests.xml (original) +++ ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/test/AutoPaymentTests.xml Mon Jan 2 08:29:59 2012 @@ -350,8 +350,8 @@ under the License. /entity-one set field=getAcctgTransEntriesAndTransTotalMap.userLogin from-field=userLogin/ set field=getAcctgTransEntriesAndTransTotalMap.organizationPartyId value=Company/ -set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodStartDate value=2011-01-01 16:55:01.0 type=Timestamp/ -set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodEndDate value=2011-12-31 16:55:01.0 type=Timestamp/ +set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodStartDate value=2012-01-01 16:55:01.0 type=Timestamp/ +set field=getAcctgTransEntriesAndTransTotalMap.customTimePeriodEndDate value=2012-12-31 16:55:01.0 type=Timestamp/ set field=getAcctgTransEntriesAndTransTotalMap.glAccountId value=12/ call-service service-name=getAcctgTransEntriesAndTransTotal in-map-name=getAcctgTransEntriesAndTransTotalMap result-to-field result-name=debitTotal field=receivableDebitTotal/ @@ -422,8 +422,8 @@ under the License. /entity-one set
Re: releases
Hi Erwan, I agree it would be nice to release. We could release: * a new bug fix release for the 09 series (named 09.04.02) * a new bug fix release for the 10 series (named 10.04.01) * the first release for the 11 series (named 11.04) To avoid confusion we could do one release per month or similar and I am wide open to any preference on the order. Kind regards, Jacopo On Jan 5, 2012, at 9:46 AM, Erwan de FERRIERES wrote: Hi devs, we haven't released any new OFBiz version since the 10.04. Should we vote for the 11.04 and release it ? Should we mark the 4.0 as no more supported, and then keep only 3 releases (9, 10 and 11) ? BTW, happy new year ! -- Erwan de FERRIERES
Re: releases
On Jan 6, 2012, at 3:39 PM, Erwan de FERRIERES wrote: If we are adding the 11.04, then there will be 4 different versions. It may be useful to help the user to decide which one to take. And reducing the choice can be one way to do it. This is a good point and I agree that we should improve the structure and information in the download page to highlight the newer and more actively maintained releases. Jacopo
Re: Stop The Madness: Indexing keyword EECAs
There is a flag in the Product entity that can beused to prevent the creation of product keywords; unfortunately the flag is ignored by the eca associated to the features of the product (imo this is something we should fix). Kind regards, Jacopo On Jan 14, 2012, at 1:59 AM, Adrian Crum wrote: I tried to find out why a data import for a bespoke (made-to-order) manufacturer was taking WAY too long. Turns out it was keyword indexing EECAs. Each product has dozens of product features, and it also has a manufacturer ID. The indexProductKeywords is called for the product, each product feature, and the ID. As a result, one product takes several seconds to store. Then the BOM for each product needs to be imported. The indexWorkEffortKeywords service is called for each work effort in the BOM. Why do I want my BOM work efforts keyword indexed? This is insane. Why would anyone set up EECAs like that? I would like to turn those EECA services into jobs that run on a regular basis, so real work can get done in real time. What do you think? -Adrian
Re: The Apache Software Foundation Projects
Hi Jacques, sorry for the late reply; Erwan is right about the tag: we create it when we tag a release. As regards you patch, please commit it and then deploy (as you would do with a standard html page of the OFBiz website); the ASF server will then fetch it from there. Thanks, Jacopo On Jan 22, 2012, at 1:07 AM, Jacques Le Roux wrote: Since R11.04 is not yet official, the patch would be rather Index: doap_OFBiz.rdf === --- doap_OFBiz.rdf (revision 1214648) +++ doap_OFBiz.rdf (working copy) @@ -50,9 +50,30 @@ foaf:mbox rdf:resource=mailto:jaco...@apache.org/ /foaf:Person /maintainer +!--release +Version +nameApache OFBiz 11.04/name +created2011-05-02/created +revision11.04/revision +/Version +/release-- release Version -nameLast stable/name +name(Last stable) Apache OFBiz 10.04/name +created2010-05-01/created +revision10.04/revision +/Version +/release+release +Version +name(Lastest 09.04) Apache OFBiz 09.04.01 /name +created2011-01-25/created +revision09.04.01/revision +/Version +/release +release +Version +nameApache OFBiz R09.04/name created2009-04-01/created revision09.04/revision /Version Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com I created this patch. Is committing and updating /www/ofbiz.apache.org/ enough? Index: doap_OFBiz.rdf === --- doap_OFBiz.rdf (revision 1214648) +++ doap_OFBiz.rdf (working copy) @@ -52,7 +52,27 @@ /maintainer release Version -nameLast stable/name +nameApache OFBiz 11.04/name +created2011-05-02/created +revision11.04/revision +/Version +/release +Version +name(Last stable) Apache OFBiz 10.04/name +created2010-05-01/created +revision10.04/revision +/Version +/release +release +Version +name(Lastest 09.04) Apache OFBiz 09.04.01 /name +created2011-01-25/created +revision09.04.01/revision +/Version +/release +release +Version +nameApache OFBiz R09.04/name created2009-04-01/created revision09.04/revision /Version Using svn log --stop-on-copy creation.date to get the date at the bottom of creation.date file (tip from Bertrand http://grep.codeconsult.ch/2008/11/26/what-svn-revision-was-this-branch-created-in/) Jacques From: Jacques Le Roux jacques.le.r...@les7arts.com Hi Jacopo, Just stumbled upon http://projects.apache.org/projects/ofbiz.html Should we not update regarding releases? Should be only stable releases there? But then why showing 4.0. Just let me know and I will update... Thanks Jacques
Re: svn commit: r1230793 - in /ofbiz/trunk/specialpurpose/scrum: ./ config/ data/ data/hookscripts/ entitydef/ servicedef/ src/org/ofbiz/scrum/ templates/ testdef/ webapp/demotest/ webapp/demotest/WEB
I agree, it is useful and I use it a lot before tagging a release. Jacopo On Jan 12, 2012, at 11:13 PM, Jacques Le Roux wrote: Yes a great tool really! At least for Apache committers... Jacques From: Adrian Crum adrian.c...@sandglass-software.com I'm familiar with RAT - I use it for the Commons Convert project. -Adrian On 1/12/2012 9:48 PM, Erwan de FERRIERES wrote: Le 12/01/2012 22:41, Adrian Crum a écrit : Erwan, Thank you for taking care of that. -Adrian You're welcome ! But I'm not alone, RAT (http://incubator.apache.org/rat) is helping me !! On 1/12/2012 9:29 PM, er...@apache.org wrote: Author: erwan Date: Thu Jan 12 21:29:51 2012
Welcome Erwan De Ferrieres as a new OFBiz PMC member
Welcome to Erwan as our new OFBiz PMC member. The current members of the OFBiz PMC have voted in favour of inviting Erwan to join the PMC, the vote has been approved by the ASF Board and Erwan has accepted our invitation. Thank you Erwan and thank you Jacques for your proposal. Kind regards, Jacopo
Re: Alternatives to using UserLoginId as a primary key
I like Adrian's proposal to make the UserLogin entity more flexible. Brett, as regards your proposal about the extension mechanism (i.e. the UserCredentials), I think it would be better an approach where each specific security implementation defines its own *Credentials (or *UserLogin or *Authentication or some other name) entity as an extension to the UserLogin for that authenticationTypeId (instead of attempting to define a general purpose UserCredentials entity). For example, for a UserLogin record for LDAP (i.e. authenticationTypeId=LDAP) we could have a corresponding record in the LdapUserLogin record; for a UserLogin record for OpenId we could have a corresponding record in the OpenIdUserLogin record etc... you could define your own for the specific security you are working on. Kind regards, Jacopo On Feb 20, 2012, at 8:38 AM, Adrian Crum wrote: As far as I know, there are two LDAP authentication implementations - one that I worked on a while back that can be found in the framework, and a CAS-LDAP one that can be found in specialpurpose. There is also a SSO implementation and some X509 stuff. -Adrian On 2/20/2012 3:32 AM, Brett Palmer wrote: Adrian, Yes, that approach would work for us as well. I like the generic authentication approach which opens it up for OpenId, LDAP, and custom authentication methods without changing how authorization in ofbiz is performed. A you proposing that we refactor the UserLogin entity, removing the custom fields and introduce a new entity like UserCredentials? That would work for us. We need to implement this type of solution for our application. We would prefer a solution that would be adopted by the community as an alternative login approach when needed. We would be happy to contribute this solution back to the community. What else has already been done in this area so we can avoid duplicating anyone's efforts or at least continue where they left off? We could create a proof of concept implementation and then post it to the community for review. We would like suggestions and feedback early so we can avoid large changes after the POC is complete. Let me know the best way to proceed with this effort. Thanks, Brett On Sun, Feb 19, 2012 at 2:30 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Brett, This opens up the possibility to solve another problem - supporting alternate authentication systems (like LDAP, etc). Right now the userLogin entity includes OFBiz credentials (login name, password), LDAP credentials (DN), and some other credentials that Andrew added. From my perspective, it might be best to use the UserLogin entity only for persisting a user, and have the credentials stored in another entity. The UserLogin entity could then support any number of authentication schemes: UserCredentials --- userLoginId* authenticationTypeId* fromDate* thruDate loginName password Would something like that solve your problem? -Adrian On 2/19/2012 6:51 AM, Brett Palmer wrote: Sakthi, Thanks for the quick reply. The system generated UserIds would not be visible to the user. They would just be used by the system to use ofbiz existing authentication and security features. Our application is not a typical ecommerce app but one that is used by students and teachers for testing. The students are suppose to use their personal userID assigned to them but these are often not remembered and so errors occur. Here is what I am proposing for our solution: 1. Add new fields to the UserLoginId table that will allow us to determine uniqueness within their particular organization. For example, a district ID and a studentID. 2. Create custom authentication method to handle the de-references of the student's studentId and districtId to determine the actual system Id. 3. Verify the password matches the one in the UserLogin table. 5. Get the UserLogin GenericValue and store in a session so ofbiz authentication and security features work. Now when a person calls to say their userId was incorrectly entered we can quickly update their UserId because the ID the student uses is not the primary key. Let me know if anyone sees anything wrong with this approach. Brett On Fri, Feb 17, 2012 at 5:57 AM, Integrin Solutionsinfo.integrin@gmail.* *cominfo.integ...@gmail.com wrote: Brett - My thoughts - - System generated UserIds might be hard for the users to remember; - Changing UsersIds of a Person is not that difficult afterall; You might want to assign a new UserId to the Userfrom PartyManager and disable the existing one; - Sakthi On 2/17/12, Brett Palmerbrettgpal...@gmail.com wrote: We have an application based on the ofbiz framework for online testing. We use the ofbiz user authentication and userLoginId as designed by ofbiz. The problem is that often teachers and students
Proposal about a time based release plan
Hi all, I would like to share some ideas I have to make our release plan more clearer, public and well defined. This plan doesn't require additional work from the community (apart from the due diligence when we will call for votes) because I will take care about preparing release candidate files, sign them and call for votes; then publish them if the vote is successful. This is basically what we did in the last 2 years with the only (big) difference that the release schedule will be decided and announced in advance on fixed dates. For example, we could decide that during the year 2012 (the same scheme could be used for 2013 etc...) we will issue a release from each branch every 4 months like this: * release 11.04 around 2012-04-15 * release 11.04.01 around 2012-08-15 * release 11.04.02 around 2012-12-15 * release 10.04.01 around 2012-03-15 * release 10.04.02 around 2012-07-15 * release 10.04.03 around 2012-11-15 * release 09.04.02 around 2012-02-15 * release 09.04.03 around 2012-06-15 * release 09.04.04 around 2012-10-15 Or we could decide on a less aggressive schedule and release each branch every 6 months etc... And we could also vote in advance for the time a release branch will be closed: for example we could vote that the community will not release and apply patches to the release branch 09.04 after the release 09.04.04 (this is just an example as I would like to propose to close the 09.04 branch earlier than this). New patches/contributions (always welcome) for that branch (after it is closed) will not be applied to the branch and will stay in Jira for interested parties (unless the community will decide to reopen it). In this way users will know in advance when a branch will be deprecated, how many bug fix releases will be issued and based on this information could prepare in time for the upgrades (or switch between major releases). Of course there will be exceptions: maybe we will have to release out of schedule to fix some major security issues or we could skip a release if no changes since the previous one were committed etc... When the plan is in place we could then prepare a nice roadmap diagram to be published in our Download page. The roadmap will not be feature based and for this reason it should be doable with the current structure and resources we have in the community: I know it would be also nice to plan and work together on a features set, but this will definitely require more coordination, agreement and effort... we can (and should) always try to do that also but this is another topic (for another thread). In the meantime, with this time based release plan we will have something real to play with. Please let me know what you think. Thanks, Jacopo
Proposal to slightly change the naming convention for releases
Hi all, I would like to propose a small change to the way we name releases, specifically the first release in a branch. The current naming convention is the following: a) the name of the release branch is apache-ofbiz-YY.MM where YY.MM is the year and month of when the branch was created b) all releases coming out from a branch have the major release number equal to the branch's YY.MM c) the first release in the branch doesn't have a minor release number; the name of the first release is then: apache-ofbiz-YY.MM d) all subsequent releases (second, third etc...) have a sequential 2-digits minor release number (01, 02,...): the second release is apache-ofbiz-YY.MM.01, the third release is apache-ofbiz-YY.MM.02 etc... I would like to change the rules to be: a) the name of the release branch is apache-ofbiz-YY.MM where YY.MM is the year and month of when the branch was created b) all releases coming out from a branch have a major release number equal to the branch's YY.MM and a minor release number (sequential 2-digits): the first release is apache-ofbiz-YY.MM.01, the second release is apache-ofbiz-YY.MM.02 etc... We could start the adoption of the new naming convention with the upcoming (April?) first release in the 11.04 branch: instead of apache-ofbiz-11.04 it will be apache-ofbiz-11.04.01. What do you think? Jacopo
Re: Alternatives to using UserLoginId as a primary key
If we are talking about the trunk and there are no objections or better ideas I would be in favor of refactoring the existing security implementation to use the new model. Regards, Jacopo On Feb 21, 2012, at 2:18 AM, Brett Palmer wrote: Jacopo, That sounds like a good approach. We'll look at an extension of the UserLogin entity with a specific type. Is the current LDAP implementation following that model or would this be something new? Thanks, Brett On Mon, Feb 20, 2012 at 5:59 AM, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: I like Adrian's proposal to make the UserLogin entity more flexible. Brett, as regards your proposal about the extension mechanism (i.e. the UserCredentials), I think it would be better an approach where each specific security implementation defines its own *Credentials (or *UserLogin or *Authentication or some other name) entity as an extension to the UserLogin for that authenticationTypeId (instead of attempting to define a general purpose UserCredentials entity). For example, for a UserLogin record for LDAP (i.e. authenticationTypeId=LDAP) we could have a corresponding record in the LdapUserLogin record; for a UserLogin record for OpenId we could have a corresponding record in the OpenIdUserLogin record etc... you could define your own for the specific security you are working on. Kind regards, Jacopo On Feb 20, 2012, at 8:38 AM, Adrian Crum wrote: As far as I know, there are two LDAP authentication implementations - one that I worked on a while back that can be found in the framework, and a CAS-LDAP one that can be found in specialpurpose. There is also a SSO implementation and some X509 stuff. -Adrian On 2/20/2012 3:32 AM, Brett Palmer wrote: Adrian, Yes, that approach would work for us as well. I like the generic authentication approach which opens it up for OpenId, LDAP, and custom authentication methods without changing how authorization in ofbiz is performed. A you proposing that we refactor the UserLogin entity, removing the custom fields and introduce a new entity like UserCredentials? That would work for us. We need to implement this type of solution for our application. We would prefer a solution that would be adopted by the community as an alternative login approach when needed. We would be happy to contribute this solution back to the community. What else has already been done in this area so we can avoid duplicating anyone's efforts or at least continue where they left off? We could create a proof of concept implementation and then post it to the community for review. We would like suggestions and feedback early so we can avoid large changes after the POC is complete. Let me know the best way to proceed with this effort. Thanks, Brett On Sun, Feb 19, 2012 at 2:30 AM, Adrian Crum adrian.c...@sandglass-software.com wrote: Brett, This opens up the possibility to solve another problem - supporting alternate authentication systems (like LDAP, etc). Right now the userLogin entity includes OFBiz credentials (login name, password), LDAP credentials (DN), and some other credentials that Andrew added. From my perspective, it might be best to use the UserLogin entity only for persisting a user, and have the credentials stored in another entity. The UserLogin entity could then support any number of authentication schemes: UserCredentials --- userLoginId* authenticationTypeId* fromDate* thruDate loginName password Would something like that solve your problem? -Adrian On 2/19/2012 6:51 AM, Brett Palmer wrote: Sakthi, Thanks for the quick reply. The system generated UserIds would not be visible to the user. They would just be used by the system to use ofbiz existing authentication and security features. Our application is not a typical ecommerce app but one that is used by students and teachers for testing. The students are suppose to use their personal userID assigned to them but these are often not remembered and so errors occur. Here is what I am proposing for our solution: 1. Add new fields to the UserLoginId table that will allow us to determine uniqueness within their particular organization. For example, a district ID and a studentID. 2. Create custom authentication method to handle the de-references of the student's studentId and districtId to determine the actual system Id. 3. Verify the password matches the one in the UserLogin table. 5. Get the UserLogin GenericValue and store in a session so ofbiz authentication and security features work. Now when a person calls to say their userId was incorrectly entered we can quickly update their UserId because the ID the student uses is not the primary key. Let me know if anyone sees anything wrong with this approach. Brett On Fri, Feb 17, 2012 at 5:57 AM, Integrin
[VOTE] [RELEASE] Apache OFBiz 09.04.02
This is the vote thread to release a new (bug fix) release for the 09.04 branch. This new release, Apache OFBiz 09.04.02 (major release number: 09.04; minor release number: 02), will supersede the release Apache OFBiz 09.04.01. The release files can be downloaded from here: http://people.apache.org/~jacopoc/dist/ and are: * apache-ofbiz-09.04.02.zip: the release package, based on the 09.04 branch at revision 1291780 (latest as of now) * KEYS: text file with keys * apache-ofbiz-09.04.02.zip.asc: the detached signature file * apache-ofbiz-09.04.02.zip.md5, apache-ofbiz-09.04.02.zip.sha: hashes Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 09.04.02 [ -1] do not release This vote will be closed in 72 hours. For more details about this process please read http://www.apache.org/foundation/voting.html The following text is quoted from the above url: Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. Kind Regards, Jacopo
Proposal to close the 4.0 and 09.04 release branches
Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Re: mailing-lists/Jira stats for 2011
I would like to add the following information, that appears to be in contrast with the trend that seems implied by the stats based on the number of posts that Erwan provided: on March 2010 (2010-03-09) the numbers of subscribers to the lists were: user list: 717 + 116 digest = 833 dev list: 467 + 69 digest = 536 today the numbers of subscribers are: user list: 804 + 164 digest = 968 dev list: 501 + 91 digest = 592 Even if it is difficult to compare the data because the periods don't match completely, it seems clear that the number of subscribers (users and devs) in the last 2 years slowly increased. If I would try to get some conclusions from this stats I could say that the interest for OFBiz is slowly growing but subscribers don't interact much with the community (don't want or don't need to). Regards, Jacopo On Jan 2, 2012, at 5:07 PM, Erwan de FERRIERES wrote: Hi all, here are some stats for mailing-lists (from markmail) and Jira, for 2011. I've added stats for 2010 too, so we can see the evolution. 2010 commits 4138 dev 11207 user 7980 2011 commits 2809 dev 6739 user 3137 Evolution commits -32% dev -40% user -61% JIRA created 2010: 703 created 2011: 553 created: -21% query: project = OFBIZ AND created = 2009-12-31 AND created = 2011-01-01 closed/resolved 2010: 551 closed/resolved 2011: 391 closed/resolved: -29% query: project = OFBIZ AND status in (Resolved, Closed) AND created = 2009-12-31 AND created = 2011-01-01 updated 2010: 700 updated 2011: 827 updated: +18% query: project = OFBIZ AND updated = 2009-12-31 AND updated = 2011-01-01 And issues still opened: 752 query: project = OFBIZ AND status not in (Resolved, Closed) -- Erwan de FERRIERES
Migration of site and dist/ to svnpubsub
Today I have created the ticket for Infra to migrate the publishing mechanism for the OFBiz site and dist/ folder (releases) to svnpubsub: https://issues.apache.org/jira/browse/INFRA-4485 As you may have read from the announcements from Infra, this is a required task as the current mechanism will be discontinued at the end of 2012. By the way, I have asked a couple of questions to Infra in Jira, we will see what they say; but soon we will have to discuss the best way to cope with the change for all our Confluence based pages. Regards, Jacopo
Re: Migration of site and dist/ to svnpubsub
Yes, definitely... but it may be also a good chance to start from scratch with less and cleaner information (frankly speaking, it is a mess right now). In my opinion a strategy like this could work (random thought not well defined and with a lot of defects... but for now it is simply to start thinking about this): 1) find a decent way to save in a safer place all the current content for future reference 2) convert the most official (and static) information from Confluence (back) to html; the following could be good candidates: https://cwiki.apache.org/OFBADMIN/mailing-lists.html https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html 3) collect a list of Confluence pages that we would like to migrate to html as well 4) then we could explore the ASF CMS tool and may decide to switch completely to it if we like it (there will be time to decide) 5) in the meantime we will setup a standard wiki: no more spaces/permissions etc... a plain wiki for generic documentation Jacopo On Feb 24, 2012, at 5:56 PM, Jacques Le Roux wrote: Moving Confluence will be more a concern :/ Jacques From: Adrian Crum adrian.c...@sandglass-software.com Jacopo, Thank you very much for taking care of this. -Adrian On 2/24/2012 3:56 PM, Jacopo Cappellato wrote: Today I have created the ticket for Infra to migrate the publishing mechanism for the OFBiz site and dist/ folder (releases) to svnpubsub: https://issues.apache.org/jira/browse/INFRA-4485 As you may have read from the announcements from Infra, this is a required task as the current mechanism will be discontinued at the end of 2012. By the way, I have asked a couple of questions to Infra in Jira, we will see what they say; but soon we will have to discuss the best way to cope with the change for all our Confluence based pages. Regards, Jacopo
Re: [VOTE] [RELEASE] Apache OFBiz 09.04.02
+1 Jacopo On Feb 22, 2012, at 9:08 AM, Jacopo Cappellato wrote: This is the vote thread to release a new (bug fix) release for the 09.04 branch. This new release, Apache OFBiz 09.04.02 (major release number: 09.04; minor release number: 02), will supersede the release Apache OFBiz 09.04.01. The release files can be downloaded from here: http://people.apache.org/~jacopoc/dist/ and are: * apache-ofbiz-09.04.02.zip: the release package, based on the 09.04 branch at revision 1291780 (latest as of now) * KEYS: text file with keys * apache-ofbiz-09.04.02.zip.asc: the detached signature file * apache-ofbiz-09.04.02.zip.md5, apache-ofbiz-09.04.02.zip.sha: hashes Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 09.04.02 [ -1] do not release This vote will be closed in 72 hours. For more details about this process please read http://www.apache.org/foundation/voting.html The following text is quoted from the above url: Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. Kind Regards, Jacopo
[VOTE] [RESULT] Apache OFBiz 09.04.02
Thanks to the voters, this vote has passed with the following results: [+1] 9: Sam Hamilton, Anil, Sascha, Jacques, Pierre Smits, Bruno, Ashish, Erwan, Jacopo [-1] 0 and also the minimum (3) number of +1 votes from PMC members has been reached: 6 votes from Anil, Jacques, Bruno, Ashish, Erwan, Jacopo I will proceed with the remaining steps required to release the package. Jacopo On Feb 22, 2012, at 9:08 AM, Jacopo Cappellato wrote: This is the vote thread to release a new (bug fix) release for the 09.04 branch. This new release, Apache OFBiz 09.04.02 (major release number: 09.04; minor release number: 02), will supersede the release Apache OFBiz 09.04.01. The release files can be downloaded from here: http://people.apache.org/~jacopoc/dist/ and are: * apache-ofbiz-09.04.02.zip: the release package, based on the 09.04 branch at revision 1291780 (latest as of now) * KEYS: text file with keys * apache-ofbiz-09.04.02.zip.asc: the detached signature file * apache-ofbiz-09.04.02.zip.md5, apache-ofbiz-09.04.02.zip.sha: hashes Please download and test the zip file and its signatures (for instructions on testing the signatures see http://www.apache.org/info/verification.html). Vote: [ +1] release as Apache OFBiz 09.04.02 [ -1] do not release This vote will be closed in 72 hours. For more details about this process please read http://www.apache.org/foundation/voting.html The following text is quoted from the above url: Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. Kind Regards, Jacopo
Please review the text in the OFBiz download page
This is mainly a request for committers that are native English speaker: today I have edited/cleaned a lot of information in the download page: http://ofbiz.apache.org/download.html could you please review what I wrote and improve the English? Thank you, Jacopo
Re: [VOTE] [RESULT] Apache OFBiz 09.04.02
On Feb 25, 2012, at 1:54 PM, Jacopo Cappellato wrote: I will proceed with the remaining steps required to release the package. Ok, everything should be done now: * created release tag * archived old 09.04.01 release * added new 09.04.01 to the dist folder and propagated to all mirrors * updated the download page * sent signed announcement about the release In March we will follow a similar approach for 10.04.01 (second release in the 10.04 series); then in April we could release the first release of the 11.04 series (Apache OFBiz 11.04.01) and also create the new release branch 12.04. Kind Regards, Jacopo
Some thoughts on OFBiz demo instances
Hi Jacques, On Feb 26, 2012, at 11:34 AM, Jacques Le Roux wrote: So, to be consistent, we should swap our stable demo from 09.4 to 10.04 and keep 09.04 as old demo like Christian began to work on it. We will see ASAP I guess... We will then also update the index page to let people know they can still test/use the oldest demo (would be 09.04 until next swap). thanks for bringing up this topic, it was the next in my todo list. There are a few things to discuss about the way we have setup our demos: * we publish a link to the trunk demo from the main page: this is very useful for developers but I doubt it is compliant with the ASF policies; I propose to keep the demo but remove the link from the site pages (we will keep the info in the Wiki and share the url in Jira or dev list communications) * instead of demoing releases we are actually demoing release branches; this is less critical than the above point but still not completely ok with the ASF policies; we can address this in one of the following ways: a) ignore the problem for now (having a running instance of each of the release branches is useful for developers but also for users) b) build the demos on latest official releases instead of branches; and possibly add new instances for the branches as well (but publish, in the indexpage, the url to the official releases only) c) hide the links to the demo instances from the main page * personally (but this is minor) I don't like the names: demo-trunk, demo-old... I would prefer a cleaner approach where the names are neutral like test1, test2 etc... or demo1, demo2 etc... we will then decide what to publish on them * I don't like the name stable release because we have actually several stable release that are valid at the same time: currently 09.04.02 and 10.04 are both stable releases; soon we will also have 11.04.01 stable release Summary: 1) demos are useful to users and developers 2) links to demos for users should be shown in the ofbiz site; links to demos for developers should be kept in the dev list/Jira/wiki 3) demos for users should be based on official releases only: 09.04.02, 10.04 4) demos for developers should be based on trunk and active release branches, currently: trunk, 10.04, 11.04 (and soon 12.04) Kind regards, Jacopo
Re: Proposal to close the 4.0 and 09.04 release branches
Thanks everyone. There seems to be a general agreement to consider closed the release branches release4.0 and release09.04, as a consequence: * we do not plan to issue new releases out of these branches * to all committers: please do not backport fixes to these 2 branches; or at least discuss this to the dev list if you see a good reason for backporting the fix * we should resolve as won't fix all issues that are specific to 4.0 or 09.04 only Of course we could revisit this decision in the future. Kind regards, Jacopo On Feb 23, 2012, at 9:35 AM, Jacopo Cappellato wrote: Hi devs, I would like to propose to officially close the two oldest branches: release4.0 release09.04 When the branches will be closed: * we will no more backport fixes to them (no commits in general will be done) * if a user will submit a patch for the branch in Jira we will resolve as won't fix: the patch will still be there for interested parties * no new release will be created in the future from the two branches * the OFBiz download page will explain that the branches are old and no more supported * (optional) we could close the Jira versions for them and resolve as won't fix outstanding issues if only related to these branches The result would be that, if the current vote for the release Apache OFBiz 09.04.02 will pass then the 09.04.02 will be the last (and third) release of this branch. Of course we could still return on this decision if something new will happen... but I doubt because the number of commits lately has been very low. The main goal is to help the community to have a clearer roadmap for the future and to help to focus on more defined targets: older branches are not supported, but the community will always try to backport fixes to the last two/three branches: the currently active branches are 11.04, 10.04 and the upcoming 12.04. Following the same rule (no more than three active release branches at a time) we could plan to close the 10.04 branch around (sometime before) April 2013 (when the new release branch 13.04 will be created). This is a small and natural step in the direction of having some sort of roadmap for the project. This, together with the discussion going on in thread Proposal about a time based release plan should be enough to define and create a nice and clean release roadmap. We could start an official vote thread if there is interest in this, or, less formally, we could more simply use this thread to discuss pros and cons and find an agreement. What do you think? Jacopo
Summary of some recent discussions around the OFBiz release roadmap and some proposals
We have recently discussed in a few threads some strategies for the definition of a release roadmap for OFBiz; I am summarizing here the main points (old and new) because there seems to be a general agreement around them and we should be ready to officialize them and then stick to this plan: * the release roadmap will be time-based rather than feature-based * every year a new release branch is created on April, generating a new Major Release Number in the format YY.MM (this is *not* a release) * from each active release branch we will release 2 releases every year (approx every 6 months); the names of the releases will be YY.MM.aa where aa is a two digits sequential number (01 is the first release, 02 the second etc..) * no more than 3 active release branches will be maintained simultaneously; for this reason we will close the oldest release branch every year sometimes before April (when the new one is created) An outstanding topic is the following: * do we still want to wait approx 1 year before releasing the first release of a branch? I don't have a strong preference but maybe a stabilization period of 6 months could be enough... but I don't know. In the plan below I am proposing a stabilization period of 10 months. As a result of the above rules, we will release approx 5 releases per year considering the following lifecycle of a release branch: * created in April * first year: stabilization; no new releases are created * second year: two releases 01 and 02 * third year: two releases 03 and 04 * fourth year: one release 05 and then the branch is closed If we name A (oldest), B and C (newest) the three active release branches, then we could stick to the following roadmap: C: new release on February and August B: new release on March and September A: new (last) release on April and then closed (when on April the new branch D is created) For example: 2015 Jan Feb C1 (after mostly 10 months of stabilization) Mar B3 Apr A5 (last); D is created May Jun Jul Aug C2 Sep B4 Oct Nov Dec 2016 Jan Feb D1 Mar C3 Apr B5 (last); E is created May Jun Jul Aug D2 Sep C4 Oct Nov Dec 2016 Jan Feb E1 Mar D3 Apr C5 (last); F is created May Jun Jul Aug E2 Sep D4 Oct Nov Dec etc... Kind regards Jacopo
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
Thank you Adrian, I agree with you and should not have used the word official because it is misleading; let's simply say that there is consensus in the dev list to attempt to stick to this plan; of course we will review it over time and change it if required, or maybe simply ignore it if it will not prove to be useful over time. Jacopo On Feb 26, 2012, at 4:37 PM, Adrian Crum wrote: This is a good summary of the discussions. I'm not clear on what officialize means. I would prefer to have this release roadmap considered as a general outline, and not something cast in stone. My concern is that it will be taken too literally and future efforts to vary the release schedule will be met with resistance because they don't fit in with the officialized road map. In other words, I'm okay with the proposed roadmap, as long as there is some wiggle room to do things differently now and then should the need arise. -Adrian On 2/26/2012 3:29 PM, Jacopo Cappellato wrote: We have recently discussed in a few threads some strategies for the definition of a release roadmap for OFBiz; I am summarizing here the main points (old and new) because there seems to be a general agreement around them and we should be ready to officialize them and then stick to this plan: * the release roadmap will be time-based rather than feature-based * every year a new release branch is created on April, generating a new Major Release Number in the format YY.MM (this is *not* a release) * from each active release branch we will release 2 releases every year (approx every 6 months); the names of the releases will be YY.MM.aa where aa is a two digits sequential number (01 is the first release, 02 the second etc..) * no more than 3 active release branches will be maintained simultaneously; for this reason we will close the oldest release branch every year sometimes before April (when the new one is created) An outstanding topic is the following: * do we still want to wait approx 1 year before releasing the first release of a branch? I don't have a strong preference but maybe a stabilization period of 6 months could be enough... but I don't know. In the plan below I am proposing a stabilization period of 10 months. As a result of the above rules, we will release approx 5 releases per year considering the following lifecycle of a release branch: * created in April * first year: stabilization; no new releases are created * second year: two releases 01 and 02 * third year: two releases 03 and 04 * fourth year: one release 05 and then the branch is closed If we name A (oldest), B and C (newest) the three active release branches, then we could stick to the following roadmap: C: new release on February and August B: new release on March and September A: new (last) release on April and then closed (when on April the new branch D is created) For example: 2015 Jan Feb C1 (after mostly 10 months of stabilization) Mar B3 Apr A5 (last); D is created May Jun Jul Aug C2 Sep B4 Oct Nov Dec 2016 Jan Feb D1 Mar C3 Apr B5 (last); E is created May Jun Jul Aug D2 Sep C4 Oct Nov Dec 2016 Jan Feb E1 Mar D3 Apr C5 (last); F is created May Jun Jul Aug E2 Sep D4 Oct Nov Dec etc... Kind regards Jacopo
Re: Some thoughts on OFBiz demo instances
On Feb 26, 2012, at 8:20 PM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com Hi Jacques, On Feb 26, 2012, at 11:34 AM, Jacques Le Roux wrote: So, to be consistent, we should swap our stable demo from 09.4 to 10.04 and keep 09.04 as old demo like Christian began to work on it. We will see ASAP I guess... We will then also update the index page to let people know they can still test/use the oldest demo (would be 09.04 until next swap). thanks for bringing up this topic, it was the next in my todo list. There are a few things to discuss about the way we have setup our demos: * we publish a link to the trunk demo from the main page: this is very useful for developers but I doubt it is compliant with the ASF policies; I propose to keep the demo but remove the link from the site pages (we will keep the info in the Wiki and share the url in Jira or dev list communications) Are you sure ASF has policies about what should be demoed and what should not? But finally if we would want both it's more a resource issues, see below... There is no policy that prevents us from publishing a demo of unreleased code (i.e. not officially signed and approved for distribution by the PMC): it is still our responsibility to not induce *users* (but developers are fine!) to use unreleased code. What I would like to avoid is something like this: * new user: hey demo-trunk is great, I like feature XYZ, where can I download this software? * committer: feature XYZ is only available from trunk, please checkout and use that So my point is: why are we demoing the trunk to users (the ofbiz main page is mostly addressed to them) if the users will not be able to use the code until is released (and this could take up to a year)? If, as you mention, it is a useful resource for developers (and I completely agree with you) we should probably move the urls (or at least clarify the labels) to another place in order to avoid any confusion. * instead of demoing releases we are actually demoing release branches; this is less critical than the above point but still not completely ok with the ASF policies; we can address this in one of the following ways: a) ignore the problem for now (having a running instance of each of the release branches is useful for developers but also for users) Yes, really. It's easier for both parts to exchanges about popping issues. I'm ok to be at the service of users, but I wonder if it's worth the effort on this aspect... b) build the demos on latest official releases instead of branches; and possibly add new instances for the branches as well (but publish, in the indexpage, the url to the official releases only) We have not enough places for more than 3 demos. Users can build their own demos locally. Of course unofficial demo servers could be used, but it has been proved in the past that it's easier to have only Apache demos to maintain... Things are pretty stable for a while (apart some unexplained Derby issues recently), of course running real realeas unstead would not change that much. Only that we would lose the very handy part for committers (3 instances running is great). c) hide the links to the demo instances from the main page * personally (but this is minor) I don't like the names: demo-trunk, demo-old... I would prefer a cleaner approach where the names are neutral like test1, test2 etc... or demo1, demo2 etc... we will then decide what to publish on them * I don't like the name stable release because we have actually several stable release that are valid at the same time: currently 09.04.02 and 10.04 are both stable releases; soon we will also have 11.04.01 stable release demo-trunk and demo-stable name were 1st suggested by infra. Then we agreed on demo-old for the penultimate Yeah, I remember... and this doesn't help me to like them more :-) To summarize: if we want to keep 3 instances to simplify the work of OFBiz developers rather than users then we should probably have: demo-trunk -- trunk demo-stable -- 11.04 branch demo-old -- 10.04 branch because these are the 3 active branches (even if we still don't have a release from 11.04, but this should come soon). But as you can see the names don't make much sense as 10.04 is not old and 11.04 is not more stable than 10.04 Kind regards, Jacopo Summary: 1) demos are useful to users and developers 2) links to demos for users should be shown in the ofbiz site; links to demos for developers should be kept in the dev list/Jira/wiki We would need more resources and I doubt infra will agree. Same issues for the 2 points below To be discussed more... ;o) Jacques 3) demos for users should be based on official releases only: 09.04.02, 10.04 4) demos for developers should be based on trunk and active release branches, currently: trunk, 10.04, 11.04 (and soon 12.04) Kind regards, Jacopo
Re: svn commit: r1294095 - /ofbiz/branches/release09.04/applications/order/src/org/ofbiz/order/order/OrderListState.java
Hi Jacques,
why are you still backporting fixes to the 09.04 branch? this is the second one
you commit after the release 09.04.02 has beed released and there seems to be
general consensus to consider it the last release in the branch.
Of course we can change decision and plan for another release and continue to
backport patches if you feel the need for this... but if we don't then these
fixes will never be released.
Jacopo
On Feb 27, 2012, at 11:26 AM, jler...@apache.org wrote:
Author: jleroux
Date: Mon Feb 27 10:26:46 2012
New Revision: 1294095
URL: http://svn.apache.org/viewvc?rev=1294095view=rev
Log:
A patch from Chatree Srichart OrderListState needs to be Serializable for
clustering https://issues.apache.org/jira/browse/OFBIZ-4660
OrderListState is to be set to session, so it needs to be Serializable for
clustering.
Modified:
ofbiz/branches/release09.04/applications/order/src/org/ofbiz/order/order/OrderListState.java
Modified:
ofbiz/branches/release09.04/applications/order/src/org/ofbiz/order/order/OrderListState.java
URL:
http://svn.apache.org/viewvc/ofbiz/branches/release09.04/applications/order/src/org/ofbiz/order/order/OrderListState.java?rev=1294095r1=1294094r2=1294095view=diff
==
---
ofbiz/branches/release09.04/applications/order/src/org/ofbiz/order/order/OrderListState.java
(original)
+++
ofbiz/branches/release09.04/applications/order/src/org/ofbiz/order/order/OrderListState.java
Mon Feb 27 10:26:46 2012
@@ -18,13 +18,26 @@
*/
package org.ofbiz.order.order;
-import java.util.*;
-import javax.servlet.http.*;
-import javolution.util.*;
-import org.ofbiz.base.util.*;
-import org.ofbiz.entity.*;
-import org.ofbiz.entity.condition.*;
-import org.ofbiz.entity.util.*;
+import java.io.Serializable;
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.Map;
+
+import javax.servlet.http.HttpServletRequest;
+import javax.servlet.http.HttpSession;
+
+import javolution.util.FastMap;
+
+import org.ofbiz.base.util.Debug;
+import org.ofbiz.base.util.UtilMisc;
+import org.ofbiz.base.util.UtilValidate;
+import org.ofbiz.entity.GenericDelegator;
+import org.ofbiz.entity.GenericEntityException;
+import org.ofbiz.entity.condition.EntityCondition;
+import org.ofbiz.entity.condition.EntityOperator;
+import org.ofbiz.entity.util.EntityFindOptions;
+import org.ofbiz.entity.util.EntityListIterator;
/**
* Session object for keeping track of the list of orders.
@@ -40,7 +53,8 @@ import org.ofbiz.entity.util.*;
* objects, including Pagination. Think about design
* patterns in Fowler.
*/
-public class OrderListState {
+@SuppressWarnings(serial)
+public class OrderListState implements Serializable {
public static final String module = OrderListState.class.getName();
public static final String SESSION_KEY = __ORDER_LIST_STATUS__;
Re: Summary of some recent discussions around the OFBiz release roadmap and some proposals
On Feb 26, 2012, at 8:04 PM, Jacques Le Roux wrote: For me also 6 months seems long enough for the 1st official release. I'm just afraid: will we have not a lot of work to release so often (relases themself, annunciations, site update and especially demos updates) Anyway it seems we need to do it, maybe at the expense of other areas we are working on (Jiras, users support, etc.) It will take time for sure but working on releases should be the main goal of a community within the ASF: a release is the only trusted way to publish the work we do: if we fix a bug but we do not issue a release the users will not get real benefit. Jacopo Jacques
Re: svn commit: r1293999 [1/2] - in /ofbiz/trunk: ./ framework/base/config/ framework/birt/ framework/birt/config/ framework/birt/data/helpdata/ framework/birt/documents/ framework/birt/lib/ framework
Hans, are all these jars really needed? Jacopo On Feb 27, 2012, at 3:37 AM, hans...@apache.org wrote: Added: ofbiz/trunk/framework/birt/lib/Tidy.jar (with props) ofbiz/trunk/framework/birt/lib/flute.jar (with props) ofbiz/trunk/framework/birt/lib/js.jar (with props) ofbiz/trunk/framework/birt/lib/org.apache.xml.resolver_1.2.0.v201005080400.jar (with props) ofbiz/trunk/framework/birt/lib/org.apache.xml.serializer_2.7.1.v201005080400.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.birt.runtime_3.7.2.v20120214-1408.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.core.contenttype_3.4.100.v20110423-0524.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.core.expressions_3.4.300.v20110228.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.core.filesystem_1.3.100.v20110423-0524.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.core.jobs_3.5.101.v20120113-1953.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.core.resources_3.7.101.v20120125-1505.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.core.runtime_3.7.0.v20110110.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.apache.derby.dbdefinition_1.0.2.v201107221459.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.apache.derby_1.0.102.v201107221459.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.console.profile_1.0.10.v201109250955.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.db.generic_1.0.1.v201107221459.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.dbdefinition.genericJDBC_1.0.1.v201107221459.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.consumer_3.2.5.v201109151100.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.design_3.3.4.v201109211529.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.flatfile_3.1.2.v201112081200.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.profile_3.2.7.v201112290953.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda_3.3.3.v201110130935.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.sqm.core_1.2.4.v201201131116.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity_1.2.4.v201202041105.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.hsqldb.dbdefinition_1.0.0.v201107221502.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.hsqldb_1.0.0.v201107221502.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.db2.luw.dbdefinition_1.0.4.v201107221502.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.db2.luw_1.0.2.v201107221502.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.informix.dbdefinition_1.0.4.v201107221502.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.informix_1.0.1.v201107221502.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.msft.sqlserver.dbdefinition_1.0.1.v201201240349.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.msft.sqlserver_1.0.1.v201107221504.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.mysql.dbdefinition_1.0.4.v201109022331.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.mysql_1.0.2.v201109022323.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oda.ws_1.2.3.v201112061438.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oda.xml_1.2.3.v201112061438.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oracle.dbdefinition_1.0.102.v201107221506.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oracle_1.0.0.v201107221506.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.postgresql.dbdefinition_1.0.2.v201110070445.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.postgresql_1.1.0.v201110070445.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.modelbase.dbdefinition_1.0.2.v201107221519.jar (with props) ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.modelbase.derby_1.0.0.v201107221519.jar
Re: Some thoughts on OFBiz demo instances
On Feb 27, 2012, at 12:46 PM, Hans Bakker wrote: On 02/27/2012 06:15 PM, Jacques Le Roux wrote: - Original Message - From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com To: dev@ofbiz.apache.org Sent: Monday, February 27, 2012 10:48 AM Subject: Re: Some thoughts on OFBiz demo instances So my point is: why are we demoing the trunk to users (the ofbiz main page is mostly addressed to them) if the users will not be able to use the code until is released (and this could take up to a year)? If, as you mention, it is a useful resource for developers (and I completely agree with you) we should probably move the urls (or at least clarify the labels) to another place in order to avoid any confusion. Agreed, trunk should be keeped as demo but removed from main page No I do not think so for the following reasons: 1. OFBiz is not for end users anyway: can an end-user setup a e-commerce shop? Can he intialize and install the system? He ALWAYS need help. The user here is the Company using the software: it could be a big company with a big internal IT or a software company selling services to its customers... they both would be end users of OFBiz; and yes I know a lot users that are using ofbiz (possibly customizing it a lot) that are using one release and not the trunk. 2. The trunk is as stable as the other versions, with a lot of enhancement added. The fact that it is not officially approved for release by the PMC is an *important* difference that any PMC member must understand and accept; we can work together releasing more often etc... but we cannot ignore this rule. 3. If we refactoring we keep it in a separate branch until it is unlikely to upset other functions. I don't understand the above statement. so we should keep it as a demo on the front page. As I said above, keeping url of the demo of the trunk in the main page is not a violation of ASF rules in itself, but it is important that the link is not unclear or confusing to users. Jacopo Regards, Hans
Re: Some thoughts on OFBiz demo instances
Please stay with your opinion Jacopo On Feb 27, 2012, at 1:22 PM, Hans Bakker wrote: Jacopo, there is, as you state no rule against it, i gave you my reasons and stay with my opinion that it should stay on the main page. Regards, Hans On 02/27/2012 07:09 PM, Jacopo Cappellato wrote: On Feb 27, 2012, at 12:46 PM, Hans Bakker wrote: On 02/27/2012 06:15 PM, Jacques Le Roux wrote: - Original Message - From: Jacopo Cappellatojacopo.cappell...@hotwaxmedia.com To:dev@ofbiz.apache.org Sent: Monday, February 27, 2012 10:48 AM Subject: Re: Some thoughts on OFBiz demo instances So my point is: why are we demoing the trunk to users (the ofbiz main page is mostly addressed to them) if the users will not be able to use the code until is released (and this could take up to a year)? If, as you mention, it is a useful resource for developers (and I completely agree with you) we should probably move the urls (or at least clarify the labels) to another place in order to avoid any confusion. Agreed, trunk should be keeped as demo but removed from main page No I do not think so for the following reasons: 1. OFBiz is not for end users anyway: can an end-user setup a e-commerce shop? Can he intialize and install the system? He ALWAYS need help. The user here is the Company using the software: it could be a big company with a big internal IT or a software company selling services to its customers... they both would be end users of OFBiz; and yes I know a lot users that are using ofbiz (possibly customizing it a lot) that are using one release and not the trunk. 2. The trunk is as stable as the other versions, with a lot of enhancement added. The fact that it is not officially approved for release by the PMC is an *important* difference that any PMC member must understand and accept; we can work together releasing more often etc... but we cannot ignore this rule. 3. If we refactoring we keep it in a separate branch until it is unlikely to upset other functions. I don't understand the above statement. so we should keep it as a demo on the front page. As I said above, keeping url of the demo of the trunk in the main page is not a violation of ASF rules in itself, but it is important that the link is not unclear or confusing to users. Jacopo Regards, Hans
bin folder for executable files/scripts
The number of executable files (*.sh and *bat) in the OFBiz home folder is rather big: what if we create a bin folder and we move all of them there? In this way users will have a place where they will find all the executable files only and the main folder will be cleaner. Jacopo
Re: svn commit: r1294450 - /ofbiz/trunk/framework/birt/lib/
Hans, do not forget to remove them from the LICENSE file as well. Jacopo On Feb 28, 2012, at 3:48 AM, hans...@apache.org wrote: Author: hansbak Date: Tue Feb 28 02:48:54 2012 New Revision: 1294450 URL: http://svn.apache.org/viewvc?rev=1294450view=rev Log: related to Jacopo's query we do not need the datatools of verious databases because we use the delegator with Birt. Contribution by Chattree Removed: ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.apache.derby.dbdefinition_1.0.2.v201107221459.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.apache.derby_1.0.102.v201107221459.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.console.profile_1.0.10.v201109250955.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.db.generic_1.0.1.v201107221459.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.dbdefinition.genericJDBC_1.0.1.v201107221459.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.consumer_3.2.5.v201109151100.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.design_3.3.4.v201109211529.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.flatfile_3.1.2.v201112081200.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.oda.profile_3.2.7.v201112290953.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity.sqm.core_1.2.4.v201201131116.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.connectivity_1.2.4.v201202041105.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.hsqldb.dbdefinition_1.0.0.v201107221502.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.hsqldb_1.0.0.v201107221502.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.db2.luw.dbdefinition_1.0.4.v201107221502.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.db2.luw_1.0.2.v201107221502.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.informix.dbdefinition_1.0.4.v201107221502.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.ibm.informix_1.0.1.v201107221502.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.msft.sqlserver.dbdefinition_1.0.1.v201201240349.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.msft.sqlserver_1.0.1.v201107221504.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.mysql.dbdefinition_1.0.4.v201109022331.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.mysql_1.0.2.v201109022323.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oda.ws_1.2.3.v201112061438.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oda.xml_1.2.3.v201112061438.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oracle.dbdefinition_1.0.102.v201107221506.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.oracle_1.0.0.v201107221506.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.postgresql.dbdefinition_1.0.2.v201110070445.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.enablement.postgresql_1.1.0.v201110070445.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.modelbase.dbdefinition_1.0.2.v201107221519.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.modelbase.derby_1.0.0.v201107221519.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.modelbase.sql.query_1.1.2.v201110151315.jar ofbiz/trunk/framework/birt/lib/org.eclipse.datatools.modelbase.sql_1.0.5.v201110151330.jar
Fixing bad patterns widely used to check role based permission
On Feb 27, 2012, at 8:47 PM, Adrian Crum wrote: I would welcome a discussion of wrong (or bad) patterns. Lately I spend about half my development time fixing things that are done wrong. -Adrian Thank you Adrian, here is what I would like to address: I see a lot of code that checks ROLE permissions in a way that make them useless or redundant. Before I describe the issue that I see I would like to summarize what I know about ROLE based permissions, it would be useful to check if we are all on the same page with these as well. There are two main families of permissions (SecurityPermission) in OFBiz and they are categorized based on a naming convention: a) standard permissions are in the format NAME_ACTION; for example: ACCOUNTING_VIEW, CATALOG_UPDATE, ...; a user with one these permission can perform the ACTION on all data related to NAME domain; for example a user with CATALOG_UPDATE can update any catalog in the system b) role permissions are in the format NAME_ROLE_ACTION; for example: ACCOUNTING_ROLE_VIEW, CATALOG_ROLE_UPDATE, ...; a user with one these permission can perform the ACTION on the data related to NAME domain but only if the party (associated to the user) is associated to (has a role) the data; the nature of the association depends on the domain/context; for example a user with CATALOG_ROLE_UPDATE can update only the catalogs in the system for which the user is in the role of LTD_ADMIN (this information is stored in ProductCategoryRole); however the association could be more complex than a role record; for example we could have a special ROLE permission that grants some action on some employee data to users that are managers in the company division where the employees work: the association here would be a combination of PartyRole/PartyRelationship (several records, possibly on a hierarchical tree); but the general rule is: if the user has a ROLE permission then additional checks on data are needed before granting rights to perform the operation on data and they depend on the context and business rules The bad pattern I see in the system is exemplified by the following code snippet from setPaymentStatus service: check-permission permission=ACCOUNTING action=_UPDATE alt-permission permission=ACCOUNTING_ROLE action=_UPDATE/ fail-property resource=AccountingUiLabels property=AccountingPermissionError/ /check-permission A check like this returns true if the user has ACCOUNTING_UPDATE or ACCOUNTING_ROLE_UPDATE; in this way the two permissions are equivalent. For the same reason, the following permission services are not very useful: simple-method method-name=basePermissionCheck short-description=Accounting component base permission logic set field=primaryPermission value=ACCOUNTING/ call-simple-method method-name=genericBasePermissionCheck xml-resource=component://common/script/org/ofbiz/common/permission/CommonPermissionServices.xml/ /simple-method simple-method method-name=basePlusRolePermissionCheck short-description=Accounting component base permission logic set field=primaryPermission value=ACCOUNTING/ set field=altPermission value=ACCOUNTING_ROLE/ call-simple-method method-name=genericBasePermissionCheck xml-resource=component://common/script/org/ofbiz/common/permission/CommonPermissionServices.xml/ /simple-method in fact: * basePermissionCheck returns true if the user has one of the base ACCOUNTING CRUD+ADMIN permissions * basePlusRolePermissionCheck returns true if user has one of the base ACCOUNTING CRUD+ADMIN permissions OR if user has one of the base ACCOUNTING_ROLE CRUD+ADMIN permissions How should the two services be used properly? If we run only basePlusRolePermissionCheck we will not know if we have to check if the party/user is associated to the data because we do not know if the user has an ACCOUNTING permission or only an ACCOUNTING_ROLE permission. In theory the two services should be used together in the following way: 1) run basePermissionCheck and if it returns true then grant right to perform the action; 2) otherwise, run basePlusRolePermissionCheck and if it returns true then check association data (but this,even inside of the ACCOUNTING domain, may depend on different data structures for different processes); if the data is available then grant right to perform the action At this point it would be more useful to have the following base services: * basePermissionCheck: same as above * rolePermissionCheck (instead of basePlusRolePermissionCheck): returns true if user has one of the base ACCOUNTING_ROLE CRUD+ADMIN permissions As a side note, for the same reason the methods security.hasRolePermission(...) are useless if you do not pass the roles (and no code does currently) and were all used in the wrong way. The end result is that we have a lot of code that treats standard permissions and ROLE permission as
Re: Fixing bad patterns widely used to check role based permission
On Feb 28, 2012, at 11:49 AM, Adrian Crum wrote: An example is your description of the CATALOGADMIN_LTD security group. The permission check is based on a party role, not a user role. Party roles and user roles are not the same thing. Yes, that is an example of a party role that is important to determine if the user is granted to perform an operation (together with the ROLE permission). But I was confused about the meaning of user role as there is not a direct relationship with OFBiz artifacts: the ingredients of the security framework in OFBiz are: * SecurityGroups: this is probably the closest concept to a user role * SecurityPermissions * *Role entities, i.e. party roles (FacilityRole, OrderRole etc...) but also other structures (like PartyRelationship etc...) can play a... role in this :-) Jacopo
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Hi Hans,
I don't like the assumption about the string control: this is a configurable
value (in web.xml) and we should not have it hardcoded in our code.
I know there are already few examples of this bad pattern and in fact we should
work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl =
prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT, );
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product =
delegator.findOne(Product, UtilMisc.toMap(productId, productId), false);
ProductContentWrapper wrapper = new
ProductContentWrapper(dispatcher, product, locale, text/html);
-url = CatalogUrlFilter.makeProductUrl(delegator,
wrapper, null, ((StringModel) prefix).getAsString(), previousCategoryId,
productCategoryId, productId);
+url = CatalogUrlFilter.makeProductUrl(delegator,
wrapper, null, prefixUrl, previousCategoryId, productCategoryId, productId);
} else {
GenericValue productCategory =
delegator.findOne(ProductCategory, UtilMisc.toMap(productCategoryId,
productCategoryId), false);
CategoryContentWrapper wrapper = new
CategoryContentWrapper(dispatcher, productCategory, locale, text/html);
-url =
CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId,
viewSize, viewIndex, viewSort, searchString);
+url =
CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId, viewSize, viewIndex,
viewSort, searchString);
}
out.write(url.toString());
} else {
Modified: ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml?rev=1295029r1=1295028r2=1295029view=diff
==
--- ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
(original)
+++ ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml Wed Feb
29 09:23:36 2012
@@ -85,7 +85,7 @@ under the License.
property-map resource=PartyUiLabels map-name=uiLabelMap
global=true/
property-map resource=CommonUiLabels map-name=uiLabelMap
global=true/
set field=title
value=${uiLabelMap.PageTitleOrderConfirmationNotice}/
-set field=baseEcommerceSecureUrl
value=${baseSecureUrl}/ecommerce/
+set field=baseEcommerceSecureUrl
value=${baseSecureUrl}/ecommerce/control/
set
Re: Please review the text in the OFBiz download page
Thank you Anne; I have committed your corrections with rev. 1295109 The site should publish them in about 1 hour. Jacopo On Feb 29, 2012, at 6:56 AM, Anne wrote: I can't find a way to log in and change it myself, but my suggested edits are trivial: where YY and MM are the year and month of when the release branch was created should be where YY and MM are the year and month the release branch was created (drop of when) Major Release Number is created every year on April should be Major Release Number is created every year in April (on becomes in) Minor Release Number is a two digits sequential number should be Minor Release Number is a two digit sequential number (singular, not plural, for digit) Cheers, Anne. On 27 February 2012 00:46, Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com wrote: This is mainly a request for committers that are native English speaker: today I have edited/cleaned a lot of information in the download page: http://ofbiz.apache.org/download.html could you please review what I wrote and improve the English? Thank you, Jacopo -- Coherent Software Australia Pty Ltd PO Box 2773 Cheltenham Vic 3192 Phone: (03) 9585 6788 Fax: (03) 9585 1086 Web: http://www.cohsoft.com.au/ Email: sa...@cohsoft.com.au Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/
Re: bin folder for executable files/scripts
Thanks for the feedback! Any suggestion for the name of the folder? I was hoping to use a standard name, that is why I initially proposed the bin folder... but since that is not an option we will have to think to something else (unless we use the existing tools folder but I am not sure about the intended usage of that). Jacopo On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote: +1 Jacques From: Adrian Crum adrian.c...@sandglass-software.com Sounds great, but don't use bin - that folder is created by Eclipse and it is in the SVN ignore list. -Adrian On 2/27/2012 7:10 PM, Jacopo Cappellato wrote: The number of executable files (*.sh and *bat) in the OFBiz home folder is rather big: what if we create a bin folder and we move all of them there? In this way users will have a place where they will find all the executable files only and the main folder will be cleaner. Jacopo
OFBiz website compliance with ASF Brand policy
As some of you may already know, being part of the Apache Software Foundation, the OFBiz project is asked to comply with the ASF Brand policy: http://www.apache.org/foundation/marks/responsibility.html http://www.apache.org/foundation/marks/pmcs.html Every quarter, as part of the report to the ASF Board, we have to add with the current status of compliance with the Project Branding Checklist. During the last year we were able to fix our site and download page in order to address some outstanding requirements; a few days ago we have added the TM to our logo and now we are mostly close to complete this work. In my next report to the ASF Board I will probably write something like this: Project Website Basics: complete [*] Project Naming And Descriptions: complete Website Navigation Links: complete Trademark Attributions: complete Logos and Graphics: complete Project Metadata: complete [*] The text in the main pages (index, download) of the project's website is now compliant with the project branding guidelines; however there are several Confluence based pages (linked from the home page) that still need to be reviewed As you can read, we are pretty close but the last item is probably the biggest one to fix: making sure that *every* link and information in the OFBiz site is *official* and published under the approval of the OFBiz PMC. This task can take a long time and I would instead really hope to clear the checklist within the next Board report (in June): in order to achieve this we will have to work together over a concrete plan of action. I would suggest the following plan of action (trying to minimize the effort and proceed at small steps): 1) remove all the existing links to Confluence/Wiki from the OFBiz website (i.e. static html pages under ofbiz.apache.org/*) 2) we will initially end up with a simpler website (less links etc) but there are some pages (currently in Confluence) that are really important, for example: https://cwiki.apache.org/OFBADMIN/mailing-lists.html https://cwiki.apache.org/OFBADMIN/ofbiz-source-repository-and-access.html in these cases we will convert them to static html pages and host them from the website (making sure they are compliant with the branding guidelines) 3) we will only keep *one* link to access Confluence/Wiki: in this way the user will clearly know that she/he is leaving the Official site for the Official Wiki (where for its nature, the information could be a bit less controlled) 4) we will then add a footer/header or similar to the Wiki pages with a mention that the information in them is less official and to report to the OFBiz PMC any abuse or similar; we should not spend too much time on this as we will have soon to migrate out of Confluence (by the end of the year) 5) change our internal policy for updates to project website pages: the changes to the static website pages will have to be voted before being published (Review-Then-Commit): even if it will be extra work, imo it is important because website pages are officially published as soon as they are committed/deployed and this is similar to issuing a release (that requires a formal vote); in this way we, as the PMC, will be sure that we are controlling the content of the website and will be responsible for it 6) then we will add content back (from Wiki to html) voting the new additions to make sure the site remains clean and good 7) in the meantime we will also discuss the new technology for the wiki Of all the above points, the weaker one is #4: because according to the branding guidelines the OFBiz PMC is also responsible for the content on the official wiki; but at least we will have a clearer boundary and there will be more time to improve (also based on the technology we will adopt for the new wiki). At the moment, the following branding requirements are some of the ones that will require some cleanup for sure: * Apache projects must host all official website content on an apache.org domain. This includes all content overseen by the project's PMC (including top level website, downloads, wikis, etc.), and ensures both that the ASF infrastructure team can maintain the services, as well informing any users that the content comes from the ASF or the project's PMC, and not a third party * Projects must ensure that their average user can find all information and code necessary to use the product in its common use cases solely on the project's own website. A normal user should be able to learn about the product from the project's own materials, and must be able to use the product solely under the Apache License or other Apache Legal Affairs approved licenses in software that is distributed from this or other Apache projects * Projects must not endorse or promote the work of third parties, nor allow third party influence to affect the future of the project
Re: svn commit: r1295344 [1/5] - in /ofbiz/trunk/framework/images/webapp/images/jquery/jquery.mobile-1.1.0-rc.1: ./ images/
Hi Anil, please update also the LICENSE (and NOTICE, if needed) file. Thanks, Jacopo On Mar 1, 2012, at 12:56 AM, apa...@apache.org wrote: Author: apatel Date: Wed Feb 29 23:56:40 2012 New Revision: 1295344 URL: http://svn.apache.org/viewvc?rev=1295344view=rev Log: Adding JQuery Mobile library. Also updated hhfacility application to use it. Lot more work needs to be done to make hhfacility application useful, We have a start :)
Re: Definitively remove beanshell from OFBiz
Implementing JSR-223 should be rather easy but if I am not wrong it would prevent the ability to cache the scripts (task that is currently done in org.ofbiz.base.util.GroovyUtil, that is using the the more flexible GroovyClassLoader mechanism); we could probably use the javax.script.Compilable interface but I am not sure... One advantage of JSR-223 would be that we could dynamically select the script engine based on the (for example) file extension without the need to maintain several classes like GroovyUtil, BsfUtil etc... The idea would be that, instead of having a GroovyUtil class we could have a generic ScriptUtil class with code like the following: ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine scriptEngine = manager.getEngineByExtension(fileExtension); Object result = scriptEngine.eval(scriptFileReader, scriptContext); and this code would be generic and could be used to plug in all the scripting engines that support JSR-223. However doing this in OFBiz would mean that we have to refactor all the code that is currently using the various scriptUtil classes and in my opinion a simpler path (that is inline with Erwan's proposal to convert all remaining beanshell snippets to Groovy and then deprecate or remove BshUtil) would be: 1) migrate the remaining Beanshell snippets to Groovy 2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to old/unused script engines) 3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223 In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with several other technologies (removed at #2) Kind regards, Jacopo [*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script engine would be easy (but the support of the new script engine will not be included in the project to keep it light and focused) On Feb 27, 2012, at 3:53 PM, Erwan de FERRIERES wrote: Le 12/02/2012 20:43, Adrian Crum a écrit : It would be nice if we could come up with a way to use JSR 223 in screen widgets and mini-language. Adrian, would this mean that we'll be moving from groovy.lang.Script to ScriptEngineManager and ScriptEngine ? Do you think this would be a big task to accomplish this migration ? Regards, -Adrian On 2/9/2012 6:31 AM, Jacques Le Roux wrote: After almost 4 years, I can see no problems with that Jacques From: Erwan de FERRIERES erwan.deferrie...@gmail.com Hi all, in may 2008, we decided to move from beanshell to groovy (http://ofbiz.markmail.org/message/5p33dhfnuh7gnfby?q=groovy+beanshell#query:groovy%20beanshell). Since this time a lot of migration has been done, but still some snippets are remaining in the code (mostly in screens). What do you think of removing all the remaining bsh code, as well as its support in OFBiz ? Regards, -- Erwan de FERRIERES -- Erwan de FERRIERES www.nereide.biz
Re: Definitively remove beanshell from OFBiz
The document is interesting and I agree with the approach in general. I don't agree, but this is a small detail, with the assertion that currency should be part of a framework: I can think of several applications not dealing with money :-) And if we want to design a framework for ERP applications then we could have some additional pieces (like Geos, Uoms, Currencies)... but this would be more a common base to ERP applications. I like the idea of one component framework: at that point it would be easier to deploy and we could use an external tomcat as the default setup (no more embedded catalina). I also think that the official OFBiz ERP (i.e. the features currently in the applications folder) should also be implemented by *one* application/component: based on naming conventions and patterns to simplify customizations and reuse but still one application where features are hidden thru permissions. But this is for OFBiz 2.0, nice to discuss, but my idea for a lightweight framework was less revolutionary and could be considered as a preparation step in the direction of the new OFBiz: cutting down old branches and unused code in order to have a smaller system to refactor according to the new vision. At that point, with a cleaner ground, we could better plan the next step: implementing a new framework or considering other options (e.g. Moqui) or even keeping what we have Jacopo On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote: As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the embedded cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient. I can help out with the conversion. I don't think the task will be that hard. Regarding a slimmed down framework, I proposed one some time ago: https://cwiki.apache.org/confluence/display/OFBADMIN/Another+Framework+Vision and that document was in response to David's proposal to base OFBiz on Moqui (another option). -Adrian On 3/1/2012 8:53 AM, Jacopo Cappellato wrote: Implementing JSR-223 should be rather easy but if I am not wrong it would prevent the ability to cache the scripts (task that is currently done in org.ofbiz.base.util.GroovyUtil, that is using the the more flexible GroovyClassLoader mechanism); we could probably use the javax.script.Compilable interface but I am not sure... One advantage of JSR-223 would be that we could dynamically select the script engine based on the (for example) file extension without the need to maintain several classes like GroovyUtil, BsfUtil etc... The idea would be that, instead of having a GroovyUtil class we could have a generic ScriptUtil class with code like the following: ScriptEngineManager manager = new ScriptEngineManager(); ScriptEngine scriptEngine = manager.getEngineByExtension(fileExtension); Object result = scriptEngine.eval(scriptFileReader, scriptContext); and this code would be generic and could be used to plug in all the scripting engines that support JSR-223. However doing this in OFBiz would mean that we have to refactor all the code that is currently using the variousscriptUtil classes and in my opinion a simpler path (that is inline with Erwan's proposal to convert all remaining beanshell snippets to Groovy and then deprecate or remove BshUtil) would be: 1) migrate the remaining Beanshell snippets to Groovy 2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to old/unused script engines) 3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223 In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with several other technologies (removed at #2) Kind regards, Jacopo [*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script
Re: svn commit: r1295344 [1/5] - in /ofbiz/trunk/framework/images/webapp/images/jquery/jquery.mobile-1.1.0-rc.1: ./ images/
Thanks Anil, then I think we are fine. Jacopo On Mar 1, 2012, at 2:08 PM, Anil Patel wrote: Jacopo, Thanks for the note. Before commit, I did take a look at the license file. It has following entry at line #1288. ofbiz/trunk/framework/images/webapp/images/jquery/* The new framework I have added is in a folder under this (jquery) folder. Also the framework uses same license as jquery (MIT), so I did not see need for adding new entry. Do you think I should still do it? Thanks and Regards Anil Patel HotWax Media Inc On Mar 1, 2012, at 12:52 AM, Jacopo Cappellato wrote: Hi Anil, please update also the LICENSE (and NOTICE, if needed) file. Thanks, Jacopo On Mar 1, 2012, at 12:56 AM, apa...@apache.org wrote: Author: apatel Date: Wed Feb 29 23:56:40 2012 New Revision: 1295344 URL: http://svn.apache.org/viewvc?rev=1295344view=rev Log: Adding JQuery Mobile library. Also updated hhfacility application to use it. Lot more work needs to be done to make hhfacility application useful, We have a start :)
Re: Framework refactor (was: Definitively remove beanshell from OFBiz)
On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote: I understand the workflow you are suggesting - cut down the size of the existing framework and then switch to something else. In an ideal world we could do that. Unfortunately, we have a lot of committers who believe more is better, so while we're cutting down in one area, someone else will be adding code in another area. Yes, I know what you mean: I still think that, if the goal is clear and the strategy makes sense (e.g. simplify/standardize the tools used, for example migrate everything from bsh to groovy, and then slim down the current framework to the bare minimum technologies used by the official applications in order to simplify and renew the code base) we could try to work to get a majority approval and a shared strategy and then everyone will have to stick to the plan and help to implement it... i.e. working as a community rather than as individual with commit rights and different visions. Jacopo
Applying the Configuration By Exception concept more extensively
A decent description of the Configuration By Exception concept is the following [*]: Java EE 5 introduced the idea of configuration by exception (sometimes referred to as programming by exception or convention over configuration). This means, unless specified differently, the container or provider should apply the default rules. In other words, having to supply a configuration is the exception to the rule. This allows you to write the minimum amount of code to get your application running, relying on the container and provider defaults. To some extent the OFBiz framework already applied this pattern is some areas (you may remember when we made the entity group-name org.ofbiz the default value and then were able to remove a bunch of configuration files); however I see a lot of room for further apply it, starting from the ofbiz-component.xml files. For example, considering the ofbiz-component.xml file in framework/example: ofbiz-component name=example xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=http://ofbiz.apache.org/dtds/ofbiz-component.xsd; !-- define resource loaders; most common is to use the component resource loader -- resource-loader name=main type=component/ !-- place the config directory on the classpath to access configuration files -- classpath type=dir location=config/ classpath type=dir location=dtd/ !-- load single or multiple external libraries -- classpath type=jar location=build/lib/*/ !-- entity resources: model(s), eca(s), group, and data definitions -- entity-resource type=model reader-name=main loader=main location=entitydef/entitymodel.xml/ entity-resource type=model reader-name=main loader=main location=entitydef/entitymodel_view.xml/ !-- entity-resource type=eca reader-name=main loader=main location=entitydef/eecas.xml/ -- entity-resource type=data reader-name=seed loader=main location=data/ExampleTypeData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExampleSecurityData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExamplePortletData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExamplePortalSeedData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExampleHelpData.xml/ entity-resource type=data reader-name=demo loader=main location=data/ExampleDemoData.xml/ !-- service resources: model(s), eca(s) and group definitions -- service-resource type=model loader=main location=servicedef/services.xml/ service-resource type=eca loader=main location=servicedef/secas.xml/ !-- service-resource type=group loader=main location=servicedef/groups.xml/ -- test-suite loader=main location=testdef/tests.xml/ !-- web applications; will be mounted when using the embedded container -- webapp name=example title=Example menu-name=secondary server=default-server location=webapp/example base-permission=OFBTOOLS,EXAMPLE mount-point=/example/ webapp name=birt title=BIRT server=default-server location=webapp/birt base-permission=OFBTOOLS,WEBTOOLS mount-point=/birt app-bar-display=false/ /ofbiz-component If we assume that the default layout of an OFBiz component is the one used by the example component (and actually by all our components) we could simply have: ofbiz-component name=example xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=http://ofbiz.apache.org/dtds/ofbiz-component.xsd; !-- define resource loaders; most common is to use the component resource loader so we use it; if you want a different one then use the resource-loader element-- !-- the following folders, if present, will be added to the classpath: config, dtd; use the classpath element with attribute type=dir to add more -- !-- all the jar files in the following folders, if present, will be added to the classpath: build/lib, lib; use the classpath element with attribute type=jar to add more -- !-- all the entity definitions files and eca definition files and group definition files in the folder entitydef will be loaded using the reader-name=main and loader=main; use the element entity-resource to specify different resources -- !-- the data files in the data subfolders will be loaded considering the subfolder name as the reader-name: for example data/seed/ will be loaded when seed data are loaded, data/demo will be loaded when demo data is loaded; you can create a new reader-name simply adding a new subfolder -- !-- service definition files, eca(s) and group definitions will be loaded from the servicedef folder; use the service-resource element ...-- !-- all the test suites in the testdef folder will be executed using the loader=main; use
Re: Framework refactor
I don't think it will be easy and actually it may be unfeasible but I see some good reasons for hope: * the general discussion/vote would involve all committers and not only PMC members: everyone would be involved in the decision and in the responsibilities/consequences around it * our committers group is made of clever persons that know we are all playing on top of a system that is bigger than us, that is very complex and has been built thanks to the visions and great ideas/skills of others; we have to make sure we do not ruin what we are asked to maintain and improve and, with such a big and complex beast, working together as a group is the only responsible way of achieving this difficult task... on the other hand continuing to think as individuals with our own personal goals and ideas will make a mess of this project soon Jacopo On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote: You are a lot more optimistic than I am. Despite the best efforts of PMC members to provide advice/guidance/suggestions, committers still do what they please. It's worth a try, but I don't have much hope for success. -Adrian On 3/1/2012 1:48 PM, Jacopo Cappellato wrote: On Mar 1, 2012, at 11:39 AM, Adrian Crum wrote: I understand the workflow you are suggesting - cut down the size of the existing framework and then switch to something else. In an ideal world we could do that. Unfortunately, we have a lot of committers who believe more is better, so while we're cutting down in one area, someone else will be adding code in another area. Yes, I know what you mean: I still think that, if the goal is clear and the strategy makes sense (e.g. simplify/standardize the tools used, for example migrate everything from bsh to groovy, and then slim down the current framework to the bare minimum technologies used by the official applications in order to simplify and renew the code base) we could try to work to get a majority approval and a shared strategy and then everyone will have to stick to the plan and help to implement it... i.e. working as a community rather than as individual with commit rights and different visions. Jacopo
Re: Framework refactor
Before even start to plan a new framework we should indeed at least carefully review what David did in Moqui. I actually already spent some time reviewing some parts of it and I will continue for sure as I am very interested in all the work that David does. If the OFBiz community will ever consider to adopt Moqui as the new framework then a lot of decision will have to be taken: forking Moqui and import its source files in the OFBiz svn? Use Moqui releases as external jars and have the OFBiz community only work on the ERP part? Collaborate with the Moqui community to get the features that we need in OFBiz? A lot of questions for the future... but in the meantime I agree with Jacques that we can take small steps to improve what we already have: agree on a plan (e.g. simplifying/cleaning the framework in preparation of a future evolution, Moqui or something else) and then stick to it moving at small steps in the same direction. Jacopo On Mar 2, 2012, at 6:59 AM, Hans Bakker wrote: Shouldn't we considering replacing the ofbiz framework with th Moqui framework? David (with Andy) created the OFBiz framework, learned from it and created Moqui using this knowledge. Why not have all people interested refactoring the OFBiz framework join the Moqui project? David, what do you think? Regards, Hans On 03/02/2012 10:31 AM, Jacques Le Roux wrote: From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com I don't think it will be easy and actually it may be unfeasible but I see some good reasons for hope: * the general discussion/vote would involve all committers and not only PMC members: everyone would be involved in the decision and in the responsibilities/consequences around it * our committers group is made of clever persons that know we are all playing on top of a system that is bigger than us, that is very complex and has been built thanks to the visions and great ideas/skills of others; we have to make sure we do not ruin what we are asked to maintain and improve and, with such a big and complex beast, working together as a group is the only responsible way of achieving this difficult task... on the other hand continuing to think as individuals with our own personal goals and ideas will make a mess of this project soon I'd be very happy to see some sense of responsability to increase in the community. And I have the feeling that it's the case. We communicate better, and better respect each other ideas and ways. This said, there are huges task ahead... As I said in another email, I'm more for the step by step approach than to try a dramatic change, ie more evolution thant revolution PS: to be more clear, when I speak about step by step approach I think about something like this part of a previous email: 1) migrate the remaining Beanshell snippets to Groovy 2) deprecate or remove (I see a lot of value in having lighter framework [*]) Beashell support (and other artifacts related to old/unused script engines) 3) (optional, something for the future) refactor the GroovyUtil class (and code that is using it) to be generic (ScriptUtil) and convert all the calling code to use it in a Groovy unaware way; this will implement the JSR-223 In this way, when we will work on #3 we could concentrate only on migration of groovy classes rather than having to cope with several other technologies (removed at #2) Kind regards, Jacopo [*] In my opinion one of the main big steps that the OFBiz project should consider is to greatly slim down the framework and only support the technology we really need (picking the best for each task); then with a much smaller codebase, we will be able to quickly improve the framework (less code to maintain etc...) to be compliant with new standards etc.. (e.g. JSR-223). For example in this context: ideally the OFBiz project should have all the scripts implemented in Groovy (one technology) and a simple way to integrate other scripting languages; we could achieve this implementing JSR-223 so that even the OFBiz code would be using javax.script.* rather than groovy.* packages OR it would be also fine if we would still be using groovy.* packages but in a clean way (e.g. all calling code could use interfaces to hide Groovy specific code) so that adding a new script engine would be easy (but the support of the new script engine will not be included in the project to keep it light and focused) Then, when done (I mean not only this part but also some needeeed others), an approach like suggested by Adrian could be adopted... My 2cts Jacques Jacopo On Mar 1, 2012, at 3:47 PM, Adrian Crum wrote: You are a lot more optimistic than I am. Despite the best efforts of PMC members to provide advice/guidance/suggestions, committers still do what they please. It's worth a try, but I don't have much hope for success. -Adrian On 3/1/2012 1:48 PM
Re: Who is using the seleniumxml and why?
Moving to the dev list: On Mar 1, 2012, at 11:51 AM, Erwan de FERRIERES wrote: what I'm planning to include is just the basics : jars and tasks. Maybe some tests as an example, like a basic login, and some actions with the example component. If there is time remaining, the selenium tests here https://issues.apache.org/jira/browse/OFBIZ-3511 could be migrated to webdriver and included too. Interesting and promising, I am sure it will be very useful; by the way I would like to think if it is a good fit for the OFBiz framework... at the moment I am more inclined to think that it this should be an external component/project made of: * documentation of how to run Selenium on OFBiz * a library of OFBiz tests for Selenium * jars (if needed) or if you want to bundle Selenium in this package In this way users interested in running the tests in OFbiz will download the package as a separate download from the OFbiz release. In fact, also based on the feedback from the users list it seems that there are several opinions and strategies on the best tools for these tests. In the future someone could contribute a new set of tests for a different tool and we could also provide download links for them too instead of bundling everything into the framework. I would see some advantages in helping these efforts grow into separate open source projects out of the ASF community (they will be more dynamic and free to evolve and they will help to grow an healthy OFBiz ecosystem) but if instead we want to own the code then we should probably add them in another place in our svn repository: a new folder like extra or similar would work to collect all the components or tools like this that will not be release in the same release package but will be released separately (e.g. Apache OFBiz Selenium Tests 1.0). In the extra (but we can find a better name) should actually go also some of the components currently in specialpurpose. And we could release them separately, if not individually, we could release Apache OFBiz Extras 1.0. Regards, Jacopo
Re: Framework refactor
On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: Jacopo, You would even consider forking? This sounds more that you want to be in control than going for the best and work together. me? I would like to propose to join the Moqui framework and when ready, use in OFBiz the jars only as we do with other open source products. As I said, this is something to consider for sure... but in the same time we have to consider all options: currently the OFBiz community is about the development of a framework and ERP system and if we change this goal it will be a big decision, so we have to consider all the pros and cons. My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui Regards, Hans
Re: Framework refactor
Yes, I know what I wrote. My question was about your sentence: This sounds more that you want to be in control than going for the best and work together. and I was asking you if the you word in it was referred to me or to the community in general... now you have clarified that it was referred to me and you are accusing me to be unfair and look for the power. Got it. I will reply to your email later. Jacopo On Mar 2, 2012, at 8:20 AM, Hans Bakker wrote: Jacopo, please read in the original message.you took it away here. you wrote: - If the OFBiz community will ever consider to adopt Moqui as the new framework then a lot of decision will have to be taken: forking Moqui and import its source files in the OFBiz svn? - That you even consider this as the first optionnot sound good.. Regards On 03/02/2012 02:05 PM, Jacopo Cappellato wrote: On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: Jacopo, You would even consider forking? This sounds more that you want to be in control than going for the best and work together. me? I would like to propose to join the Moqui framework and when ready, use in OFBiz the jars only as we do with other open source products. As I said, this is something to consider for sure... but in the same time we have to consider all options: currently the OFBiz community is about the development of a framework and ERP system and if we change this goal it will be a big decision, so we have to consider all the pros and cons. My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui Regards, Hans
Re: Applying the Configuration By Exception concept more extensively
You are right Adrian... actually this would be the last thing to touch but we could use a different convention like: data/some name_seed.xml data/some name_demo.xml or more simply: data/seed.xml data/demo.xml (where the filename is the reader name) and then consider to merge all seed records in some name_seed.xml and all records for demo in some name_demo.xml Jacopo On Mar 2, 2012, at 9:06 AM, Adrian Crum wrote: I don't think we can eliminate the seed/demo data readers. In most cases, data loading must be done in a certain order. -Adrian On 3/1/2012 2:53 PM, Jacopo Cappellato wrote: A decent description of the Configuration By Exception concept is the following [*]: Java EE 5 introduced the idea of configuration by exception (sometimes referred to as programming by exception or convention over configuration). This means, unless specified differently, the container or provider should apply the default rules. In other words, having to supply a configuration is the exception to the rule. This allows you to write the minimum amount of code to get your application running, relying on the container and provider defaults. To some extent the OFBiz framework already applied this pattern is some areas (you may remember when we made the entity group-name org.ofbiz the default value and then were able to remove a bunch of configuration files); however I see a lot of room for further apply it, starting from the ofbiz-component.xml files. For example, considering the ofbiz-component.xml file in framework/example: ofbiz-component name=example xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=http://ofbiz.apache.org/dtds/ofbiz-component.xsd; !-- define resource loaders; most common is to use the component resource loader -- resource-loader name=main type=component/ !-- place the config directory on the classpath to access configuration files -- classpath type=dir location=config/ classpath type=dir location=dtd/ !-- load single or multiple external libraries -- classpath type=jar location=build/lib/*/ !-- entity resources: model(s), eca(s), group, and data definitions -- entity-resource type=model reader-name=main loader=main location=entitydef/entitymodel.xml/ entity-resource type=model reader-name=main loader=main location=entitydef/entitymodel_view.xml/ !--entity-resource type=eca reader-name=main loader=main location=entitydef/eecas.xml/ -- entity-resource type=data reader-name=seed loader=main location=data/ExampleTypeData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExampleSecurityData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExamplePortletData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExamplePortalSeedData.xml/ entity-resource type=data reader-name=seed loader=main location=data/ExampleHelpData.xml/ entity-resource type=data reader-name=demo loader=main location=data/ExampleDemoData.xml/ !-- service resources: model(s), eca(s) and group definitions -- service-resource type=model loader=main location=servicedef/services.xml/ service-resource type=eca loader=main location=servicedef/secas.xml/ !-- service-resource type=group loader=main location=servicedef/groups.xml/ -- test-suite loader=main location=testdef/tests.xml/ !-- web applications; will be mounted when using the embedded container -- webapp name=example title=Example menu-name=secondary server=default-server location=webapp/example base-permission=OFBTOOLS,EXAMPLE mount-point=/example/ webapp name=birt title=BIRT server=default-server location=webapp/birt base-permission=OFBTOOLS,WEBTOOLS mount-point=/birt app-bar-display=false/ /ofbiz-component If we assume that the default layout of an OFBiz component is the one used by the example component (and actually by all our components) we could simply have: ofbiz-component name=example xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:noNamespaceSchemaLocation=http://ofbiz.apache.org/dtds/ofbiz-component.xsd; !-- define resource loaders; most common is to use the component resource loader so we use it; if you want a different one then use the resource-loader element-- !-- the following folders, if present, will be added to the classpath: config, dtd; use the classpath element with attribute type=dir to add more -- !-- all the jar files in the following folders, if present, will be added to the classpath: build/lib, lib; use the classpath element with attribute type=jar to add more -- !-- all the entity definitions files and eca definition files and group
Re: Framework refactor
On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote: Jacopo, You would even consider forking? From Wikipedia [*]: [...] More recently, distributed revision control (DVCS) tools have popularised a less emotive use of the term fork, blurring the distinction with branch. With a DVCS such as Mercurial or Git, the normal way to contribute to a project is to first branch the repository, and later seek to have your changes integrated with the main repository. Sites such as Github, Bitbucket and Launchpad provide free DVCS hosting expressly supporting independent branches, such that the technical, social and financial barriers to forking a source code repository are massively reduced. In order of preference (descending), here are the options I see for the future of the OFBiz framework: 1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then release it separately from the Apache OFBiz ERP 2) greatly clean up and improve the existing framework (I was not sure if this could go at #1) 3) if the above will not be possible (frankly speaking, in the committers group, apart from David, none of us ever implemented with success an open source framework) we should also consider to drop the existing code and have our community focusing on the ERP part (as Hans seems to advocate); at this point Moqui would be the most natural choice; if we will ever go with this path a great exchange of information will have to happen between the two projects: for example OFBiz will probably have to ask the Moqui framework to evolve some of its features; given the current nature of the Moqui project, I doubt that the OFBiz committers will be ever invited as committers there; if Moqui will be our choice, I see two possibilities: 3.a) we base the Apache OFBiz ERP on a release of Moqui: this will only be possible if Moqui release will have all the features we need (and if Moqui community will be interested in getting contribution to evolve in the direction required by OFBzi) 3.b) if 3.a will not be possible because OFBiz will need some features that Moqui community will not consider as a good fit for Moqui, then, under the guidance and bless of David, we could work on a fork: get the code from a Moqui release, import in our repository and add to it, in a controlled way, the features we need; of course this should be always kept as close as possible to the original code; we could synch our custom code with every new Moqui release; I was not thinking about *stealing* code to Moqui and the fact that David is both the founder of OFBiz and of Moqui and he is both in the OFBiz PMC and the leader of the Moqui project will definitely facilitate this; but it will be still an ugly solution but for example when you said: My proposal is that Apache OFBiz will be in the future just the ERP system based on many opensource products like birt and also Moqui you are actually implying that the ERP applications will be able to use Birt... but this requires some sort of framework and what would you do if Moqui will not think that Birt is a good fit for them? 4) if Moqui will not be a good option we may consider other frameworks (?), but it will be difficult, or continue with what we have Jacopo [*]: http://en.wikipedia.org/wiki/Fork_(software_development)
Proposal for some changes to the layout of the OFBiz svn repository
In preparation for bigger changes :-) I would like to propose the addition of two new folders to the OFBiz svn repository: branches/ tags/ archive/ (NEW) trunk/ trunk/extras (NEW) The archive folder will be used for keeping an archive of no more used components or pieces of code: for example the specialpurpose/shark and the framework/jetty components could be moved there (but of course we will vote for each component's move); the idea is that the code under the archive folder is not planned to be released (but of course plans could change if there is an interest in the community) but in the same time we prefer to keep the code available to be resurrected The trunk/extras folder is actually very similar to specialpurpose (I have also considered to propose to rename it to extras): it will contain optional components or tools (not necessarily OFBiz components) like the support for Selenium tests (and the tests themselves) etc... The idea is that the content of this folder will not be released in the Apache OFBiz releases but it will be instead released by the OFBiz community as a separate product like Apache OFBiz Extras or similar. What do you think? Jacopo
Re: Service alert: ofbiz-vm.apache.org/HTTP - Ofbiz Demo Trunk is WARNING
On Mar 3, 2012, at 11:44 AM, Jacques Le Roux wrote: And the trunk demo has been (it seems) normally stopped Not sure why... Yeah, I know why but can't tell you at the moment (not in this public list) Jacopo
Re: Definitively remove beanshell from OFBiz
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote: As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the embedded cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient. I can help out with the conversion. I don't think the task will be that hard. Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task. I will commit my code changes today. Regards, Jacopo
Re: Definitively remove beanshell from OFBiz
My changes are in commit 1296762 Help with reviews and tests will be very much appreciated. Jacopo On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote: On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote: As far as I know, most scripting engines have some sort of embedded cache. The problem will be that we can't clear the embedded cache like we can with our own cache implementation. I don't see that as a show stopper - it's mostly inconvenient. I can help out with the conversion. I don't think the task will be that hard. Adrian, FYI I am enhancing some of the existing framework code that uses the GroovyUtil class to simplify this task. I will commit my code changes today. Regards, Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently implemented: now all the code
that had a dependency on Groovy or Beanshell packages has been converted to be
only dependent on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are preparsed/executed) and
also check if we can always assume that if the code inside of ${...} starts
with a string (no spaces) followed by a colon (and a blank character?) then the
string is the scripting language: I didn't check the impact on existing scripts
but it should be easy to write a reg exp to find all of them (I expect that the
number will be small) and modify them to be compatible with the convention. I
intentionally didn't focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate
how scritps are parsed?
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because
Groovy will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan was
to completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting language
in custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crum adrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the
embedded
cache like we can with our own cache implementation. I don't see that
as a show stopper - it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be that
hard.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223 (Was: Definitively remove beanshell from OFBiz)
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have a
strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by all
the existing scripts and by some other code like the implementation of Groovy
service engine and Groovy event handler) and so the dependency on Groovy
will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic
Groovy snippets like ${groovy: ...}; I have some concerns in this area that I
will address in a separate email soon; in this way we will secure the ootb
system (packaged with several groovy scripts and the groovy jars) but of course
if the user will add to it jars files for a new scripting language (executed
using JSR-223) then the security issue will still be there, but at least the
user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts, so
that they can be used by Groovy scripts to run services, use the delegator
etc...
We should also consider the impact on performance, even if the best way to go
is probably to run some performance tests on the system running Groovy with
current code and with the system running Groovy using a custom method and then
compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded cache.
The problem will be that we can't clear the embedded cache like we can
with our own cache implementation. I don't see that as a show stopper -
it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be that
hard.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
Yes, this is fine and I was thinking about a similar solution; however I would
like to find a simpler convention because [script:groovy] is a lot of typing
and could be difficult to read when the code in buried in the value attribute
of a set element.
Something like:
${script:jython code_here}
${script:groovy code_here}
${script: code_here} this could use the default language set in some
properties file (i.e. groovy); this follows the configuration by exception
pattern (specify the script only if you want to use a non default one).
But we should also consider a shortcut where the script word is abbreviated,
for example by the s word:
${s:jython code_here}
${s:groovy code_here}
${s: code_here}
Jacopo
On Mar 5, 2012, at 8:41 AM, Adrian Crum wrote:
I was thinking we could use something like ${[script:groovy]...}
${[script:jython]...} etc. I'm concerned that looking for a string followed
by a colon can lead to errors.
-Adrian
On 3/5/2012 6:22 AM, Jacopo Cappellato wrote:
I would like to clarify that in this first pass I focused on moving code
around keeping the same exact behavior currently implemented: now all the
code that had a dependency on Groovy or Beanshell packages has been
converted to be only dependent on ScriptUtil class.
In order to implement JSR-223 we may have to change some of the current
behavior (the different way Beanshell and Groovy are preparsed/executed) and
also check if we can always assume that if the code inside of ${...} starts
with a string (no spaces) followed by a colon (and a blank character?) then
the string is the scripting language: I didn't check the impact on existing
scripts but it should be easy to write a reg exp to find all of them (I
expect that the number will be small) and modify them to be compatible with
the convention. I intentionally didn't focus on this second step.
Jacopo
On Mar 4, 2012, at 10:27 PM, Jacques Le Roux wrote:
I must says I only cursorily reviewed the code Jacopo committed and did not
look into JSR-223 details.
So I thought at some point you have to check which language wich is used?
Like in
+if (groovy.equals(language)) {
+if (scriptClass == null) {
+scriptClass = ScriptUtil.parseScript(language, script);
+}
+if (scriptClass != null) {
+result = InvokerHelper.createScript(scriptClass,
GroovyUtil.getBinding(inputMap)).run();
+}
+} else if (bsh.equals(language)) {
+result = BshUtil.eval(script,
UtilMisc.makeMapWritable(inputMap));
+}
In other words from Jacopo's code here, it seems you have to differentiate
how scritps are parsed?
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
Groovy supports JSR-223, so there is no reason to treat it differently. My
question has nothing to do with which scripting engine
is supplied with OFBiz.
-Adrian
On 3/4/2012 8:43 PM, Jacques Le Roux wrote:
I don't want to interfer with Jacopo's answer, but I guess it's because
Groovy will be implemented OOTB. The others could be but
Groovy is already part of the framework (the inital subject from Erwan
was to completely remove BeanShell OOTB usage), I mean
it's the idea and what Jacopo said already.
I second this idea. Everybody can use her/his preferred scripting
language in custom projects. But using only one language OOTB
seems to be common sense. We chose groovy...
Jacques
From: Adrian Crumadrian.c...@sandglass-software.com
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think
that?
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the
embedded
cache like we can with our own cache implementation. I don't see that
as a show stopper - it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be
that hard.
Adrian, FYI I am enhancing some of the existing framework code that
uses the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would be
an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of scripts.
If the user will add a new jar to support a different script (and the user will
also have to implement the custom scripts) then this will be less secure but
there isn't much we could do as we delegate to JSR-223 the implementation of
security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be language
specific) but for now we can postpone this discussion at when (if it will ever
happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled independently
from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange design
ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't have
a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by
all the existing scripts and by some other code like the implementation of
Groovy service engine and Groovy event handler) and so the dependency on
Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain for
it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for dynamic
Groovy snippets like ${groovy: ...}; I have some concerns in this area that
I will address in a separate email soon; in this way we will secure the
ootb system (packaged with several groovy scripts and the groovy jars) but
of course if the user will add to it jars files for a new scripting language
(executed using JSR-223) then the security issue will still be there, but at
least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy scripts,
so that they can be used by Groovy scripts to run services, use the
delegator etc...
We should also consider the impact on performance, even if the best way to
go is probably to run some performance tests on the system running Groovy
with current code and with the system running Groovy using a custom method
and then compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the embedded cache like
we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.
I can help out with the conversion. I don't think the task will be that
hard.
Adrian, FYI I am enhancing some of the existing framework code that uses
the GroovyUtil class to simplify this task.
I will commit my code changes today.
Regards,
Jacopo
Re: Implementing JSR-223
On Mar 5, 2012, at 8:57 AM, Adrian Crum wrote:
Btw, expressions should go in the from-field attribute, not the value
attribute.
Well, the mechanism value=${groovy: ...} is actually used a lot currently;
and in the from-field attribute the ${groovy: is not required.
Jacopo
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Hey Hans, (and all OFBiz committers in general)
I would like to stress the importance to address reviews on commits (especially
if they come from committers, like me, because we have veto on commits) asap
by improving the code or reverting it.
Actually the etiquette when a committer complains about a commit and motivates
the concerns (as I did) should be:
1) immediately improve the code according to the committer's review
2) or immediately provide additional information if you think that the code is
good and that, with the additional details, the reviewer will be satisfied; if
the discussion takes longer then the commit should be reverted until the
agreement is found
3) or immediately revert it
The fact that we use a commit then review approach doesn't mean that every
committers has the power to commit what he wants ignoring the others... the
opposite is actually true: every time we do a commit we should be ready to
receive feedback and improve the code; only at that point the code will become
official.
I hope this is the last time I have to state this fundamental rule,
Jacopo
On Feb 29, 2012, at 10:40 AM, Jacopo Cappellato wrote:
Hi Hans,
I don't like the assumption about the string control: this is a
configurable value (in web.xml) and we should not have it hardcoded in our
code.
I know there are already few examples of this bad pattern and in fact we
should work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl =
prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT, );
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product =
delegator.findOne(Product, UtilMisc.toMap(productId, productId), false);
ProductContentWrapper wrapper = new
ProductContentWrapper(dispatcher, product, locale, text/html);
-url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId);
+url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId);
} else {
GenericValue productCategory =
delegator.findOne(ProductCategory, UtilMisc.toMap(productCategoryId,
productCategoryId), false);
CategoryContentWrapper wrapper = new
CategoryContentWrapper(dispatcher, productCategory, locale, text/html);
-url =
CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId,
viewSize, viewIndex, viewSort, searchString);
+url =
CatalogUrlFilter.makeCategoryUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Thank Hans,
from now on please revert the commit until you find time to commit a better
version.
Regards,
Jacopo
On Mar 5, 2012, at 12:01 PM, Hans Bakker wrote:
Jacopo,
in general i honor all comments although it can take some time, also this one
it is comming
Regards,
Hans
On 03/05/2012 05:57 PM, Jacopo Cappellato wrote:
Hey Hans, (and all OFBiz committers in general)
I would like to stress the importance to address reviews on commits
(especially if they come from committers, like me, because we have veto on
commits) asap by improving the code or reverting it.
Actually the etiquette when a committer complains about a commit and
motivates the concerns (as I did) should be:
1) immediately improve the code according to the committer's review
2) or immediately provide additional information if you think that the code
is good and that, with the additional details, the reviewer will be
satisfied; if the discussion takes longer then the commit should be reverted
until the agreement is found
3) or immediately revert it
The fact that we use a commit then review approach doesn't mean that every
committers has the power to commit what he wants ignoring the others... the
opposite is actually true: every time we do a commit we should be ready to
receive feedback and improve the code; only at that point the code will
become official.
I hope this is the last time I have to state this fundamental rule,
Jacopo
On Feb 29, 2012, at 10:40 AM, Jacopo Cappellato wrote:
Hi Hans,
I don't like the assumption about the string control: this is a
configurable value (in web.xml) and we should not have it hardcoded in our
code.
I know there are already few examples of this bad pattern and in fact we
should work and fix them as well.
Jacopo
On Feb 29, 2012, at 10:23 AM, hans...@apache.org wrote:
Author: hansbak
Date: Wed Feb 29 09:23:36 2012
New Revision: 1295029
URL: http://svn.apache.org/viewvc?rev=1295029view=rev
Log:
correct url generation for seo friendly url's
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
ofbiz/trunk/specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Modified:
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java?rev=1295029r1=1295028r2=1295029view=diff
==
---
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
(original)
+++
ofbiz/trunk/applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java
Wed Feb 29 09:23:36 2012
@@ -102,6 +102,7 @@ public class OfbizCatalogAltUrlTransform
String productCategoryId = getStringArg(args,
productCategoryId);
String productId = getStringArg(args, productId);
String url = ;
+String CONTROL_MOUNT_POINT = control;
Object prefix = env.getVariable(urlPrefix);
String viewSize = getStringArg(args, viewSize);
@@ -127,14 +128,19 @@ public class OfbizCatalogAltUrlTransform
Delegator delegator =
FreeMarkerWorker.getWrappedObject(delegator, env);
LocalDispatcher dispatcher =
FreeMarkerWorker.getWrappedObject(dispatcher, env);
Locale locale = (Locale) args.get(locale);
+String prefixUrl = prefix.toString();
+// remove control path from the prefix URL
+if(prefixUrl.contains(CONTROL_MOUNT_POINT)){
+prefixUrl =
prefixUrl.replaceAll(/+CONTROL_MOUNT_POINT, );
+}
if (UtilValidate.isNotEmpty(productId)) {
GenericValue product =
delegator.findOne(Product, UtilMisc.toMap(productId, productId),
false);
ProductContentWrapper wrapper = new
ProductContentWrapper(dispatcher, product, locale, text/html);
-url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, ((StringModel)
prefix).getAsString(), previousCategoryId, productCategoryId, productId);
+url =
CatalogUrlFilter.makeProductUrl(delegator, wrapper, null, prefixUrl,
previousCategoryId, productCategoryId, productId);
} else {
GenericValue productCategory =
delegator.findOne(ProductCategory, UtilMisc.toMap(productCategoryId,
productCategoryId), false);
CategoryContentWrapper wrapper = new
CategoryContentWrapper(dispatcher, productCategory, locale, text/html
Re: svn commit: r1295029 - in /ofbiz/trunk: applications/product/src/org/ofbiz/product/category/OfbizCatalogAltUrlTransform.java specialpurpose/ecommerce/widget/EmailOrderScreens.xml
Yes, *reverting* and then sending a word back that an improved version is in progress would also be fine. Jacopo On Mar 5, 2012, at 12:10 PM, Jacques Le Roux wrote: Maybe then sending back a word saying that it's a WIP would help ;o) Jacques
Re: Discussion: Mini-language Overhaul
I am a big fan of Minilang too.
The evolution strategy that I would like to see implemented for Minilang is
actually the same one I would liketo see applied to OFBiz framework in general:
review the current usage of the tool, fix existing usage for consistency
(upgrade old code to use newer mechanisms offered by the tool), get rid of
unused or old mechanisms in the attempt to slim down the size of the framework
code, unify/simplify mechanisms based on lesson learned; all of this could be
useful even to prepare the future migration to a different tool (e.g. Groovy).
I know that it is very vague and doesn't add much to this thread but I like the
approach suggested by Adrian.
In my opinion, a good way to define a new version of the set operation could
be that of analyzing how we are currently using the operation in OFBiz: as a
starting point we could start by searching all occurrences of set string in
OFBiz, then review them and see different patterns; discuss and define the few
ones that we like more, convert all code to use them consistently, then (or in
the same phase) define the new element to better implement the patterns that we
like.
And now I am switching to the brainstorming mode :-)
Kind regards,
Jacopo
brainstorming
I would like to have a set operation that implements some of the ideas of the
configure by exception concept.
As regards the type supported, but pending the review of existing usage, we may
consider to only support these:
* Object
* List
* Map
* BigDecimal/BigInteger (all numbers in Minilang should be treated as
BigDecimal; no support for Integer, Float etc...)
* String (expander i.e. the equivalent of GString in Groovy)
* a date object
Then we could get rid of the from-field attribute and replace it with a
from attribute that can take as input a single field (as it is now) or an
expression; some examples (all the following are evaluated using Groovy except
where a different language is specified i.e. default scripting language):
set field=field1 from=parameters.inputField1/ // field1 will have the
same type of inputField1
set field=field2 from=parameters.inputField1 + parameters.inputField2/ //
if inputField1 and inputField2 are numbers then field2 will be the BigDecimal
sum of the two
set field=field3 from=parameters.inputField1 * 10/
set field=field4 from=script:bsh parameters.inputField1 + 10/ // use
Beanshell
set field=field5 from=parameters.inputField1 type=BigDecimal/ // if
inputField1 is a string representation of a number we can convert with the
explicit definition of the type
For the constant values (I am not sure if it is a good idea, but for now I will
throw it out):
set field=stringField value=This is a string/
set field=stringField value=This is a string with a ${variable}/
// the following two are equivalent
set field=bigDecimalField value=100/ // the system attempt to parse 100
as a number first (BigDecimal) and then as a string
set field=bigDecimalField value=100 type=BigDecimal/
set field=stringField value=100 type=String/ // treat the field as a
string
/brainstorming
On Mar 5, 2012, at 9:07 PM, Adrian Crum wrote:
I am not one of those people. I use mini-lang almost exclusively.
-Adrian
On 3/5/2012 7:46 PM, Anil Patel wrote:
Adrian,
Thanks for starting this thread.
While we all love mini-lang, I am wondering if we should really ask
ourselves if we really want to overhaul mini-lang or should we consider
alternates. From what I know, Not many people like to build application
using mini lang. Many end up using Java or Groovy.
Thanks and Regards
Anil Patel
HotWax Media Inc
On Mar 5, 2012, at 9:47 AM, Adrian Crum wrote:
Mini-language has evolved a lot over the years. Most of the development has
occurred on an as-needed basis, so there is no clear design or
implementation - things just get tacked on over time.
A recent discussion has opened up the possibility to rework the
mini-languageset element. From my perspective, that task is long overdue.
Also, the schemas are out of date, and they are unnecessarily complicated.
So, those need a thorough going over.
While we are at it, why don't we create a draft design document based on
the current implementation, and then use it to look for other ways
mini-language can be improved? We can all offer suggestions and comments,
agree on a final design, finalize the draft, and then implement it in code.
The design document then becomes the developer's reference.
What do you think?
-Adrian
Re: Implementing JSR-223
This could work but I was thinking to something more like having some core
packages (like entity and service) always imported in groovy scripts/services;
or having the delegator and dispatcher objects properly casted to their
interfaces (to take advantage of IDE autocompletion features); etc...
But I don't have a clear list at the moment so please do not consider my notes
a blocker.
I am working at a POC for a best practice Groovy service implementation and
this should end up with a wish list of features I would like to have. Then we
can discuss the best way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during the
design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you have
in mind could be implemented in a generic way and reused. Personally, I would
like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience
of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there would
be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to run
Groovy scripts in a secure way and already packaged with hundreds of
scripts.
If the user will add a new jar to support a different script (and the user
will also have to implement the custom scripts) then this will be less
secure but there isn't much we could do as we delegate to JSR-223 the
implementation of security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be
language specific) but for now we can postpone this discussion at when (if
it will ever happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange
design ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't
have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required by
all the existing scripts and by some other code like the implementation of
Groovy service engine and Groovy event handler) and so the dependency
on Groovy will still be there even if we run it with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain
for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I don't
think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for
dynamic Groovy snippets like ${groovy: ...}; I have some concerns in this
area that I will address in a separate email soon; in this way we will
secure the ootb system (packaged with several groovy scripts and the
groovy jars) but of course if the user will add to it jars files for a new
scripting language (executed using JSR-223) then the security issue will
still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy
scripts, so that they can be used by Groovy scripts to run services, use
the delegator etc...
We should also consider the impact on performance, even if the best way to
go is probably to run some performance tests on the system running Groovy
with current code and with the system running Groovy using a custom method
and then compare the results.
Jacopo
-Adrian
On 3/4/2012 7:27 AM, Jacopo Cappellato wrote:
My changes are in commit 1296762
Help with reviews and tests will be very much appreciated.
Jacopo
On Mar 3, 2012, at 1:45 PM, Jacopo Cappellato wrote:
On Mar 1, 2012, at 10:51 AM, Adrian Crum wrote:
As far as I know, most scripting engines have some sort of embedded
cache. The problem will be that we can't clear the embedded cache like
we can with our own cache implementation. I don't see that as a show
stopper - it's mostly inconvenient.
I can help out with the conversion
Re: Discussion: Mini-language Overhaul
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited number of types.
Currently, mini-lang supports any type - thanks to the conversion framework.
The conversion framework is fine; I was thinking that we could implicitly (by
default) treat in Minilang all the numbers as BigDecimals, all the strings as
GStrings/Expandable Strings; where special conversions are required than the
type can be specified.
I like the idea of changing the from-field attribute to from. I would like to
see a from-script attribute added:
set field=field4 from-script=groovy: parameters.inputField1 + 10/!--
Use Groovy --
and why not:
set field=field4 from=parameters.inputField1/!-- Use Groovy internally:
refactor OFBiz custom code to delegate on Groovy the evaluation of simple
assignments; this could potentially replace FlexibleStringExpander related code
--
set field=field4 from=groovy: parameters.inputField1 + 10/!-- Use Groovy
explicitly to evaluate the expression (use the same from attribute instead of
a separate from-script)--
set field=field4 from=parameters.inputField1 + 10/!-- Use Groovy (by
default, configurable) to evaluate the expression--
set field=field4 from=beanshell: parameters.inputField1 + 10/!-- Use
Beanshell to evaluate the expression--
?
Then we can remove script support from expressions, which will eliminate ugly
hacks like:
set field=field4 value=${groovy: parameters.inputField1 + 10}/
+1
Jacopo
-Adrian
On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
I am a big fan of Minilang too.
The evolution strategy that I would like to see implemented for Minilang
is actually the same one I would liketo see applied to OFBiz framework in
general: review the current usage of the tool, fix existing usage for
consistency (upgrade old code to use newer mechanisms offered by the tool),
get rid of unused or old mechanisms in the attempt to slim down the size of
the framework code, unify/simplify mechanisms based on lesson learned; all
of this could be useful even to prepare the future migration to a different
tool (e.g. Groovy).
I know that it is very vague and doesn't add much to this thread but I like
the approach suggested by Adrian.
In my opinion, a good way to define a new version of the set operation
could be that of analyzing how we are currently using the operation in
OFBiz: as a starting point we could start by searching all occurrences of
set string in OFBiz, then review them and see different patterns;
discuss and define the few ones that we like more, convert all code to use
them consistently, then (or in the same phase) define the new element to
better implement the patterns that we like.
And now I am switching to the brainstorming mode :-)
Kind regards,
Jacopo
brainstorming
I would like to have a set operation that implements some of the ideas of
the configure by exception concept.
As regards the type supported, but pending the review of existing usage, we
may consider to only support these:
* Object
* List
* Map
* BigDecimal/BigInteger (all numbers in Minilang should be treated as
BigDecimal; no support for Integer, Float etc...)
* String (expander i.e. the equivalent of GString in Groovy)
* a date object
Then we could get rid of the from-field attribute and replace it with a
from attribute that can take as input a single field (as it is now) or an
expression; some examples (all the following are evaluated using Groovy
except where a different language is specified i.e. default scripting
language):
set field=field1 from=parameters.inputField1/ // field1 will have the
same type of inputField1
set field=field2 from=parameters.inputField1 + parameters.inputField2/
// if inputField1 and inputField2 are numbers then field2 will be the
BigDecimal sum of the two
set field=field3 from=parameters.inputField1 * 10/
set field=field4 from=script:bsh parameters.inputField1 + 10/ // use
Beanshell
set field=field5 from=parameters.inputField1 type=BigDecimal/ // if
inputField1 is a string representation of a number we can convert with the
explicit definition of the type
For the constant values (I am not sure if it is a good idea, but for now I
will throw it out):
set field=stringField value=This is a string/
set field=stringField value=This is a string with a ${variable}/
// the following two are equivalent
set field=bigDecimalField value=100/ // the system attempt to parse
100 as a number first (BigDecimal) and then as a string
set field=bigDecimalField value=100 type=BigDecimal/
set field=stringField value=100 type=String/ // treat the field as
a string
/brainstorming
On Mar 5, 2012, at 9:07 PM, Adrian Crum wrote:
I am not one of those people. I use mini-lang almost exclusively.
-Adrian
On 3/5/2012 7:46 PM, Anil Patel wrote:
Adrian,
Thanks for starting this thread.
While
Re: Implementing JSR-223
I would be in favor of bulk renaming all the context variables in our
scripts... maybe we could wait after the creation of the 12.04 release
branch... but I would be in favor even if we do this earlier.
Jacopo
On Mar 6, 2012, at 9:47 AM, Adrian Crum wrote:
Update: I added a generic ScriptEngine to the service engine in rev 1297323.
I haven't updated screen widgets and mini-lang to use JSR-223 because there
is a compatibility problem. In JSR-223, the context binding is reserved for
the ScriptContext object, so any script code that uses the variable context
will be using the ScriptContext object - not the context Map. I'm not sure
how to proceed from here.
-Adrian
On 3/6/2012 7:58 AM, Jacopo Cappellato wrote:
This could work but I was thinking to something more like having some core
packages (like entity and service) always imported in groovy
scripts/services; or having the delegator and dispatcher objects
properly casted to their interfaces (to take advantage of IDE autocompletion
features); etc...
But I don't have a clear list at the moment so please do not consider my
notes a blocker.
I am working at a POC for a best practice Groovy service implementation
and this should end up with a wish list of features I would like to have.
Then we can discuss the best way to achieve this.
Jacopo
On Mar 5, 2012, at 9:14 AM, Adrian Crum wrote:
If you don't mind, I would like to get all of the issues resolved during
the design phase.
I will wait for the private email to understand what you mean by a secure
scripting package.
What I was suggesting is a script utility object that can be put in the
context so that all scripting languages can use it. Whatever methods you
have in mind could be implemented in a generic way and reused. Personally,
I would like to use something like:
// Groovy, JavaScript
partyValue = script.entityOne(Party);
if (partyValue)...
In other words, have an object in the context that gives us the convenience
of mini-language.
-Adrian
On 3/5/2012 8:01 AM, Jacopo Cappellato wrote:
On Mar 5, 2012, at 8:46 AM, Adrian Crum wrote:
It seems to me if there is a security issue using Groovy, then there
would be an issue using any scripting language.
Yes, but what we would bundle ootb would be a secured packaged ready to
run Groovy scripts in a secure way and already packaged with hundreds of
scripts.
If the user will add a new jar to support a different script (and the user
will also have to implement the custom scripts) then this will be less
secure but there isn't much we could do as we delegate to JSR-223 the
implementation of security.
Why can't we put the friendly methods in the context, so all scripting
languages can use them?
I am not sure I understand what you are proposing (the method would be
language specific) but for now we can postpone this discussion at when (if
it will ever happen) we will discuss about this approach.
Jacopo
-Adrian
On 3/5/2012 6:46 AM, Jacopo Cappellato wrote:
On Mar 4, 2012, at 9:16 PM, Adrian Crum wrote:
The code changes tested fine.
I noticed in your code comments that Groovy should be handled
independently from other scripting languages. Why do you think that?
First of all, I apologize for having added my personal opinion to those
comments :-) but I thought that in this way it was easier to exchange
design ideas; the comments can actually be removed.
The reasons I think we could treat Groovy in a special way (but I don't
have a strong opinion on this) are:
* ootb OFBiz will still be packaged with Groovy jars (they are required
by all the existing scripts and by some other code like the
implementation of Groovy service engine and Groovy event handler)
and so the dependency on Groovy will still be there even if we run it
with JSR-223
* the code to run Groovy in the special way is now all contained in the
ScriptUtil class and there are actually a few lines of code to maintain
for it
* keeping a custom way for Groovy has two main advantages that are not
currently used but I would like to consider in the short term (and I
don't think they are supported thru JSR-223... but I am not sure):
** security: I would like to restrict the JVM security settings for
dynamic Groovy snippets like ${groovy: ...}; I have some concerns in
this area that I will address in a separate email soon; in this way we
will secure the ootb system (packaged with several groovy scripts and
the groovy jars) but of course if the user will add to it jars files for
a new scripting language (executed using JSR-223) then the security
issue will still be there, but at least the user will know about it
** I would like to inject some OFBiz friendly methods to all Groovy
scripts, so that they can be used by Groovy scripts to run services, use
the delegator etc...
We should also consider the impact on performance, even if the best way
Re: Discussion: Mini-language Overhaul
On Mar 6, 2012, at 10:03 AM, Adrian Crum wrote:
Replacing FSE with Groovy is a bad idea. Adam and I optimized FSE so that it
is very lightweight and fast. I also optimized the UEL integration so there
is very little overhead in the evaluation process. Switching everything to
Groovy will slow things down and increase memory usage. Also keep in mind
that Groovy creates a class for every script, so we will run out of permgen
space again.
Ok, makes perfect sense, thank you.
I think a wiser strategy would be to make mini-lang as feature complete as
possible, and include a from-script attribute for any feature gaps. In other
words, use from-script as a last resort - because it is costly.
+1: by the way we could still use the from attribute for both:
set field=field4 from=parameters.inputField1/ !-- use Minilang built-in
and efficient support --
set field=field4 from=parameters.inputField1 + 10/ !-- use Minilang
built-in and efficient support: not currently supported but maybe something to
consider in the future --
set field=field4 from=groovy: parameters.inputField1 + 10/ !-- use
Groovy (inefficient) --
Jacopo
-Adrian
On 3/6/2012 8:53 AM, Jacopo Cappellato wrote:
On Mar 6, 2012, at 9:32 AM, Adrian Crum wrote:
I don't understand what you mean by supporting a limited number of types.
Currently, mini-lang supports any type - thanks to the conversion framework.
The conversion framework is fine; I was thinking that we could implicitly
(by default) treat in Minilang all the numbers as BigDecimals, all the
strings as GStrings/Expandable Strings; where special conversions are
required than the type can be specified.
I like the idea of changing the from-field attribute to from. I would like
to see a from-script attribute added:
set field=field4 from-script=groovy: parameters.inputField1 + 10/!--
Use Groovy --
and why not:
set field=field4 from=parameters.inputField1/!-- Use Groovy
internally: refactor OFBiz custom code to delegate on Groovy the evaluation
of simple assignments; this could potentially replace FlexibleStringExpander
related code --
set field=field4 from=groovy: parameters.inputField1 + 10/!-- Use
Groovy explicitly to evaluate the expression (use the same from attribute
instead of a separate from-script)--
set field=field4 from=parameters.inputField1 + 10/!-- Use Groovy (by
default, configurable) to evaluate the expression--
set field=field4 from=beanshell: parameters.inputField1 + 10/!-- Use
Beanshell to evaluate the expression--
?
Then we can remove script support from expressions, which will eliminate
ugly hacks like:
set field=field4 value=${groovy: parameters.inputField1 + 10}/
+1
Jacopo
-Adrian
On 3/6/2012 7:31 AM, Jacopo Cappellato wrote:
I am a big fan of Minilang too.
The evolution strategy that I would like to see implemented for Minilang
is actually the same one I would liketo see applied to OFBiz framework in
general: review the current usage of the tool, fix existing usage for
consistency (upgrade old code to use newer mechanisms offered by the
tool), get rid of unused or old mechanisms in the attempt to slim down the
size of the framework code, unify/simplify mechanisms based on lesson
learned; all of this could be useful even to prepare the future migration
to a different tool (e.g. Groovy).
I know that it is very vague and doesn't add much to this thread but I
like the approach suggested by Adrian.
In my opinion, a good way to define a new version of the set operation
could be that of analyzing how we are currently using the operation in
OFBiz: as a starting point we could start by searching all occurrences of
set string in OFBiz, then review them and see different patterns;
discuss and define the few ones that we like more, convert all code to use
them consistently, then (or in the same phase) define the new element to
better implement the patterns that we like.
And now I am switching to the brainstorming mode :-)
Kind regards,
Jacopo
brainstorming
I would like to have a set operation that implements some of the ideas
of the configure by exception concept.
As regards the type supported, but pending the review of existing usage,
we may consider to only support these:
* Object
* List
* Map
* BigDecimal/BigInteger (all numbers in Minilang should be treated as
BigDecimal; no support for Integer, Float etc...)
* String (expander i.e. the equivalent of GString in Groovy)
* a date object
Then we could get rid of the from-field attribute and replace it with a
from attribute that can take as input a single field (as it is now) or
an expression; some examples (all the following are evaluated using Groovy
except where a different language is specified i.e. default scripting
language):
set field=field1 from=parameters.inputField1/ // field1 will have
the same type of inputField1
set field
