[jira] [Commented] (OFBIZ-4481) adding a new attribute ignore-when(verry similar to use-when) taht enabe rendering or not a field in list or multi form.
[ https://issues.apache.org/jira/browse/OFBIZ-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526394#comment-14526394 ] Wei Zhang commented on OFBIZ-4481: -- How about enhance the OOTB field ignore/, such as field name=conditionalDescignore ignore-when='Y'.equals(ignoreDescription)//field? adding a new attribute ignore-when(verry similar to use-when) taht enabe rendering or not a field in list or multi form. Key: OFBIZ-4481 URL: https://issues.apache.org/jira/browse/OFBIZ-4481 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: youssef khaye Priority: Minor Labels: form, list, use-when Attachments: ignoreField.patch I need to define some parameters (using portlet attributes) that enable showing or not some field in my portlet taht contains a form of type list. Or on a form of type list or multi, it is not possible to completely ignore a field via use-when attribute. Instead it hides the title and the column header became shifted from the table content. For example I want to hide the description column from my form when exampleName is choosen as sort-field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6034) Widget Refactoring: Refactor how links are rendered
[ https://issues.apache.org/jira/browse/OFBIZ-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526472#comment-14526472 ] Jacques Le Roux commented on OFBIZ-6034: We would need to create sub-tasks, but it's already one so we are screwed (Jira allows only 1 level). So we will create related issues rather Widget Refactoring: Refactor how links are rendered --- Key: OFBIZ-6034 URL: https://issues.apache.org/jira/browse/OFBIZ-6034 Project: OFBiz Issue Type: Sub-task Components: framework Affects Versions: Trunk Reporter: Pierre Smits Labels: ftl, java, links, xsd Currently links are rendered differently across menu, screen and form. We have: * link in menu-items * link in screens * hyperlink in forms, in field definitions * sub-hyperlink in forms, in display-entity in field definitions But how the links are rendered is not consistent. So can link-type=ajax-window be used to trigger a popup window, while it can't be used in a link in a menu-item, nor from a form -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6327) Make it available in forms
Jacques Le Roux created OFBIZ-6327: -- Summary: Make it available in forms Key: OFBIZ-6327 URL: https://issues.apache.org/jira/browse/OFBIZ-6327 Project: OFBiz Issue Type: Sub-task Reporter: Jacques Le Roux I don't see a need for menus, but could be. Relates also to OFBIZ-6034 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6305) German translations for various applications
[ https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6305: - Attachment: OFBIZ-6305-ProductErrorUiLabels.patch Next patch for the ProductErrorUiLabels... German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker Assignee: Christian Geisert Attachments: OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
buildbot success in ASF Buildbot on ofbiz-branch14
The Buildbot has detected a restored build on builder ofbiz-branch14 while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/ofbiz-branch14/builds/111 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: lares_ubuntu Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz14-commit' triggered this build Build Source Stamp: [branch ofbiz/branches/release14.12] 1677599 Blamelist: jacopoc Build succeeded! Sincerely, -The Buildbot
[jira] [Created] (OFBIZ-6328) createProductionRunsForOrder service doesn't handle cancelled production runs
Christian Carlow created OFBIZ-6328: --- Summary: createProductionRunsForOrder service doesn't handle cancelled production runs Key: OFBIZ-6328 URL: https://issues.apache.org/jira/browse/OFBIZ-6328 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow createProductionRunsForOrder doesn't create production runs whenever a WorkOrderItemFulfillment record exists even if workEffort.currentStatusId == PRUN_CANCELLED. The service should be enhanced to recognized canceled production runs and create replacements when no active ones are found. Extra logic may need to be added later to handle changing production run statuses from canceled back to an active state when another active production run took its place but as of right now such a status change is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6197) Allow production runs to be generated based on OrderItemShipGroupAssoc instead of only Shipment
[ https://issues.apache.org/jira/browse/OFBIZ-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6197: Attachment: (was: OFBIZ-6198.patch) Allow production runs to be generated based on OrderItemShipGroupAssoc instead of only Shipment --- Key: OFBIZ-6197 URL: https://issues.apache.org/jira/browse/OFBIZ-6197 Project: OFBiz Issue Type: New Feature Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Manufacturing Shipment Plan requires a shipment to be created before a production run can be generated to fulfill the corresponding OrderItemShipGroupAssoc. I propose adding the capability to generate production runs based on OrderItemShipGroupAssoc without having to create a shipment for it first. It seems unnecesarily cumbersome and redundant to require users to create a shipment and plan each order items corresponding the OrderItemShipGroupAssoc they already created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6323) LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types
[ https://issues.apache.org/jira/browse/OFBIZ-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526654#comment-14526654 ] Forrest Rae commented on OFBIZ-6323: Fair enough. Thanks! LookupProductAndPrice ajaxLookup should only return DEFAULT_PRICE rather than all the price types - Key: OFBIZ-6323 URL: https://issues.apache.org/jira/browse/OFBIZ-6323 Project: OFBiz Issue Type: Bug Components: product Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 14.12.01 Reporter: Forrest Rae Assignee: Jacques Le Roux Attachments: OFBIZ-6323.patch The LookUpProductPrice ajaxLookup leverages the same LookupDecorator screen that is used for more advanced product queries. The results of the request display all the different price types configured for a product This is confusing for the user when adding an item to a quote. The attached patch adds additional conditionalFields to the search criteria. I've searched the code base for areas where this change might adversely affect usability and didn't see any cases of that. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6327) Make layered-window available in forms
[ https://issues.apache.org/jira/browse/OFBIZ-6327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-6327: --- Summary: Make layered-window available in forms (was: Make it available in forms) Make layered-window available in forms -- Key: OFBIZ-6327 URL: https://issues.apache.org/jira/browse/OFBIZ-6327 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS Reporter: Jacques Le Roux Fix For: Trunk I don't see a need for menus, but could be. Relates also to OFBIZ-6034 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
Martin Becker created OFBIZ-6329: Summary: Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526790#comment-14526790 ] Adam Heath commented on OFBIZ-6271: --- What Jacques is asking about, are all the other non-build targets in the build.xml. Aka, load-demo, start, etc. I've been struggling(not with the implementation, but with the where) on how to deal with those targets in a maven world. Maven is a *build system*, while ant's build.xml is just a series of commands(targets) that have names and do something, and might also require other things to run first(depends). There really isn't a simple way to just add callable commands to maven's pom.xml structures. I've played with making each called target from ant by a non-default-activated profile. I then attempted to inline each target body using maven-antrun-plugin, but that was ugly. I then have switched to moving the special targets to a separate external build.xml snippet, which is then called by both ant and maven. This latter method actually seems like it would be generally useful, even without maven in use. Aka, the top-level build.xml, and all the internal component build.xml, should just be for building/deploying ofbiz. The extra cli targets at the top-level should be in a separate location(similar to how we have that top-level tools folder). For backwards compatibility, top-level would need to call the external targets for a time being. Does that make sense? build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Becker updated OFBIZ-6329: - Attachment: OFBIZ-6329_Non-Template-Caching.patch OFBIZ-6329_FTL-Caching.patch Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6085: Attachment: (was: OFBIZ-6085.patch) Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6085: Attachment: OFBIZ-6085.patch Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526847#comment-14526847 ] Adrian Crum commented on OFBIZ-6329: Thank you for working on this, but the patch file format is wrong. Please use a unified diff format. Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6085) Add support for production run inventory tracking
[ https://issues.apache.org/jira/browse/OFBIZ-6085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526888#comment-14526888 ] Christian Carlow commented on OFBIZ-6085: - I updated this patch again to handle the related OFBIZ-6328 which will also be separately patched without code related to this issue. Code related to OFBIZ-6266 and OFBIZ-6267 was removed and will be provided as a separate patch to that issue. The patch still includes changes to handle dependent OFBIZ-5532, OFBIZ-6255, OFBIZ-6264 and OFBIZ-6265. Part of OFBIZ-6042 is also handled and that code will be extracted and provided as a separate patch to that issue along with the remaining code missing from this patch. OFBIZ-5548 and OFBIZ-5569 are still contained in the patch because they are so closely related but may be extracted as a separate patches as well. The mechanism that controls the visibility of time entry functionality still hasn't been determined but should include logic to hide the declaration form worker field since it is never used without the patched code. Add support for production run inventory tracking - Key: OFBIZ-6085 URL: https://issues.apache.org/jira/browse/OFBIZ-6085 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Assignee: Pierre Smits Attachments: OFBIZ-6085.patch Production run inventory tracking seems worthy of support so that production managers can get an idea of the department work load. InventoryItemDetails should be created during production run declarations so that the material that was stocked out for the production run can be tracked while it is being manufacturing into the good. Essentially is would be like stock moves or inventory xfers occuring within the production runs for the task fixed asset facilities/locations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1677597 - in /ofbiz/trunk: .classpath LICENSE framework/base/lib/commons/commons-cli-1.2.jar macros.xml
On May 4, 2015, at 6:36 PM, Adam Heath doo...@brainfood.com wrote: Why are antlr and asm removed, but not mentioned in the log? Antlr and asm jars were not removed, just the classpath entries for the groovy.class.path path id: the classes are included in the groovy-all jar; one of the entries (commons-cli-1.0.jar) was old and was pointing to an invalid jar. Jacopo
[jira] [Updated] (OFBIZ-6328) createProductionRunsForOrder service doesn't handle cancelled production runs
[ https://issues.apache.org/jira/browse/OFBIZ-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6328: Attachment: OFBIZ-6328.patch createProductionRunsForOrder service doesn't handle cancelled production runs - Key: OFBIZ-6328 URL: https://issues.apache.org/jira/browse/OFBIZ-6328 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6328.patch createProductionRunsForOrder doesn't create production runs whenever a WorkOrderItemFulfillment record exists even if workEffort.currentStatusId == PRUN_CANCELLED. The service should be enhanced to recognized canceled production runs and create replacements when no active ones are found. Extra logic may need to be added later to handle changing production run statuses from canceled back to an active state when another active production run took its place but as of right now such a status change is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6328) createProductionRunsForOrder service doesn't handle cancelled production runs
[ https://issues.apache.org/jira/browse/OFBIZ-6328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526905#comment-14526905 ] Christian Carlow commented on OFBIZ-6328: - This patch was extracted from OFBIZ-6085 to handle this issue separately. createProductionRunsForOrder service doesn't handle cancelled production runs - Key: OFBIZ-6328 URL: https://issues.apache.org/jira/browse/OFBIZ-6328 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6328.patch createProductionRunsForOrder doesn't create production runs whenever a WorkOrderItemFulfillment record exists even if workEffort.currentStatusId == PRUN_CANCELLED. The service should be enhanced to recognized canceled production runs and create replacements when no active ones are found. Extra logic may need to be added later to handle changing production run statuses from canceled back to an active state when another active production run took its place but as of right now such a status change is not possible. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: svn commit: r1677597 - in /ofbiz/trunk: .classpath LICENSE framework/base/lib/commons/commons-cli-1.2.jar macros.xml
On 05/04/2015 12:29 PM, Jacopo Cappellato wrote: On May 4, 2015, at 6:36 PM, Adam Heath doo...@brainfood.com wrote: Why are antlr and asm removed, but not mentioned in the log? Antlr and asm jars were not removed, just the classpath entries for the groovy.class.path path id: the classes are included in the groovy-all jar; one of the entries (commons-cli-1.0.jar) was old and was pointing to an invalid jar. But the commit log didn't say that.
Re: svn commit: r1677597 - in /ofbiz/trunk: .classpath LICENSE framework/base/lib/commons/commons-cli-1.2.jar macros.xml
On May 4, 2015, at 7:59 PM, Adam Heath doo...@brainfood.com wrote: But the commit log didn't say that. I guess it is a way to say: Jacopo, could you please mention it in the commit log?. Sure, I have now expanded the commit logs :-) Jacopo
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527064#comment-14527064 ] Ron Wheeler commented on OFBIZ-6271: Maven profiles are inherently evil and draw otherwise good people over to the dark side. The https://maven.apache.org/plugins/maven-antrun-plugin/ can be used as Adam suggested but this requires the end user to build a maven project. I favour a proper installer that allows one to install or upgrade their installation in a simple way that is defined in configuration and code that can be tested rather than in documentation which gets out of date and depends on the user's interpretation of what is written and their abiilty to follow instructions and type things accurately. The installer can be built with Maven as a project. If someone want to buld a custom installer, they just change the dependencies in the installer POM to point to their custom jar files that will override the Maven Central official OFBiz jars. They can substitute splash pages, panel text, readme, licenses, seed data or whatever is required to distribute their custom OFBiz. THe complexity of seed data, demo data and test data can be hidden from the system administrator which could allow theOFBIZ dev team to rethink the data loading process witout worrying about complexity. The installer can offer a default install and offer the person doing the install the abililty to ignore components or install options. It can also do some sanity checks prior to installation. It can automatically detect the OS to do the right things - desktop shortcuts, Windows registry entries, add to start menu - to make the installation process easier. This makes support easier since the installations should become much more consistent. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527083#comment-14527083 ] Michael Brohl commented on OFBIZ-6329: -- The patch format is following the Apache proposed workflow for working with git repositories, see http://www.apache.org/dev/git.html. What's wrong with it? Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Vote: move to git.
+0 I like git and use it primarily but I'm not sure that adoption of git at the ASF has reached the point where I'm prepared to force it onto the unwilling. On 5 May 2015 15:01, Hans Bakker h.bak...@antwebsystems.com wrote: As the discussions seem to end, can i propose a vote? The question : should we convert the master SVN repository of Apache OFBIz to a GIT version? The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html * +1: 'Yes lets do it' * +0: 'I don't feel strongly about it, but I'm okay with this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's /do/ it!' * -0.9: 'I /really/ don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' * -1 'I do not want this.' Votes will be possible for one week from today. Regards, Hans On 20/04/15 11:38, Hans Bakker wrote: As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging. Regards, Hans
Vote: move to git.
As the discussions seem to end, can i propose a vote? The question : should we convert the master SVN repository of Apache OFBIz to a GIT version? The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html * +1: 'Yes lets do it' * +0: 'I don't feel strongly about it, but I'm okay with this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's /do/ it!' * -0.9: 'I /really/ don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' * -1 'I do not want this.' Votes will be possible for one week from today. Regards, Hans On 20/04/15 11:38, Hans Bakker wrote: As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging. Regards, Hans
Re: Vote: move to git.
This may be the nail in the coffin, at least for now, but +0, needs more discussion/planning. I've been using git-svn for longer than most with ofbiz, and would really love it if we were already using git, but it's just too soon. Just because git is decentralized, doesn't mean that there is no longer a center. *Someone* has to be pulling/merging all the branches, and who would step up to that plate? Who would want to take on the mantel? I don't think we as a community are ready to require that of someone. Of course, we need to start planning for this eventuality, imho, but we are still a long ways off. ps: I, and others, will continue to use git in our upstream svn interactions, as that seems to work well enough pps: as per Adrian's vote call, there is nothing actionable here. On 05/04/2015 10:01 PM, Hans Bakker wrote: As the discussions seem to end, can i propose a vote? The question : should we convert the master SVN repository of Apache OFBIz to a GIT version? The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html * +1: 'Yes lets do it' * +0: 'I don't feel strongly about it, but I'm okay with this.' * -0.5: 'I don't like this idea, but I can't find any rational justification for my feelings.' * ++1: 'Wow! I like this! Let's /do/ it!' * -0.9: 'I /really/ don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.' * +0.9: 'This is a cool idea and i like it, but I don't have time/the skills necessary to help out.' * -1 'I do not want this.' Votes will be possible for one week from today. Regards, Hans On 20/04/15 11:38, Hans Bakker wrote: As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging. Regards, Hans
[jira] [Commented] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527207#comment-14527207 ] Michael Brohl commented on OFBIZ-6329: -- Yes, I know. I thought that the patch formats are compatible. The git patch contains a unified diff format. Haven't tried it myself but since the german translations patch went through without problems, I thought it's ok. We will provide new patches then. Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527390#comment-14527390
]
Pierre Smits commented on OFBIZ-6271:
-
It seems you're looking for something like this:
{code:xml}
project name=MyProject basedir=. default=main
xmlns:artifact=antlibrg.apache.maven.artifact.ant
target name=installAll
artifact:mvn
arg value=install/
/artifact:mvn
/target
{code}
build management with maven
---
Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log
This is a new build system; the primary goal will be to not require any
changes to existing ofbiz layouts(for backwards compatibility, at least
initially).
These pom.xml files are completely new; the existing build.xml infrastructure
will continue to exist. The existing build.xml will never call into
maven(which is what processes the pom.xml), and maven will never call into
build.xml either.
I have already committed a working pom.xml for the top level, and
framework/start. Shortly, I will be adding framework/base and
framework/entity, but into this branch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527418#comment-14527418 ] Adam Heath commented on OFBIZ-6271: --- Yes, no, both. I want maven to be have the ability to call load-demo, create-tenant, etc. I want ant to be able to call into maven, for the actual build. So, as a plan, the special non-build targets in the top-level build.xml get extracted out, to be placed into a single file, shared by both build systems. Then, both systems can call into this shared file. For a time, both build systems are maintained in parallel, with mostly identical features. This to give developers a time to acclimate. After a time, switch ant to call into maven for the build targets, but still leave the targets in build.xml. Add a deprecation message. Even more time, remove the build.xml from all of ofbiz. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6271) build management with maven
[ https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527421#comment-14527421 ] Adam Heath commented on OFBIZ-6271: --- I also struggled with moving the list of tasks from top-level build.xml into some piece of compiled code. However, those top-level tasks are really short scriptlets, batch files, shell scripts, whatever. So, making full-on java code doesn't really work either, and would be harder to maintain(in theory). This is still a bit of an open-ended issue. And, honestly, now that I am here, I'm actually kind of curious about that other elephant, aka, gradle. build management with maven --- Key: OFBIZ-6271 URL: https://issues.apache.org/jira/browse/OFBIZ-6271 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Reporter: Adam Heath Priority: Minor Attachments: console.log This is a new build system; the primary goal will be to not require any changes to existing ofbiz layouts(for backwards compatibility, at least initially). These pom.xml files are completely new; the existing build.xml infrastructure will continue to exist. The existing build.xml will never call into maven(which is what processes the pom.xml), and maven will never call into build.xml either. I have already committed a working pom.xml for the top level, and framework/start. Shortly, I will be adding framework/base and framework/entity, but into this branch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6271) build management with maven
[
https://issues.apache.org/jira/browse/OFBIZ-6271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527390#comment-14527390
]
Pierre Smits edited comment on OFBIZ-6271 at 5/4/15 9:54 PM:
-
It seems you're looking for something like this:
{code:xml}
project name=MyProject basedir=. default=main
xmlns:artifact=antlibrg.apache.maven.artifact.ant
target name=installAll
artifact:mvn
arg value=install/
/artifact:mvn
/target
{code}
Or am I mistaken?
was (Author: pfm.smits):
It seems you're looking for something like this:
{code:xml}
project name=MyProject basedir=. default=main
xmlns:artifact=antlibrg.apache.maven.artifact.ant
target name=installAll
artifact:mvn
arg value=install/
/artifact:mvn
/target
{code}
build management with maven
---
Key: OFBIZ-6271
URL: https://issues.apache.org/jira/browse/OFBIZ-6271
Project: OFBiz
Issue Type: Improvement
Components: ALL COMPONENTS
Reporter: Adam Heath
Priority: Minor
Attachments: console.log
This is a new build system; the primary goal will be to not require any
changes to existing ofbiz layouts(for backwards compatibility, at least
initially).
These pom.xml files are completely new; the existing build.xml infrastructure
will continue to exist. The existing build.xml will never call into
maven(which is what processes the pom.xml), and maven will never call into
build.xml either.
I have already committed a working pom.xml for the top level, and
framework/start. Shortly, I will be adding framework/base and
framework/entity, but into this branch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText
[ https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14527172#comment-14527172 ] Adrian Crum commented on OFBIZ-6329: OFBiz uses Subversion, not Git. Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText --- Key: OFBIZ-6329 URL: https://issues.apache.org/jira/browse/OFBIZ-6329 Project: OFBiz Issue Type: Bug Components: content Affects Versions: Trunk Reporter: Martin Becker Attachments: OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching.patch There are several problems with the current caching logic in DataResourceWorker.renderDataResourceAsText(...). Enabling the caching of rendered FTL-Templates from DataResources with the property disable.ftl.template.cache in content.properties enables a non-functioning block of code that handles the rendering of the cached template. And if it is deactivated (default), the FTL-Templates are still cached by the FreeMarkerWorker. However the correct logic for caching and using the rendered FTL-Template is already implemented in the FreeMarkerWorker and controlled by an optional useCache parameter. In addition there is an API call to DataResourceWorker.writeDataResourceText for non template content with a static true for useCache instead of using the given cache parameter value of the renderDataResourceAsText method itself, so even if the caller do not want to use caching at all, the non template text data is cached an FTL-Templates are cached also. I will provide a patch for those two issues in the mentioned method. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
