[jira] [Commented] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507350#comment-14507350 ] Adam Heath commented on OFBIZ-6290: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/pos/src/org/ofbiz/pos/config/ButtonEventConfig.java:55: warning: [deprecation] getXmlRootElement(String) in ResourceLoader has been deprecated [javac17] Element root = ResourceLoader.getXmlRootElement(ButtonEventConfig.BUTTON_EVENT_CONFIG); [javac17] ^ ButtonEventConfig uses getXmlRootElement which has been deprecated -- Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system
Adam Heath created OFBIZ-6289: - Summary: Oagis classes are making use of the deprecated html rendering system Key: OFBIZ-6289 URL: https://issues.apache.org/jira/browse/OFBIZ-6289 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/oagis Reporter: Adam Heath Priority: Minor More of the same; oagis classes are using the deprecated html rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507321#comment-14507321 ] Adam Heath commented on OFBIZ-6289: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:67: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:76: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:76: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisServices.java:193: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] ScreenRenderer screens = new ScreenRenderer(writer, bodyParameters, new HtmlScreenRenderer()); [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:74: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/oagis/src/org/ofbiz/oagis/OagisShipmentServices.java:74: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17] ^ Oagis classes are making use of the deprecated html rendering system Key: OFBIZ-6289 URL: https://issues.apache.org/jira/browse/OFBIZ-6289 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/oagis Reporter: Adam Heath Priority: Minor More of the same; oagis classes are using the deprecated html rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
Adam Heath created OFBIZ-6290: - Summary: ButtonEventConfig uses getXmlRootElement which has been deprecated Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Created] (OFBIZ-6275) OFBiz code seems make use of other deprecated OFBiz features
Ok, all issues created. Hang back a bit before anyone starts taking ownership of stuff, I've need to make time to commit the ones I've already got fixed. On 04/22/2015 10:11 AM, Adam Heath wrote: I've got some changes already for the sub-tasks I will be filing shortly; as before, a separate branch will be made. On 04/22/2015 10:08 AM, Adam Heath (JIRA) wrote: Adam Heath created OFBIZ-6275: - Summary: OFBiz code seems make use of other deprecated OFBiz features Key: OFBIZ-6275 URL: https://issues.apache.org/jira/browse/OFBIZ-6275 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Adam Heath Priority: Minor Add compilerarg value=-Xlint:deprecation/ to macros.xml. Do a clean, then a build. See the warnings. This task should be an umbrella over any possible sub-tasks, as people find and discover these issues, and come up with fixes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507330#comment-14507330 ] Adam Heath commented on OFBIZ-6270: --- Because I plan on also adding test cases(which were also removed); they will probably even be based on the removed test case classes. And, since I haven't yet done the work, and I am following the release-first/release-often workflow, I created a branch early, and committed code early, in case anyone else wants to work with me. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6289) Oagis classes are making use of the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507342#comment-14507342 ] Adam Heath commented on OFBIZ-6289: --- These need to be switched to a macro system. Oagis classes are making use of the deprecated html rendering system Key: OFBIZ-6289 URL: https://issues.apache.org/jira/browse/OFBIZ-6289 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/oagis Reporter: Adam Heath Priority: Minor More of the same; oagis classes are using the deprecated html rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507352#comment-14507352 ] Adam Heath commented on OFBIZ-6290: --- Same problem, don't use a cached version of this method. ButtonEventConfig uses getXmlRootElement which has been deprecated -- Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Maven is only one of the alternatives that could be investigated. It would be nice if the people who build OFBiz every day tried to use Adam's solution before it is removed. Is it as easy to test Ant+Ivy. Ron On 22/04/2015 5:13 AM, Pierre Smits wrote: I already establised a working solution for better dependency management based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the checkout at that time (35 MBs). And it seems with less effort/less complexity than is now is being shown in the OFBIZ-6172 branch... I suggested a dev branch back then ( https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could evaluate. Unfortunately it didn't gather momentum at the time. Does that mean that it is a worse fit? I dare say: not! Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Perhaps it would be a good idea for some of the key people to take a close look at what has been done. This is potentially a big step forward in modernizing the product. Having a working solution takes a lot of the FUD out of the discussion and allows the approach to be tested by the people who are building OFBiz every day. Even if it actually does everything that Adam claims and the consensus of the committers is to move to Maven, it will still be a good idea to support the 2 build methods until everyone important is ready to commit to Maven. It may take a while to get the Maven approach sold to everyone even if they know that at some point they will be forced to move. Some will be early adopters and some will be late but if you don't have to force everyone to move at once, it does make the transition easier. If it is the consensus that the Ant build is still better, the Maven stuff is easy to remove without damaging the Ant build. I suggest leaving it in until everyone who needs to test it before the decision is made, has a chance to test it. It is unreasonable to expect each of the committers to make their own Maven build to test the idea. Adam has saved us a lot of speculation about what it means to move to Maven. Give the supporters and skeptics some time to test before removing it. Ron On 22/04/2015 2:52 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote: My commit is not breaking anything. Why remove something that is harmless? Hi Adam, The fact that a commit is harmless is not enough for its approval. I know that your commit doesn't cause any side effects and I appreciate that you are now doing your work in a feature branch. I am asking you to revert that commit to trunk not because its quality is bad or I see potential issues but only because the decision about the official build tool for the project must be taken by the community and we are not planning to maintain more than one alternative options in the official repository. Just to make it super clear, I restate my request: please revert 1674216 (it is the only commit to trunk) then let's continue the work about Maven in the release branch you have created. In the meantime the discussion about ant vs ant+ivy vs maven vs gradle vs ... will go on and its outcome will determine the final decision; since there are clearly different points of view for the different tools we all have to be open to consider other's opinions: crystallized positions will not help much in this context. The branch you have created is valuable because it provides a reference implementation for the discussion, but it is important that you appreciate that it may not be merged into the project (based on the outcome of the ongoing discussion). Regards, Jacopo -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
+1 Ron On 22/04/2015 5:25 AM, Pierre Smits wrote: The Groovy/Gradle approach enables this project to bring build/dependency management regarding base applications and optionals (special purpose/outside ASF solutions) from the CLI to an application. Increasing the user experience of those who manage the implementation for their users. Leading to potentially more adopters. I don't care particularly for the argument of the trend projection (Maven vs Gradle vs ANT+IVY). That is based on an algorithm that pulls in all kinds of stuff. And whether that stuff is applicable to the needs of this project can't be determined. What I see happening in this thread (and others similarly related to the subject) is projection of favouritism (Apple vs Microsoft, BMW vs Mercedes, et all). We should first focus on the need of the project, build consensus before moving on. Having a dev branch filled with something to evaluate comes second. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com wrote: I already establised a working solution for better dependency management based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the checkout at that time (35 MBs). And it seems with less effort/less complexity than is now is being shown in the OFBIZ-6172 branch... I suggested a dev branch back then ( https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could evaluate. Unfortunately it didn't gather momentum at the time. Does that mean that it is a worse fit? I dare say: not! Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Perhaps it would be a good idea for some of the key people to take a close look at what has been done. This is potentially a big step forward in modernizing the product. Having a working solution takes a lot of the FUD out of the discussion and allows the approach to be tested by the people who are building OFBiz every day. Even if it actually does everything that Adam claims and the consensus of the committers is to move to Maven, it will still be a good idea to support the 2 build methods until everyone important is ready to commit to Maven. It may take a while to get the Maven approach sold to everyone even if they know that at some point they will be forced to move. Some will be early adopters and some will be late but if you don't have to force everyone to move at once, it does make the transition easier. If it is the consensus that the Ant build is still better, the Maven stuff is easy to remove without damaging the Ant build. I suggest leaving it in until everyone who needs to test it before the decision is made, has a chance to test it. It is unreasonable to expect each of the committers to make their own Maven build to test the idea. Adam has saved us a lot of speculation about what it means to move to Maven. Give the supporters and skeptics some time to test before removing it. Ron On 22/04/2015 2:52 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote: My commit is not breaking anything. Why remove something that is harmless? Hi Adam, The fact that a commit is harmless is not enough for its approval. I know that your commit doesn't cause any side effects and I appreciate that you are now doing your work in a feature branch. I am asking you to revert that commit to trunk not because its quality is bad or I see potential issues but only because the decision about the official build tool for the project must be taken by the community and we are not planning to maintain more than one alternative options in the official repository. Just to make it super clear, I restate my request: please revert 1674216 (it is the only commit to trunk) then let's continue the work about Maven in the release branch you have created. In the meantime the discussion about ant vs ant+ivy vs maven vs gradle vs ... will go on and its outcome will determine the final decision; since there are clearly different points of view for the different tools we all have to be open to consider other's opinions: crystallized positions will not help much in this context. The branch you have created is valuable because it provides a reference implementation for the discussion, but it is important that you appreciate that it may not be merged into the project (based on the outcome of the ongoing discussion). Regards, Jacopo -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com
[jira] [Created] (OFBIZ-6276) Fix deprecation issues in framework/entity
Adam Heath created OFBIZ-6276: - Summary: Fix deprecation issues in framework/entity Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6278: - Assignee: Adam Heath JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
Adam Heath created OFBIZ-6278: - Summary: JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6281) Many classes in framework/widget are still using html-based renderers, instead of macro-based
[ https://issues.apache.org/jira/browse/OFBIZ-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507256#comment-14507256 ] Adam Heath commented on OFBIZ-6281: --- [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:46: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/macro/MacroScreenRenderer.java:65: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer.ScreenletMenuRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:82: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] writer.append(FoScreenRenderer.getFoStyle(widgetStyle)); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:208: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] writer.append(FoScreenRenderer.getFoStyle(areaStyle)); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/FoFormRenderer.java:290: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] writer.append(FoScreenRenderer.getFoStyle(areaStyle)); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/fo/ScreenFopViewHandler.java:132: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] ScreenRenderer screens = new ScreenRenderer(writer, null, new HtmlScreenRenderer()); [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/widget/src/org/ofbiz/widget/renderer/html/HtmlTreeRenderer.java:337: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated
[jira] [Updated] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6278: -- Priority: Minor (was: Major) JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6279: -- Component/s: framework UtilDateTime has an ImmutableDate inner class that has deprecation warnings --- Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Components: ALL COMPONENTS, framework Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6280: -- Priority: Minor (was: Major) SecurityFactory implements methods that have been deprecated Key: OFBIZ-6280 URL: https://issues.apache.org/jira/browse/OFBIZ-6280 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor This class implements Security, which has methods that have been deprecated. As such, it gets deprecation warnings when implementing those methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath updated OFBIZ-6279: -- Component/s: (was: ALL COMPONENTS) UtilDateTime has an ImmutableDate inner class that has deprecation warnings --- Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507279#comment-14507279 ] Adam Heath commented on OFBIZ-6285: --- Same type of problems. OutputServices uses the deprecated fo widget rendering system - Key: OFBIZ-6285 URL: https://issues.apache.org/jira/browse/OFBIZ-6285 Project: OFBiz Issue Type: Sub-task Components: content Reporter: Adam Heath Priority: Minor Yet again, another instance of hard-coded rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
[ https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507126#comment-14507126 ] Pierre Smits commented on OFBIZ-6238: - In a multi-organisation setup, (multiple internal organisations registering orders) this would be limiting also. A better convention would be: FpartyId-TpartyId-orderId.pfd with: * F = from notation * T = to notation * partyId = the partyId of the involved party, with 'FpartyId' designating the internal party and 'TpartyId' designating the external party * orderId = the orderId of the order. Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacopo Cappellato Priority: Trivial Attachments: OrderServices.patch According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
[ https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507126#comment-14507126 ] Pierre Smits edited comment on OFBIZ-6238 at 4/22/15 2:14 PM: -- In a multi-organisation setup, (multiple internal organisations registering orders) this patch would be limiting also. A better convention would be: FpartyId-TpartyId-orderId.pfd with: * F = from notation * T = to notation * partyId = the partyId of the involved party, with 'FpartyId' designating the internal party and 'TpartyId' designating the external party * orderId = the orderId of the order. was (Author: pfm.smits): In a multi-organisation setup, (multiple internal organisations registering orders) this would be limiting also. A better convention would be: FpartyId-TpartyId-orderId.pfd with: * F = from notation * T = to notation * partyId = the partyId of the involved party, with 'FpartyId' designating the internal party and 'TpartyId' designating the external party * orderId = the orderId of the order. Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacopo Cappellato Priority: Trivial Attachments: OrderServices.patch According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- 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=14507135#comment-14507135
]
Pierre Smits commented on OFBIZ-6085:
-
{quote}
I'll also work on default options that prevent time entries by default but
having the feature available OOTB would be convenient
{quote}
Meaning you're going to do a Manufacturing configuration extension? Or...?
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: Renaming OFBiz artefacts
-1, but not permanently. If we start renaming things, then it'll become hard to port changes back and forth between release branches and trunk. We need to reduce the number of outstanding branches first, before this can even be started. On 04/22/2015 10:09 AM, Ron Wheeler wrote: I was thinking of something like an 8 hour sprint where several people divide up the task and do it and test it quickly. divide up by application, code/XML, seed data, documentation, testing and what ever makes sense to get the change done in a few hours. Ron On 22/04/2015 5:01 AM, Pierre Smits wrote: Ron, Notwithstanding the appropriateness of the elements in your response, everything done in the OFBiz project IS a community project (endeavour for a better word). Thank you for reiterating the invite for more collaboration. I wholeheartedly agree and support. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Definitely a good idea. Should it be done as a community project over a short period of time? It would seem to be easier to do as a sort of global search and replace followed by testing rather than modifying a piece and looking for all of the references to that code and changing them and testing and then picking the next piece. Adding a JIRA sounds like the best start. Ron On 22/04/2015 4:36 AM, Pierre Smits wrote: Hi all, In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian proposed to rename our OFBiz artefacts from org.ofbiz to org.apache.ofbiz to bring it more inline to conventions used by other Apache projects/products. Does this proposal need any further discussion? Or can we move forward by creating a JIRA and work from there? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Commented] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[
https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507250#comment-14507250
]
Adam Heath commented on OFBIZ-6279:
---
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1197:
warning: [deprecation] setYear(int) in Date has been deprecated
[javac17] public void setYear(int year) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1202:
warning: [deprecation] setMonth(int) in Date has been deprecated
[javac17] public void setMonth(int month) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1207:
warning: [deprecation] setDate(int) in Date has been deprecated
[javac17] public void setDate(int date) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1212:
warning: [deprecation] setHours(int) in Date has been deprecated
[javac17] public void setHours(int hours) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1217:
warning: [deprecation] setMinutes(int) in Date has been deprecated
[javac17] public void setMinutes(int minutes) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/util/UtilDateTime.java:1222:
warning: [deprecation] setSeconds(int) in Date has been deprecated
[javac17] public void setSeconds(int seconds) {
[javac17] ^
UtilDateTime has an ImmutableDate inner class that has deprecation warnings
---
Key: OFBIZ-6279
URL: https://issues.apache.org/jira/browse/OFBIZ-6279
Project: OFBiz
Issue Type: Sub-task
Components: ALL COMPONENTS
Reporter: Adam Heath
Assignee: Adam Heath
When extending/implementing a class/interface, where methods in the parent
have been marked deprecated, sub-instances also get deprecation warnings.
The fix here is to also mark the sub-instances deprecated(with @Deprecated or
/** @deprecated */
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
Adam Heath created OFBIZ-6280: - Summary: SecurityFactory implements methods that have been deprecated Key: OFBIZ-6280 URL: https://issues.apache.org/jira/browse/OFBIZ-6280 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath This class implements Security, which has methods that have been deprecated. As such, it gets deprecation warnings when implementing those methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
[
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507268#comment-14507268
]
Adam Heath commented on OFBIZ-6284:
---
[javac17]
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/artifactinfo/ServiceArtifactInfo.java:96:
warning: [deprecation] getAllEntityNamesUsed() in SimpleMethod has been
deprecated
[javac17] SetString allEntityNameSet =
simpleMethodToCall.getAllEntityNamesUsed();
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/artifactinfo/ServiceArtifactInfo.java:156:
warning: [deprecation] getAllServiceNamesCalled() in SimpleMethod has been
deprecated
[javac17] SetString allServiceNameSet =
simpleMethodToCall.getAllServiceNamesCalled();
[javac17] ^
ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
-
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507284#comment-14507284 ] Adam Heath commented on OFBIZ-6287: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:54: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:61: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/birt/src/org/ofbiz/birt/email/BirtEmailServices.java:61: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] protected static final HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17] ^ BirtEmailServices uses the deprecated html rendering system --- Key: OFBIZ-6287 URL: https://issues.apache.org/jira/browse/OFBIZ-6287 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/birt Reporter: Adam Heath Priority: Minor Yet another instance of html rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system
Adam Heath created OFBIZ-6287: - Summary: BirtEmailServices uses the deprecated html rendering system Key: OFBIZ-6287 URL: https://issues.apache.org/jira/browse/OFBIZ-6287 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/birt Reporter: Adam Heath Priority: Minor Yet another instance of html rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507231#comment-14507231
]
Adam Heath commented on OFBIZ-6276:
---
[javac17]
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/GenericDelegator.java:1415:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] public int storeAll(ListGenericValue values, boolean
doCacheClear, boolean createDummyFks) throws GenericEntityException {
[javac17]^
[javac17]
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:329:
warning: [deprecation] storeAll(ListGenericValue,boolean,boolean) in
Delegator has been deprecated
[javac17] delegator.storeAll(valuesToWrite, doCacheClear,
createDummyFks);
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:498:
warning: [deprecation] removeAll(List? extends GenericEntity,boolean) in
Delegator has been deprecated
[javac17]
delegator.removeAll(valuesToDelete, doCacheClear);
[javac17] ^
Fix deprecation issues in framework/entity
--
Key: OFBIZ-6276
URL: https://issues.apache.org/jira/browse/OFBIZ-6276
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
It appears that the storeAll() variants are being refactor; basically, the
useCache parameter is being removed. However, this has caused the
entity engine to have deprecation with itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507248#comment-14507248 ] Adam Heath commented on OFBIZ-6278: --- [javac17] /srv/ofbiz/apache-git/framework/base/src/org/ofbiz/base/config/JNDIConfigUtil.java:39: warning: [deprecation] getXmlRootElement(String) in ResourceLoader has been deprecated [javac17] return ResourceLoader.getXmlRootElement(JNDIConfigUtil.JNDI_CONFIG_XML_FILENAME); [javac17] ^ JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6281) Many classes in framework/widget are still using html-based renderers, instead of macro-based
Adam Heath created OFBIZ-6281: - Summary: Many classes in framework/widget are still using html-based renderers, instead of macro-based Key: OFBIZ-6281 URL: https://issues.apache.org/jira/browse/OFBIZ-6281 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html renderers had hard-coded output. A new system had been developed, which uses macros; this allowed for swapping the output with something more or less advanced, without having to change the code. However, many classes are still using the old rendering system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system
Adam Heath created OFBIZ-6283: - Summary: A few classes in webtools make use of the html widget rendering system Key: OFBIZ-6283 URL: https://issues.apache.org/jira/browse/OFBIZ-6283 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system is deprecated in favor of a macro-based approach. These classes should be updated to use the new system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6286) SagePay classes make use of deprecated httpclient features
Adam Heath created OFBIZ-6286: - Summary: SagePay classes make use of deprecated httpclient features Key: OFBIZ-6286 URL: https://issues.apache.org/jira/browse/OFBIZ-6286 Project: OFBiz Issue Type: Sub-task Components: accounting Reporter: Adam Heath Priority: Minor I have not checked httpclient upstream to see what should be used in place of the deprecated classes/methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6286) SagePay classes make use of deprecated httpclient features
[ https://issues.apache.org/jira/browse/OFBIZ-6286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507282#comment-14507282 ] Adam Heath commented on OFBIZ-6286: --- [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41: warning: [deprecation] DefaultHtt pClient in org.apache.http.impl.client has been deprecated [javac17] import org.apache.http.impl.client.DefaultHttpClient; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43: warning: [deprecation] BasicHttpP arams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.BasicHttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.HttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41: warning: [deprecation] DefaultHttpClient in org.apache.http.impl.client has been deprecated [javac17] import org.apache.http.impl.client.DefaultHttpClient; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43: warning: [deprecation] BasicHttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.BasicHttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.HttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:41: warning: [deprecation] DefaultHttpClient in org.apache.http.impl.client has been deprecated [javac17] import org.apache.http.impl.client.DefaultHttpClient; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:43: warning: [deprecation] BasicHttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.BasicHttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:44: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] import org.apache.http.params.HttpParams; [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:282: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:378: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:472: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:564: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayServices.java:675: warning: [deprecation] getConnectionManager() in HttpClient has been deprecated [javac17] httpClient.getConnectionManager().shutdown(); [javac17] ^ [javac17] /srv/ofbiz/apache-git/applications/accounting/src/org/ofbiz/accounting/thirdparty/sagepay/SagePayUtil.java:164: warning: [deprecation] HttpParams in org.apache.http.params has been deprecated [javac17] HttpParams params = new BasicHttpParams(); [javac17] ^ [javac17]
Re: Renaming OFBiz artefacts
I was thinking of something like an 8 hour sprint where several people divide up the task and do it and test it quickly. divide up by application, code/XML, seed data, documentation, testing and what ever makes sense to get the change done in a few hours. Ron On 22/04/2015 5:01 AM, Pierre Smits wrote: Ron, Notwithstanding the appropriateness of the elements in your response, everything done in the OFBiz project IS a community project (endeavour for a better word). Thank you for reiterating the invite for more collaboration. I wholeheartedly agree and support. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Definitely a good idea. Should it be done as a community project over a short period of time? It would seem to be easier to do as a sort of global search and replace followed by testing rather than modifying a piece and looking for all of the references to that code and changing them and testing and then picking the next piece. Adding a JIRA sounds like the best start. Ron On 22/04/2015 4:36 AM, Pierre Smits wrote: Hi all, In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian proposed to rename our OFBiz artefacts from org.ofbiz to org.apache.ofbiz to bring it more inline to conventions used by other Apache projects/products. Does this proposal need any further discussion? Or can we move forward by creating a JIRA and work from there? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Commented] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
[ https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507239#comment-14507239 ] Adam Heath commented on OFBIZ-6277: --- [javac17] /srv/ofbiz/apache-git/framework/entity/src/org/ofbiz/entity/util/EntitySaxReader.java:379: warning: [deprecation] Configuration() in Configuration has been deprecated [javac17] Configuration config = new Configuration(); [javac17]^ framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
Adam Heath created OFBIZ-6277: - Summary: framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6282) EmailServices is making use the html widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507260#comment-14507260 ] Adam Heath commented on OFBIZ-6282: --- These 2 issues have similar problems. EmailServices is making use the html widget rendering system Key: OFBIZ-6282 URL: https://issues.apache.org/jira/browse/OFBIZ-6282 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system has been replaced by a macro version; EmailServices still uses the old form. This should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6282) EmailServices is making use the html widget rendering system
Adam Heath created OFBIZ-6282: - Summary: EmailServices is making use the html widget rendering system Key: OFBIZ-6282 URL: https://issues.apache.org/jira/browse/OFBIZ-6282 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system has been replaced by a macro version; EmailServices still uses the old form. This should be fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507264#comment-14507264 ] Adam Heath commented on OFBIZ-6283: --- [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:40: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:49: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/framework/webtools/src/org/ofbiz/webtools/print/FoPrintServerEvents.java:49: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ A few classes in webtools make use of the html widget rendering system -- Key: OFBIZ-6283 URL: https://issues.apache.org/jira/browse/OFBIZ-6283 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system is deprecated in favor of a macro-based approach. These classes should be updated to use the new system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507277#comment-14507277 ] Adam Heath commented on OFBIZ-6285: --- [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer; [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer; [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:66: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] import org.ofbiz.widget.renderer.fo.FoScreenRenderer; [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:77: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] protected static final FoScreenRenderer foScreenRenderer = new FoScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/applications/content/src/org/ofbiz/content/output/OutputServices.java:77: warning: [deprecation] FoScreenRenderer in org.ofbiz.widget.renderer.fo has been deprecated [javac17] protected static final FoScreenRenderer foScreenRenderer = new FoScreenRenderer(); [javac17]^ OutputServices uses the deprecated fo widget rendering system - Key: OFBIZ-6285 URL: https://issues.apache.org/jira/browse/OFBIZ-6285 Project: OFBiz Issue Type: Sub-task Components: content Reporter: Adam Heath Priority: Minor Yet again, another instance of hard-coded rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
[ https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507275#comment-14507275 ] Martin Becker commented on OFBIZ-6238: -- What (F)partyId do you mean for your setting, from the order point of view, respectively which orderRole to get a party from the current oder? As there a different roles for sales and purchase orders, this has to be differentiated at least. My thought was a simple and robust way to give the attachment a unique name, which the orderId itself does, or isn't it? Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacopo Cappellato Priority: Trivial Attachments: OrderServices.patch According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6287) BirtEmailServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507285#comment-14507285 ] Adam Heath commented on OFBIZ-6287: --- More instances BirtEmailServices uses the deprecated html rendering system --- Key: OFBIZ-6287 URL: https://issues.apache.org/jira/browse/OFBIZ-6287 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/birt Reporter: Adam Heath Priority: Minor Yet another instance of html rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6238) Give the order notification email attachment the orderId as filename
[ https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507288#comment-14507288 ] Pierre Smits commented on OFBIZ-6238: - The Order in its pdf form represents a potential legal document between 2 main parties, the supplier and the customer (of the goods, service et all). If it is as such, the simple from and to inclusion in the name of the pdf file will represent that. Any other party involved are representatives related to the internal processes of the internal (from) organisation. They play a minimal role in the legal aspect. But yes, only the orderId is uniqueness enough. Give the order notification email attachment the orderId as filename Key: OFBIZ-6238 URL: https://issues.apache.org/jira/browse/OFBIZ-6238 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk Reporter: Martin Becker Assignee: Jacopo Cappellato Priority: Trivial Attachments: OrderServices.patch According to customer needs I've made a change to OrderServices.sendOrderNotificationScreen to fill the attachmentName parameter of the sendMailFromScreen context with the orderId to override the default in sendMailFromScreen, so that the PDF attachments in standard order notifications have a name like WS10001.pdf instead of Details.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system
Adam Heath created OFBIZ-6288: - Summary: ExamplePrintServices uses the deprecated html rendering system Key: OFBIZ-6288 URL: https://issues.apache.org/jira/browse/OFBIZ-6288 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/example Reporter: Adam Heath Priority: Minor Another case of html rendering in use instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Created] (OFBIZ-6275) OFBiz code seems make use of other deprecated OFBiz features
I've got some changes already for the sub-tasks I will be filing shortly; as before, a separate branch will be made. On 04/22/2015 10:08 AM, Adam Heath (JIRA) wrote: Adam Heath created OFBIZ-6275: - Summary: OFBiz code seems make use of other deprecated OFBiz features Key: OFBIZ-6275 URL: https://issues.apache.org/jira/browse/OFBIZ-6275 Project: OFBiz Issue Type: Bug Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Adam Heath Priority: Minor Add compilerarg value=-Xlint:deprecation/ to macros.xml. Do a clean, then a build. See the warnings. This task should be an umbrella over any possible sub-tasks, as people find and discover these issues, and come up with fixes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
Adam Heath created OFBIZ-6279: - Summary: UtilDateTime has an ImmutableDate inner class that has deprecation warnings Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Renaming OFBiz artefacts
That’s a good point! (especially for a bunch of build tool alternative branches ;-)) Martin Becker ecomify GmbH Am 22.04.2015 um 17:13 schrieb Adam Heath doo...@brainfood.com: -1, but not permanently. If we start renaming things, then it'll become hard to port changes back and forth between release branches and trunk. We need to reduce the number of outstanding branches first, before this can even be started. On 04/22/2015 10:09 AM, Ron Wheeler wrote: I was thinking of something like an 8 hour sprint where several people divide up the task and do it and test it quickly. divide up by application, code/XML, seed data, documentation, testing and what ever makes sense to get the change done in a few hours. Ron On 22/04/2015 5:01 AM, Pierre Smits wrote: Ron, Notwithstanding the appropriateness of the elements in your response, everything done in the OFBiz project IS a community project (endeavour for a better word). Thank you for reiterating the invite for more collaboration. I wholeheartedly agree and support. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Definitely a good idea. Should it be done as a community project over a short period of time? It would seem to be easier to do as a sort of global search and replace followed by testing rather than modifying a piece and looking for all of the references to that code and changing them and testing and then picking the next piece. Adding a JIRA sounds like the best start. Ron On 22/04/2015 4:36 AM, Pierre Smits wrote: Hi all, In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian proposed to rename our OFBiz artefacts from org.ofbiz to org.apache.ofbiz to bring it more inline to conventions used by other Apache projects/products. Does this proposal need any further discussion? Or can we move forward by creating a JIRA and work from there? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Commented] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
[
https://issues.apache.org/jira/browse/OFBIZ-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507252#comment-14507252
]
Adam Heath commented on OFBIZ-6280:
---
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:264:
warning: [deprecation] securityGroupPermissionExists(String,String) in
Security has been deprecated
[javac17] public boolean securityGroupPermissionExists(String
groupId, String permission) {
[javac17]^
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:105:
warning: [deprecation] findUserLoginSecurityGroupByUserLoginId(String) in
Security has been deprecated
[javac17] public IteratorGenericValue
findUserLoginSecurityGroupByUserLoginId(String userLoginId) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:274:
warning: [deprecation] setDelegator(Delegator) in Security has been deprecated
[javac17] public void setDelegator(Delegator delegator) {
[javac17] ^
[javac17]
/srv/ofbiz/apache-git/framework/security/src/org/ofbiz/security/SecurityFactory.java:116:
warning: [deprecation] getDelegator() in Security has been deprecated
[javac17] public Delegator getDelegator() {
[javac17] ^
SecurityFactory implements methods that have been deprecated
Key: OFBIZ-6280
URL: https://issues.apache.org/jira/browse/OFBIZ-6280
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
This class implements Security, which has methods that have been deprecated.
As such, it gets deprecation warnings when implementing those methods.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6283) A few classes in webtools make use of the html widget rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507265#comment-14507265 ] Adam Heath commented on OFBIZ-6283: --- Again, similar problems. A few classes in webtools make use of the html widget rendering system -- Key: OFBIZ-6283 URL: https://issues.apache.org/jira/browse/OFBIZ-6283 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor The html rendering system is deprecated in favor of a macro-based approach. These classes should be updated to use the new system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
Adam Heath created OFBIZ-6284:
-
Summary: ServiceArtifactInfo uses deprecated
getAll{Object}Names{Verb}
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OFBIZ-6285) OutputServices uses the deprecated fo widget rendering system
Adam Heath created OFBIZ-6285: - Summary: OutputServices uses the deprecated fo widget rendering system Key: OFBIZ-6285 URL: https://issues.apache.org/jira/browse/OFBIZ-6285 Project: OFBiz Issue Type: Sub-task Components: content Reporter: Adam Heath Priority: Minor Yet again, another instance of hard-coded rendering being used instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507293#comment-14507293 ] Adam Heath commented on OFBIZ-6288: --- [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:52: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:52: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:52: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] import org.ofbiz.widget.renderer.html.HtmlScreenRenderer; [javac17] ^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:58: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ [javac17] /srv/ofbiz/apache-git/specialpurpose/example/src/org/ofbiz/example/ExamplePrintServices.java:58: warning: [deprecation] HtmlScreenRenderer in org.ofbiz.widget.renderer.html has been deprecated [javac17] private static HtmlScreenRenderer htmlScreenRenderer = new HtmlScreenRenderer(); [javac17]^ ExamplePrintServices uses the deprecated html rendering system -- Key: OFBIZ-6288 URL: https://issues.apache.org/jira/browse/OFBIZ-6288 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/example Reporter: Adam Heath Priority: Minor Another case of html rendering in use instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6288) ExamplePrintServices uses the deprecated html rendering system
[ https://issues.apache.org/jira/browse/OFBIZ-6288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507313#comment-14507313 ] Adam Heath commented on OFBIZ-6288: --- Old(html) rendering system instead of macro rendering. ExamplePrintServices uses the deprecated html rendering system -- Key: OFBIZ-6288 URL: https://issues.apache.org/jira/browse/OFBIZ-6288 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/example Reporter: Adam Heath Priority: Minor Another case of html rendering in use instead of macro rendering. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Adam, This all sounds good to me. I will have time to review your improvements after May 1. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 9:37 PM, Adam Heath wrote: On 04/21/2015 12:29 AM, Jacopo Cappellato wrote: On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote: (picking a random email to respond to; I haven't read anything of this thread all weekend, I will need to spend some time doing so) Fyi, I have framework/start, base, and entity all compiling with maven now. API test cases work. Separate foo.jar and foo-test.jar are done. META-INF/services/ all located properly. Everything in base/lib/** and entity/lib/** has dependency settings in pom.xml, but *without* having to download anything(yet). I can't stress enough that there are *no* changes to any existing files. Absolutely none. As such, due to the volume of this discussion, I will be coming up with a way to have all these poms overlayed(or some other technical solution) to an unmodified ofbiz checkout. Git submodules might not be the right approach, I need to look at git subtree a bit more. ps: It's suprising how quickly I was able to start getting maven to work. I thought it would be extremely difficult. pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new. Hi Adam, I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community. My commit is not breaking anything. Why remove something that is harmless? Let's be positive and forward enabling; if a commit is reverted, then that reversion has not stopped any discussion, and now the original committer will have to do more work to re-add what was removed. This particular commit has not changed anyone's workflow, has not altered any existing file; it hasn't even broken any automated tests. Has anyone complained about eclipse or netbeans ceasing to function, because suddenly there is a pom.xml at the top level? in fact, no one will notice unless they run maven themselves. Seriously, what is the harm in leaving this early POC in trunk, esp. when I am willing to move over to an svn branch away from trunk? You have my attention. I have altered my off-work hours, to give up some of my free time, to improve the project. That is a big deal for me. Why not make use of this time in a productive matter? I am willing to do work. I am willing to move forward. I am implementing. Also, and this may sound like I'm tooting my own horn(well, ok, it is), but *I* implemented macros.xml and common.xml. I made the build system simpler. We used to have to copy the full build.xml into every component, and any changes had to be done to all of them. With this new build system(stating again, nothing has been broken *at all* with what has been added), not only will we be able to have the same set of current features, but we will get *even more*. Proper inter-project dependencies. Proper downloading of external libraries. No longer will anything be embedded. The LICENSE and NOTICE files will be reduced to a fraction of their size(and auto-generated, there's a maven plugin for this, based on all listed dependency items). All those project pages you see about project info, javadocs, etc, are produced by maven plugins. Better project distribution(maven can publish directory to a repo). Automatic version updates(all that TRUNK stuff in my examples). OFBiz will be a better behaved system in the Apache Family. Less work will be needed to maintain our own custom build.xml, as now the community at large will continue to improve the maven ecosystem. Less NIH. ps: In case you didn't notice, I have created a JIRA issue for this(OFBIZ-6271), and an svn branch. I will not be submitting separate patches into that issue; instead, changes will be in the branch. This allows for proper history to be maintained, once the change is merged in. I will continue to use git locally for this(as I always have), and will go silent for a short bit, but then mass-commit changes afterI have finessed them into something presentable. A new burst is coming in a few hours.
Re: move to git.
Yes, but these are commiters contributions, i mean non-commiters one should go thru jira. Le 21 avril 2015 23:00:26 UTC+02:00, Adam Heath doo...@brainfood.com a écrit : On 04/21/2015 08:09 AM, Gil portenseigne wrote: In every case, contribution will have to be given within Jira to get into the project. This is not the case even today. I see changes in the svn log that have no jira issue.
Re: [jira] [Created] (OFBIZ-6275) OFBiz code seems make use of other deprecated OFBiz features
On Apr 22, 2015, at 6:29 PM, Adam Heath doo...@brainfood.com wrote: Ok, all issues created. Hang back a bit before anyone starts taking ownership of stuff, I've need to make time to commit the ones I've already got fixed. kudos! Jacopo
[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507425#comment-14507425 ] Martin Becker commented on OFBIZ-6273: -- There are about 375 findings of Deprecated keyword in java code in the trunk, some are duplicated, because of the deprecated keyword in javaDoc and as annotation for the same method. What about to link this issue with [OFBIZ-6275] OFBiz code seems make use of other deprecated OFBiz features from Adam for which a branch already exists, since the use of some deprecated API by OFBiz has to be changed first before we can get rid of the deprecated API itself? I would vote for first fixing the findings from Adam and then removing the deprecated API, either in the branch Adam just created or in another branch in sequence. Another question is: What about deprecated fields/entities and corresponding upgrade services? Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507486#comment-14507486 ] Jacopo Cappellato commented on OFBIZ-6273: -- Thank you Martin, excellent work! I agree that the work that will be done in OFBIZ-6275 will simplify this task, we can definitely wait and then complete the work in that branch or wait for it to be merged. As regards the entities/fields: I'd vote to remove them and the supporting upgrade scripts from the trunk; they will still live in the release branches where they make more sense. And removing entity/fields definitions doesn't cause issues to existing data (i.e. OFBiz will not try to drop tables/columns). Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/22/2015 12:52 PM, David E. Jones wrote: On 21 Apr 2015, at 14:17, Adam Heath doo...@brainfood.com wrote: Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons. In google, search for maven, then gradle. See how many responses each one gets. Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java terms. Then, also do a A vs B vs C search, aka, maven vs gradle vs ant. After doing this, maven is still the right choice. This is an appeal to popularity, not utility. Did further. Read what is linked from google(or your search engine of choice). Just like code formatting can be a proxy to code quality, so can search result count. But you still have to investigate, and maven does seem to have higher community, support, etc.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/22/2015 12:53 PM, David E. Jones wrote: On 21 Apr 2015, at 14:09, Pierre Smits pierre.sm...@gmail.com wrote: Is this the path you want to walk? Code over Community? Engage in commit wars, just to force your way? Please don't! Collaborating is easier than forcing. The latter harms the project more than the first. Really? Doing a POC and proposing a direction implies all of this to you? I haven't done any forcing. I haven't done any commit wars. I've done a POC, as David mentions.
Re: move to git.
That raises another irritating thing about the JIRA SVN workflow vs GIT pull requests. If you look at the contributor graph on GitHub for OFBiz you will see that it currently has only 3 contributors. Foremost this is because the project committers have mostly not configured their Apache addresses into their GitHub accounts. Secondly, however, it is caused by the fact that all JIRA committed patches will show the name of the person who merged the patch rather than its original author. https://github.com/apache/ofbiz/graphs/contributors We can make up stories about why this is desirable but I think any honest assessment would conclude that it is an inconvenience at best and a hazard at worst. Eventually if these dots are not connected the origins of some OFBiz code could become as mysterious as the early CVS commits. With the GIT pull request workflow we would not only know who wrote the code but would still know who performed the merge. We could also sign the commits so that their origin is cryptographically confirmed. - Original Message - From: Gil Portenseigne gil.portensei...@nereide.fr Subject: Re: move to git. Yes, but these are commiters contributions, i mean non-commiters one should go thru jira.
Re: move to git.
From: Pierre Smits pierre.sm...@gmail.com Subject: Re: move to git. That, Ean, says more about github than SVN. See https://fisheye6.atlassian.com/users/ofbiz and https://fisheye6.atlassian.com/graph/ofbiz showing a totally different story. How do I see the people who submitted patches via JIRA?
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 21 Apr 2015, at 14:09, Pierre Smits pierre.sm...@gmail.com wrote: Is this the path you want to walk? Code over Community? Engage in commit wars, just to force your way? Please don't! Collaborating is easier than forcing. The latter harms the project more than the first. Really? Doing a POC and proposing a direction implies all of this to you? -David
Re: move to git.
That, Ean, says more about github than SVN. See https://fisheye6.atlassian.com/users/ofbiz and https://fisheye6.atlassian.com/graph/ofbiz showing a totally different story. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 7:31 PM, Ean Schuessler e...@brainfood.com wrote: That raises another irritating thing about the JIRA SVN workflow vs GIT pull requests. If you look at the contributor graph on GitHub for OFBiz you will see that it currently has only 3 contributors. Foremost this is because the project committers have mostly not configured their Apache addresses into their GitHub accounts. Secondly, however, it is caused by the fact that all JIRA committed patches will show the name of the person who merged the patch rather than its original author. https://github.com/apache/ofbiz/graphs/contributors We can make up stories about why this is desirable but I think any honest assessment would conclude that it is an inconvenience at best and a hazard at worst. Eventually if these dots are not connected the origins of some OFBiz code could become as mysterious as the early CVS commits. With the GIT pull request workflow we would not only know who wrote the code but would still know who performed the merge. We could also sign the commits so that their origin is cryptographically confirmed. - Original Message - From: Gil Portenseigne gil.portensei...@nereide.fr Subject: Re: move to git. Yes, but these are commiters contributions, i mean non-commiters one should go thru jira.
Re: move to git.
Tracking the original contributor is an important point. The nice thing about git is that every commit has a UUID so even as that commit is pulled from one repository to another the contributor and other details can be tracked. In SVN as things go from one repo to another this is lost (unless it's something like a full repository import). -David On 22 Apr 2015, at 10:31, Ean Schuessler e...@brainfood.com wrote: That raises another irritating thing about the JIRA SVN workflow vs GIT pull requests. If you look at the contributor graph on GitHub for OFBiz you will see that it currently has only 3 contributors. Foremost this is because the project committers have mostly not configured their Apache addresses into their GitHub accounts. Secondly, however, it is caused by the fact that all JIRA committed patches will show the name of the person who merged the patch rather than its original author. https://github.com/apache/ofbiz/graphs/contributors We can make up stories about why this is desirable but I think any honest assessment would conclude that it is an inconvenience at best and a hazard at worst. Eventually if these dots are not connected the origins of some OFBiz code could become as mysterious as the early CVS commits. With the GIT pull request workflow we would not only know who wrote the code but would still know who performed the merge. We could also sign the commits so that their origin is cryptographically confirmed. - Original Message - From: Gil Portenseigne gil.portensei...@nereide.fr Subject: Re: move to git. Yes, but these are commiters contributions, i mean non-commiters one should go thru jira.
[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014
[ https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507496#comment-14507496 ] Martin Becker commented on OFBIZ-6273: -- Thats my opinion, too (entities/fields). I will monitor [OFBIZ-6275] and perhaps deliver some patches for the issues there and come back to this task if afterwards. Remove from trunk the deprecated code if deprecated before December 2014 Key: OFBIZ-6273 URL: https://issues.apache.org/jira/browse/OFBIZ-6273 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Jacopo Cappellato The code that has been deprecated before December 2014 will be released in the releases of the 14.12 branch: in this way users will be notified about deprecated methods/code. For this reason we can proceed and remove all the deprecated code from trunk, deprecated before December 2014. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 21 Apr 2015, at 14:17, Adam Heath doo...@brainfood.com wrote: Gradle is a non-starter. When I saw that mentioned, I actually did do some comparisons. In google, search for maven, then gradle. See how many responses each one gets. Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java terms. Then, also do a A vs B vs C search, aka, maven vs gradle vs ant. After doing this, maven is still the right choice. This is an appeal to popularity, not utility. -David
[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=14507549#comment-14507549 ] Christian Carlow commented on OFBIZ-6085: - I guess a manufacturing extension of the WorkEffort entity would be entailed if the functionality were provided optional, however I'm not exactly sure how such an extension should be implemented yet. I wonder if an extra field such as WorkEffort.useTimeEntries should be created and allow to be set for routings and tasks and copied to the production runs and tasks which could also allow manual settings. Does this seem like an appropriate approach? Also, the production run declaration form provides a worker field that never gets used because the time entry code is commented which is the part of the code meant to use it. Therefore that field should probably be included in the group of time entry fields that should be hidden if the option is disabled. 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: move to git.
By committers referencing the contributors to the JIRA issue in the commit report. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 7:57 PM, Ean Schuessler e...@brainfood.com wrote: From: Pierre Smits pierre.sm...@gmail.com Subject: Re: move to git. That, Ean, says more about github than SVN. See https://fisheye6.atlassian.com/users/ofbiz and https://fisheye6.atlassian.com/graph/ofbiz showing a totally different story. How do I see the people who submitted patches via JIRA?
Re: move to git.
On 04/22/2015 01:00 PM, Pierre Smits wrote: By committers referencing the contributors to the JIRA issue in the commit report. But that's not reflected in the links you provided, or users aren't getting mentioned. With the git workflow, whoever created the commit will *definately* be recorded, it doesn't require some free-form text message, that may or may not be parsed correctly.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
From: David E. Jones d...@me.com Subject: Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml This is an appeal to popularity, not utility. I don't think we've proven that those fail to converge over time.
[jira] [Resolved] (OFBIZ-6278) JNDIConfigUtil makes use of deprecated getXmlRootElement
[ https://issues.apache.org/jira/browse/OFBIZ-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6278. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675465 JNDIConfigUtil makes use of deprecated getXmlRootElement Key: OFBIZ-6278 URL: https://issues.apache.org/jira/browse/OFBIZ-6278 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement caches it's return value; this has been deprecated, because DOM objects are memory intensive, and generally are only needed once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6280) SecurityFactory implements methods that have been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6280. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675463 SecurityFactory implements methods that have been deprecated Key: OFBIZ-6280 URL: https://issues.apache.org/jira/browse/OFBIZ-6280 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor This class implements Security, which has methods that have been deprecated. As such, it gets deprecation warnings when implementing those methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6290) ButtonEventConfig uses getXmlRootElement which has been deprecated
[ https://issues.apache.org/jira/browse/OFBIZ-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6290. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675466 ButtonEventConfig uses getXmlRootElement which has been deprecated -- Key: OFBIZ-6290 URL: https://issues.apache.org/jira/browse/OFBIZ-6290 Project: OFBiz Issue Type: Sub-task Components: specialpurpose/pos Reporter: Adam Heath Assignee: Adam Heath Priority: Minor ResourceLoader.getXmlRootElement() caches its return value; however, DOM elements are memory intensive, and the returned value tends to only be used once. So, this is a poor pattern. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OFBIZ-6279) UtilDateTime has an ImmutableDate inner class that has deprecation warnings
[ https://issues.apache.org/jira/browse/OFBIZ-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6279. --- Resolution: Fixed Fixed in branch OFBIZ-6275, r1675462 UtilDateTime has an ImmutableDate inner class that has deprecation warnings --- Key: OFBIZ-6279 URL: https://issues.apache.org/jira/browse/OFBIZ-6279 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath When extending/implementing a class/interface, where methods in the parent have been marked deprecated, sub-instances also get deprecation warnings. The fix here is to also mark the sub-instances deprecated(with @Deprecated or /** @deprecated */ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
From: Pierre Smits pierre.sm...@gmail.com Subject: Re: move to git. By committers referencing the contributors to the JIRA issue in the commit report. But that is not reflected in your referenced visualization: https://fisheye6.atlassian.com/users/ofbiz I think it would be easier if you simply concede that the current process does not let svn blame report the actual authors for patch lines. Here is a simple enough question, which non-committer has submitted the most code to OFBiz and what was the distribution of their changes amongst the various OFBiz components?
[jira] [Resolved] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
[
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath resolved OFBIZ-6284.
---
Resolution: Fixed
This is resolved in branch OFBIZ-6275, r1675520
ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
-
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
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=14508346#comment-14508346 ] Christian Carlow commented on OFBIZ-6085: - Pierre, Isn't ProductStore.reserveInventory an extension designed to allow configurability of that application functionality and shouldn't the same mechanism be used for controlling production declaration time entry capabilities (WorkEffort.useTimeEntries)? Do you suggest an alternative to the entity extension approach? 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: move to git.
On 22 Apr 2015, at 16:49, Adam Heath doo...@brainfood.com wrote: On 04/22/2015 06:13 PM, Jacopo Cappellato wrote: On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote: When this happened, we had to relicense the entire project from GPL to Apache 2.0. Gr It was not GPL! :-) It was something tho; I may be wrong on that, I didn't actually look it up. I do recall that switching was quite the ordeal. It was MIT, but that wasn't the real issue with all the CLAs... the ASF requires them but they are not generally required for other users of the Apache 2 license. This was a pain... took months of effort. Even under the ASF we don't know who all code has come from, there is no way to get a list from SVN or any other tool... not even from Jira (though that's closer, but we only have associations between those who opened issues or attached a patch or those sorts of activities, doesn't always match exactly which patch gets committed, etc... AND not all commits get linked back to the Jira issues... oh and mentioning a name in a commit, pretty useless from a reporting perspective... parsing difficulties, data cleanliness/consistency issues... nightmare). -David
Re: move to git.
https://github.com/ansible/ansible/graphs/contributors mpdehaan used to be *the* ansible guy. It was his original creation. He has since moved on, but 1000 contributors that have actual code inside the primary repository. Also look at https://github.com/ansible/ansible/graphs/contributors?from=2012-11-23to=2013-05-03type=c, which shows how you can have a draggable window; but having a nice gui is not what this sub-discussion is about. On 04/22/2015 06:14 PM, Pierre Smits wrote: Indeed, let's not amalgamate everything and keep the discussion clean. The https://fisheye6.atlassian.com/graph/ofbiz does show information about the jira issue (including the contributor, if done correctly). Just click on the blue i icon to the right of the comment excerpt. You'll see a modal window appearing with more info. Take as an example the commit done on April 18th starting with comment: 'A patch from Pierre Smits...' Thank you for sharing insights in how Git could work for this project. I appreciate it. Can you provide links to examples of an Apache project using Git that shows a contribution from a non-privileged contributor as you describe? It would surely help understanding the described visibility and help this community to make a sound decision when all has been said. Quoting: which non-committer has submitted the most code to OFBiz and what was the distribution of their changes amongst the various OFBiz components? I would love to see that too. Maybe our PMC chair can clarify and comment on that? Please remember: if anyone feels that this discussion has reached a saturation point (all viewpoints and concerns presented) and a sense of consensus needs to be established, just call a vote. The outcome will dictate the direction. To me this seems a procedural issue, not a code change. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
[jira] [Commented] (OFBIZ-6270) base/json/JSON has been removed, with no deprecation window
[ https://issues.apache.org/jira/browse/OFBIZ-6270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508221#comment-14508221 ] Adam Heath commented on OFBIZ-6270: --- Also, just because ofbiz upstream has changed things, and between 1 official release, has deprecated something(and/or removed the code), external vendors might need to support extensions that have to run against multiple versions of ofbiz. Having the ability to run this external code on both versions of ofbiz at the same time makes it easier to slowly upgrade the client systems, without having a flag day across everything. base/json/JSON has been removed, with no deprecation window --- Key: OFBIZ-6270 URL: https://issues.apache.org/jira/browse/OFBIZ-6270 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk, 12.04.04 Reporter: Adam Heath Assignee: Adam Heath Priority: Critical The antlr-based json parser(at org.ofbiz.base.json.JSON.cc) was removed last October(2014-10-27). However, no backwards-compatible class was left in place, with a proper @Deprecation tag applied. The proper approach should have been to leave the class in place, adding @Deprecation, and leaving the json-lib.jar in place. Then, after one successful release, removing the actual code. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Fwd: Re: Maven
Just to let everyone know that we are not the only people working on a switch to Maven. The Apache FOP team is also trying to see what the impact would be of switching to Maven. Being able to put libraries in Maven Central more easily seems to be a hot topic. Building the appropriate artifacts seems to be hard using their existing build tools. Forwarded Message from FOP mailing List On Wed, Apr 22, 2015 at 2:03 PM, Luis Bernardo lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote: Maybe I only spoke for myself, but I am in: +1 From what I understand publishing the source jars to maven central would be automatic then, since there is some plugin for that. Given the fact that I have spent many hours adapting the Batik ant file to produce the source jars for maven central (I am still in the process of checking the result is correct) any steps that help with that in the future (be either for FOP or Batik) are welcome. that's my exact thinking; one reason we have historically done a poor job of maven deployment is because we aren't using maven; switching to maven will make that a no-brainer and ensure correct deployment On 4/22/15 6:35 PM, Glenn Adams wrote: On Wed, Apr 22, 2015 at 10:31 AM, Luis Bernardo lmpmberna...@gmail.com mailto:lmpmberna...@gmail.com wrote: I think that maven will be embraced as soon as there is a volunteer to do the transition. A few years ago I went through the process of creating a full maven configuration for FOP; however, the group was not ready to make the transition at that time. I have recently converted another multiple-module internal project to maven from ant, and would be able to repeat the process on fop. However, I don't want to do it unless there is support to switch over. On 4/22/15 6:13 PM, Glenn Adams wrote: on another point, when can we transition to maven? our ant configurations are difficult to maintain and understand; we should modernize
Re: move to git.
On 22 Apr 2015, at 16:14, Pierre Smits pierre.sm...@gmail.com wrote: Indeed, let's not amalgamate everything and keep the discussion clean. The https://fisheye6.atlassian.com/graph/ofbiz does show information about the jira issue (including the contributor, if done correctly). Just click on the blue i icon to the right of the comment excerpt. You'll see a modal window appearing with more info. Take as an example the commit done on April 18th starting with comment: 'A patch from Pierre Smits...' Thank you for sharing insights in how Git could work for this project. I appreciate it. Can you provide links to examples of an Apache project using Git that shows a contribution from a non-privileged contributor as you describe? It would surely help understanding the described visibility and help this community to make a sound decision when all has been said. Not an ASF project, but here is an example of what that can look like (and demonstrating the shameful lack of community in Moqui Framework). In this case I am the only person with push/write permission to this git repository, so all others came through pull requests after they committed to their own fork repositories: https://github.com/moqui/moqui/graphs/contributors Quoting: which non-committer has submitted the most code to OFBiz and what was the distribution of their changes amongst the various OFBiz components? I would love to see that too. Maybe our PMC chair can clarify and comment on that? The PMC chair doesn't have access to any magic tools that are unavailable to the rest of us... this is an unknown (even if we can get approximate data from Jira and SVN). -David
Re: Renaming OFBiz artefacts
Can people explain the advantages? just in-line with other projects? that is it? how about all customizations and local implementations? a -1 from me too On 22/04/15 22:13, Adam Heath wrote: -1, but not permanently. If we start renaming things, then it'll become hard to port changes back and forth between release branches and trunk. We need to reduce the number of outstanding branches first, before this can even be started. On 04/22/2015 10:09 AM, Ron Wheeler wrote: I was thinking of something like an 8 hour sprint where several people divide up the task and do it and test it quickly. divide up by application, code/XML, seed data, documentation, testing and what ever makes sense to get the change done in a few hours. Ron On 22/04/2015 5:01 AM, Pierre Smits wrote: Ron, Notwithstanding the appropriateness of the elements in your response, everything done in the OFBiz project IS a community project (endeavour for a better word). Thank you for reiterating the invite for more collaboration. I wholeheartedly agree and support. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler rwhee...@artifact-software.com wrote: Definitely a good idea. Should it be done as a community project over a short period of time? It would seem to be easier to do as a sort of global search and replace followed by testing rather than modifying a piece and looking for all of the references to that code and changing them and testing and then picking the next piece. Adding a JIRA sounds like the best start. Ron On 22/04/2015 4:36 AM, Pierre Smits wrote: Hi all, In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian proposed to rename our OFBiz artefacts from org.ofbiz to org.apache.ofbiz to bring it more inline to conventions used by other Apache projects/products. Does this proposal need any further discussion? Or can we move forward by creating a JIRA and work from there? Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: jira workflow
Adam, JIRA offers quite some flexibility with respect to defining status field values (see: https://confluence.atlassian.com/display/JIRA063/Defining+Status+Field+Values) and workflow schemes ( https://confluence.atlassian.com/display/JIRA063/Configuring+workflow+schemes ) It might be so that what we have got is limited, e.g. just the default re status field (values https://confluence.atlassian.com/display/JIRA063/What+is+an+Issue#WhatisanIssue-Status ) I remember Jacques and I having discussed potential changes (status and workflow) in the past and what the process would of having that implemented. If I remember well, there are some options available to projects. But such questions about extensions should best be directed at INFRA. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 10:07 PM, Adam Heath doo...@brainfood.com wrote: So, I've started attempting to use JIRA and branches, to implement a new workflow. Basically, I'm seeing what the capabilities of the systems are. I've run into a bit of a mis-feature, I believe, so I'm asking here to see if anyone might help. Here is the workflow I am attempting to follow. 1: Bug/feature/etc gets created. 2: Branch is made with the name set to the id from (1). 3: Sub-tasks are made, to split up the large amount of work from (1). 4: Each sub-task can be assigned to different people, and work proceeds in parallel. The state of the sub-task moves from OPEN to IN-PROGRESS. 5: Commits are done to the shared branch from (2), with each message tagged with the id(s) from (3). 6: When a commit from (5) is pushed, the developer doing the work moves the issue state to RESOLVED. This is not closed, as the change is not available for testing by the reported yet. Nor has it been made available to the rest of the ecosystem. 7: Some code reviewer looks at the series of commits, and if they do what they set out to do, merges the branch to trunk/master/release. The issue state(s) change from RESOLVED to 8: The original filer looks at trunk/master/release, and if the original report has been resolved, changes the issue state from to CLOSED. I don't see an option in JIRA for the represenative state in 7. The commits I have just sent into branch OFBIZ-6275 are currently at line (6) from above.
Re: move to git.
Github shows the committers as contributors. The links I provided just shows a better overview of those contributors. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 8:05 PM, Adam Heath doo...@brainfood.com wrote: On 04/22/2015 01:00 PM, Pierre Smits wrote: By committers referencing the contributors to the JIRA issue in the commit report. But that's not reflected in the links you provided, or users aren't getting mentioned. With the git workflow, whoever created the commit will *definately* be recorded, it doesn't require some free-form text message, that may or may not be parsed correctly.
[jira] [Assigned] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
[ https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6277: - Assignee: Adam Heath framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath reassigned OFBIZ-6276: - Assignee: Adam Heath Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
@David: Really? No, I projected a scenario that could happen if due process isn't upheld. I rather not see such a scenario unfolding. And in this case I feel the gun was jumped. While still debating over pros and cons. A bit of patience applied would not have led to that projection. And remember I did a PoC on Ant+IVY (outside of our repository) and opened the discussion regarding opening a dev branch so that people evaluate that alternative and learn from my insights gathered in the beginning of 2014. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 7:53 PM, David E. Jones d...@me.com wrote: On 21 Apr 2015, at 14:09, Pierre Smits pierre.sm...@gmail.com wrote: Is this the path you want to walk? Code over Community? Engage in commit wars, just to force your way? Please don't! Collaborating is easier than forcing. The latter harms the project more than the first. Really? Doing a POC and proposing a direction implies all of this to you? -David
Re: move to git.
On 04/22/2015 06:13 PM, Jacopo Cappellato wrote: On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote: When this happened, we had to relicense the entire project from GPL to Apache 2.0. Gr It was not GPL! :-) It was something tho; I may be wrong on that, I didn't actually look it up. I do recall that switching was quite the ordeal.
Re: move to git.
It occasionally happens that committers don't reference the contributors. But that is seldom. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 8:05 PM, Adam Heath doo...@brainfood.com wrote: On 04/22/2015 01:00 PM, Pierre Smits wrote: By committers referencing the contributors to the JIRA issue in the commit report. But that's not reflected in the links you provided, or users aren't getting mentioned. With the git workflow, whoever created the commit will *definately* be recorded, it doesn't require some free-form text message, that may or may not be parsed correctly.
[jira] [Assigned] (OFBIZ-6284) ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
[
https://issues.apache.org/jira/browse/OFBIZ-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Heath reassigned OFBIZ-6284:
-
Assignee: Adam Heath
ServiceArtifactInfo uses deprecated getAll{Object}Names{Verb}
-
Key: OFBIZ-6284
URL: https://issues.apache.org/jira/browse/OFBIZ-6284
Project: OFBiz
Issue Type: Sub-task
Components: framework
Reporter: Adam Heath
Assignee: Adam Heath
Priority: Minor
I can't comment to much on this; the methods that have been marked deprecated
have no javadocs, nothing to indicate why they should no longer be used. I
haven't checked the commit log, however.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity
[ https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14508164#comment-14508164 ] Adam Heath commented on OFBIZ-6276: --- When I first saw this deprecation warning, I thought it would be something simple. Even when I filed this issue, I held back on deep thought. However, the refactor that is being attempted around storeAll is very back for backwards compatibility. A parameter is being removed, that has critical meaning. I don't really think this is something that can safely be implemented. A new method name would need to be created to do that refactor. Fix deprecation issues in framework/entity -- Key: OFBIZ-6276 URL: https://issues.apache.org/jira/browse/OFBIZ-6276 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Priority: Minor It appears that the storeAll() variants are being refactor; basically, the useCache parameter is being removed. However, this has caused the entity engine to have deprecation with itself. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote: When this happened, we had to relicense the entire project from GPL to Apache 2.0. Gr It was not GPL! :-) Jacopo
[jira] [Resolved] (OFBIZ-6277) framework/entity makes use of deprecated class Configuration
[ https://issues.apache.org/jira/browse/OFBIZ-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Heath resolved OFBIZ-6277. --- Resolution: Fixed This is resolved in branch OFBIZ-6275, r1675521 framework/entity makes use of deprecated class Configuration Key: OFBIZ-6277 URL: https://issues.apache.org/jira/browse/OFBIZ-6277 Project: OFBiz Issue Type: Sub-task Components: framework Reporter: Adam Heath Assignee: Adam Heath Priority: Minor EntitySaxReader makes use of freemarker.template.Configuration, which seems to be deprecated. -- 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=14508173#comment-14508173 ] Pierre Smits commented on OFBIZ-6085: - New extensions to current entities are not required to provide configurability of an applications. OFBiz has what is needed for that. 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: move to git.
The links you provide only show developers who have write access to svn. Git(not just github, let's not conflate anything) keeps track of more than that. If there was someone who had forked a repo, comitted something on their local desktop, then pushed to a public server, and then someone on the offiicially sanctioned ofbiz git repo pulled from this other source, then the original committor will now show as a contributor. And, besides, that isn't the point. The links you provided do *not* show anyone from jira. Full stop. They *only* show people who have write access to svn. Full stop. In the past, ofbiz made a decision to move to apache.org. When this happened, we had to relicense the entire project from GPL to Apache 2.0. This required finding all current and past SVN contributors, and asking their permission. Then, all commit messages were scrubbed, and if some user was mentioned in passing, they had to then be tracked down and ask their permission as well. The links you provide still do not show these additional patch suppliers, and would not have helped. If someone creates an issue in jira, then someone *else* uploads a file and attaches a patch, it is this someone else that is the owner of the code. Show me how you can track that down. On 04/22/2015 03:49 PM, Pierre Smits wrote: Github shows the committers as contributors. The links I provided just shows a better overview of those contributors. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Wed, Apr 22, 2015 at 8:05 PM, Adam Heath doo...@brainfood.com wrote: On 04/22/2015 01:00 PM, Pierre Smits wrote: By committers referencing the contributors to the JIRA issue in the commit report. But that's not reflected in the links you provided, or users aren't getting mentioned. With the git workflow, whoever created the commit will *definately* be recorded, it doesn't require some free-form text message, that may or may not be parsed correctly.
Re: move to git.
Indeed, let's not amalgamate everything and keep the discussion clean. The https://fisheye6.atlassian.com/graph/ofbiz does show information about the jira issue (including the contributor, if done correctly). Just click on the blue i icon to the right of the comment excerpt. You'll see a modal window appearing with more info. Take as an example the commit done on April 18th starting with comment: 'A patch from Pierre Smits...' Thank you for sharing insights in how Git could work for this project. I appreciate it. Can you provide links to examples of an Apache project using Git that shows a contribution from a non-privileged contributor as you describe? It would surely help understanding the described visibility and help this community to make a sound decision when all has been said. Quoting: which non-committer has submitted the most code to OFBiz and what was the distribution of their changes amongst the various OFBiz components? I would love to see that too. Maybe our PMC chair can clarify and comment on that? Please remember: if anyone feels that this discussion has reached a saturation point (all viewpoints and concerns presented) and a sense of consensus needs to be established, just call a vote. The outcome will dictate the direction. To me this seems a procedural issue, not a code change. Best regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
[jira] [Updated] (OFBIZ-6272) We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do
[ https://issues.apache.org/jira/browse/OFBIZ-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nuwan Koggalahewa updated OFBIZ-6272: - Description: We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do with existing features in ofbiz We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do with existing features in ofbiz - Key: OFBIZ-6272 URL: https://issues.apache.org/jira/browse/OFBIZ-6272 Project: OFBiz Issue Type: Wish Reporter: Nuwan Koggalahewa We want to use ofbiz for inventory management. Suppliers are the owners of the inventoy item. We want to charge inventory cost per kilo and per day. Is it possible to do with existing features in ofbiz -- This message was sent by Atlassian JIRA (v6.3.4#6332)
