[jira] [Created] (OFBIZ-6307) Add ability to change Routing statuses
Christian Carlow created OFBIZ-6307: --- Summary: Add ability to change Routing statuses Key: OFBIZ-6307 URL: https://issues.apache.org/jira/browse/OFBIZ-6307 Project: OFBiz Issue Type: Improvement Components: manufacturing Affects Versions: Trunk Reporter: Christian Carlow Only ROU_ACTIVE statusItem exists for statusTypeId ROUTING_STATUS. Adding another such as ROU_INACTIVE would allow for more control over routings. Doing so entails adding the statusId to the find and edit screens. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Milestone: Re: svn commit: r1676405 - in /ofbiz/branches/OFBIZ-6271: applications/product/pom.xml pom.xml
1) I'm using maven 3.0.4. I don't use the latest and greatest of everything. We(Brainfood) are currently utilizing Debian Wheezy, with backports, as are release platform target. 2) If I rm -rf $HOME/.m2/, I get the same problem. Issue confirmed. Thanks guys. I should have done step 2 before announcing. On 04/27/2015 11:57 PM, Ron Wheeler wrote: 1) Old version of Maven. running with the current version will make it easier to debug any problems 2) It looks like you have not built and deployed the parent project so the reference to the parent is not working. Ron On 28/04/2015 12:40 AM, Hans Bakker wrote: Hi Adam, tried it and found out on Ubuntu 14:04 the command is: mvn package -DskipTests and gives a number of errors maven version: Apache Maven 3.0.5 Maven home: /usr/share/maven Java version: 1.7.0_65, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-oracle/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.13.0-48-generic, arch: amd64, family: unix hans@hans:~/svn/OFBIZ-6271$ sudo bash errors: hans@hans:~/svn/OFBIZ-6271$ mvn package -DskipTests [INFO] Scanning for projects... [ERROR] The build could not read 45 projects - [Help 1] [ERROR] [ERROR] The project org.apache.ofbiz:ofbiz-start:TRUNK (/home/hans/svn/OFBIZ-6271/framework/start/pom.xml) has 1 error [ERROR] Non-resolvable parent POM for org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find org.apache.ofbiz:ofbiz-parent:pom:TRUNK in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ org.apache.ofbiz:ofbiz-component:TRUNK, /home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 - [Help 2] [ERROR] [ERROR] The project org.apache.ofbiz:ofbiz-base:TRUNK (/home/hans/svn/OFBIZ-6271/framework/base/pom.xml) has 1 error [ERROR] Non-resolvable parent POM for org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find org.apache.ofbiz:ofbiz-parent:pom:TRUNK in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ org.apache.ofbiz:ofbiz-component:TRUNK, /home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 - [Help 2] [ERROR] [Eand more On 28/04/15 09:15, Adam Heath wrote: With this commit, all optionally detected libraries/features during the compilation with ant are now being done with maven. A maven clean and maven package -DskipTests is runnable with tools/startofbiz.sh. I have not run system integration tests(aka, any test that requires a running ofbiz instance). The startup code does proceed without any exceptions, so I think this is progressing rapidly.
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. The rest of the versioned jars are just as bad. - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc Do each of the separate moqui sub-tools need their own runtime folder? How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc? - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it Wait. The webapp initializes the context factory? There isn't a separate way to do this? Does that mean Moqui is tied to a webapp? What kind of webapp? I hope it isn't servlets. You mention it as weboot. Does that mean it runs at the root of the webserver? This might be a noob question. - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) Ah. So that means that means that moqui-component needs a container definition. Ignore the above then. I have never liked that ofbiz startup delays initialization of certain components until they are magically called from some random bit of java code, aka, the web container starting up. - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory Sorry for the noob question, but does that mean that both ofbiz entityengine and moqui could talk to the same database backend(s), at the same time? This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. Actually, a bit simpler, would be to just see if moqui can be added to the classpath, and loaded, before translating any datamodels. Once that is done, then have a method that translates the model definitions dynamically at load time, so that they are always kept in sync. Once this has proven, then that dynamic translation can be removed, and the output of it can become the new static definition of the model. The reason I suggest this way, is so that hot-deploy components(or other file modifications) that alter the entity definitions dynamically(extends-entity, whole new entity definitions) can also work transparently. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 02:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ If each component were released separately, then it becomes a non-problem. I haven't yet given up on this, tho.
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 03:16 AM, Jacques Le Roux wrote: Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote: src/main/java/org/ofbiz/product/ src/main/minilang/org/ofbiz/product/ src/main/groovy/... src/test/java/org/ofbiz/product/ I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project. When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications. Hmm, right. Good idea. We(Brainfood) would love it if all the action code was turned into services. But, even in that case, src/main/scripts would be used, as I think src/main/groovy is for groovyc. I'll find out today if that is the case. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend api layer. Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code.
[jira] [Created] (OFBIZ-6310) createConditionList doesn't handle widget dropdown multi-submitted values when called by performFind
Christian Carlow created OFBIZ-6310: --- Summary: createConditionList doesn't handle widget dropdown multi-submitted values when called by performFind Key: OFBIZ-6310 URL: https://issues.apache.org/jira/browse/OFBIZ-6310 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6310) createConditionList doesn't handle widget dropdown multi-submitted values when called by performFind
[ https://issues.apache.org/jira/browse/OFBIZ-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6310: Attachment: OFBIZ-6310.patch createConditionList doesn't handle widget dropdown multi-submitted values when called by performFind Key: OFBIZ-6310 URL: https://issues.apache.org/jira/browse/OFBIZ-6310 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6310.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
Hi David, very good to have you back in the project! Exiting times ahead! Regards, Hans On 28/04/15 15:39, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
[jira] [Created] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager
Forrest Rae created OFBIZ-6311: -- Summary: Order Manager ViewQuote screen should display party name and link to party manager Key: OFBIZ-6311 URL: https://issues.apache.org/jira/browse/OFBIZ-6311 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: 13.07.01, 12.04.05, Trunk Reporter: Forrest Rae As a convenience, and to match the other applications, Order Manager ViewQuote screen should display party name and link to party manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
On 28 Apr 2015, at 07:42, Adam Heath doo...@brainfood.com wrote: On 04/28/2015 03:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) There are 2 separate items in this bullet point. I'll talk about the second, updating jar versions. HAHAHAHAHAHAHA! I have discovered that ofbiz is using hc.apache.org(HttpClient), and commons-httpclient. The former is the newer, rewritten, rearchitected, replacement for the latter. The rest of the versioned jars are just as bad. Sounds like a small project of its own... - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc Do each of the separate moqui sub-tools need their own runtime folder? How difficult would it be to have $OFBIZ_HOME/runtime/$tool1, runtime/$tool2, etc? The Moqui runtime folder is similar to the one in OFBiz with component directories, and framework specific directories for classes, conf, db, elasticsearch, lib, log, template, and txlog. The Derby DB files go under the db directory (similar to in OFBiz) and the same is true for the Elasticsearch files (if you are running an embedded ES node with local storage). Some of these Moqui needs as separate folders, some can be combined with OFBiz ones, like the Derby and log dirs. - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it Wait. The webapp initializes the context factory? There isn't a separate way to do this? Does that mean Moqui is tied to a webapp? What kind of webapp? I hope it isn't servlets. You mention it as weboot. Does that mean it runs at the root of the webserver? This might be a noob question. Moqui is designed to facilitate deployment as a single WAR file. The Screen definitions in Moqui live in an hierarchy and you can add the root screen of each of your apps under the /apps screen, or under the root screen if you don’t want the /apps screen decorations. There are other ways to deploy it, like the static init approach mentioned below, but for most use this is by far the easiest. There is even support to add the runtime directory to the WAR file which gets picked up automatically when present, making it possible to throw the whole thing into one big WAR file and drop it into Tomcat or upload it to AWS ElasticBeanstalk or the myriad of similar hosting options. - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) Ah. So that means that means that moqui-component needs a container definition. Ignore the above then. I have never liked that ofbiz startup delays initialization of certain components until they are magically called from some random bit of java code, aka, the web container starting up. Even though Moqui has a real init/destroy lifecycle, many things are lazy-loaded and cached just like in OFBiz. This provides a lot of flexibility in both development and for production maintenance/etc. Moqui does have some cache warming code for entities, services, and screens that is on by default in production mode. - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory Sorry for the noob question, but does that mean that both ofbiz entityengine and moqui could talk to the same database backend(s), at the same time? Yes. Initially this would be the easiest way to run them together. An early priority would be to use the Moqui transaction management (based on Bitronix or Atomikos, Bitronix being WAY faster and with the latest update far more reliable too) so that OFBiz Entity Engine and Moqui Entity Facade operations would share TX contexts. This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui
[jira] [Commented] (OFBIZ-6309) Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList
[ https://issues.apache.org/jira/browse/OFBIZ-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518319#comment-14518319 ] Christian Carlow commented on OFBIZ-6309: - Adrian, OpenJDK Runtime Environment (build 1.8.0_45-b13) on Fedora Linux 21 Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList - Key: OFBIZ-6309 URL: https://issues.apache.org/jira/browse/OFBIZ-6309 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6309.patch For some reason Locale.getAvailableLocales() returns an array list whose first member is a locale without a display name which causes an FTL error at ListLocales page. The error is not occurring for the demo trunk. The attached patch adds a line to UtilMisc to check that a displayName exists before adding the locale to the list in case the same happens for other users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager
[ https://issues.apache.org/jira/browse/OFBIZ-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6311: --- Attachment: OFBIZ-6311.patch Patch to include the party name and link to Party Manager. Might need some minor improvements to match the other applications. Order Manager ViewQuote screen should display party name and link to party manager -- Key: OFBIZ-6311 URL: https://issues.apache.org/jira/browse/OFBIZ-6311 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Labels: patch Attachments: OFBIZ-6311.patch As a convenience, and to match the other applications, Order Manager ViewQuote screen should display party name and link to party manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6311) Order Manager ViewQuote screen should display party name and link to party manager
[ https://issues.apache.org/jira/browse/OFBIZ-6311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6311: --- Affects Version/s: Release Branch 14.12 Order Manager ViewQuote screen should display party name and link to party manager -- Key: OFBIZ-6311 URL: https://issues.apache.org/jira/browse/OFBIZ-6311 Project: OFBiz Issue Type: Improvement Components: order Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Labels: patch Attachments: OFBIZ-6311.patch As a convenience, and to match the other applications, Order Manager ViewQuote screen should display party name and link to party manager. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518398#comment-14518398 ] Forrest Rae commented on OFBIZ-6312: I will need to also supply a patch for the Product Duplication form at the bottom of the screen as well. Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal: redefining the components' directory layout for source files
On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? Ant is the ultimate in flexibility. The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz. I would be tempted to look at providing alternative Ant builds. It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html Having Ant scripts that build individual components or groups of components should be pretty simple. It is also possible to deploy artifacts built with Ant to Maven Central. http://central.sonatype.org/pages/apache-ant.html I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development tasks, it can be part of the move to Maven and any reorganization of the applications. This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Created] (OFBIZ-6305) German translations for various applications
Martin Becker created OFBIZ-6305: Summary: German translations for various applications Key: OFBIZ-6305 URL: https://issues.apache.org/jira/browse/OFBIZ-6305 Project: OFBiz Issue Type: Improvement Components: ALL APPLICATIONS Affects Versions: Upcoming Branch Reporter: Martin Becker We would like to contribute missing german translations for the OFBiz applications based on the current trunk. There will arrive patches for this per application within this ticket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6034) Widget Refactoring: Refactor how links are rendered
[ https://issues.apache.org/jira/browse/OFBIZ-6034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-6034: Summary: Widget Refactoring: Refactor how links are rendered (was: Refactor how links are rendered) Widget Refactoring: Refactor how links are rendered --- Key: OFBIZ-6034 URL: https://issues.apache.org/jira/browse/OFBIZ-6034 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Pierre Smits Labels: ftl, java, links, xsd Currently links are rendered differently across menu, screen and form. We have: * link in menu-items * link in screens * hyperlink in forms, in field definitions * sub-hyperlink in forms, in display-entity in field definitions But how the links are rendered is not consistent. So can link-type=ajax-window be used to trigger a popup window, while it can't be used in a link in a menu-item. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
This is great news! Your participation will be invaluable! Adrian Crum Sandglass Software www.sandglass-software.com On 4/28/2015 9:39 AM, David E. Jones wrote: +1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
[jira] [Created] (OFBIZ-6306) Widget Refactoring: image src ../ should work in forms
Pierre Smits created OFBIZ-6306: --- Summary: Widget Refactoring: image src ../ should work in forms Key: OFBIZ-6306 URL: https://issues.apache.org/jira/browse/OFBIZ-6306 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Pierre Smits Currently a image src ../ can only be used at screen level. It should also work at form level. -- 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=14516972#comment-14516972 ] Jacques Le Roux commented on OFBIZ-6273: Agreed on entity/fields definitions an related scripts. But this might require an official vote and especially a mention at https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+Requiring+Data+Migration+-+upgrade+ofbiz . Unfortunately I guess we will be unable to update https://cwiki.apache.org/confluence/display/OFBIZ/Chinese+-+Revisions+Requiring+Data+Migration that's why I wonder if such pages should exist! 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] [Updated] (OFBIZ-6301) Widget Refactoring: implement HtmlScreenWrapper
[ https://issues.apache.org/jira/browse/OFBIZ-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-6301: Summary: Widget Refactoring: implement HtmlScreenWrapper (was: Widget Refactor: implement HtmlScreenWrapper) Widget Refactoring: implement HtmlScreenWrapper --- Key: OFBIZ-6301 URL: https://issues.apache.org/jira/browse/OFBIZ-6301 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Pierre Smits Currently we have HtmlFormWrapper.java so that form widgets can be rendered from java and groovy. Having something similar for screen widgets would increase the user experience as screen widget specific elements (sections, screenlets, etc) can be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6217) fix warnings in trunk on java source code
[ https://issues.apache.org/jira/browse/OFBIZ-6217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516963#comment-14516963 ] Jacques Le Roux commented on OFBIZ-6217: I had no special advices, just a global one, seems OK with your and Adrian's comments fix warnings in trunk on java source code - Key: OFBIZ-6217 URL: https://issues.apache.org/jira/browse/OFBIZ-6217 Project: OFBiz Issue Type: Improvement Components: ALL COMPONENTS Affects Versions: Trunk Reporter: Taher Alkhateeb Assignee: Adrian Crum Priority: Minor Labels: java, warning Fix For: Upcoming Branch Attachments: OFBIZ-6217-patch-4.patch, remove_unused_imports.patch, warnings_patch_2.patch, warnings_patch_2.patch Right now, we have 528 warnings on trunk out of which 238 are about raw types and 118 never used imports. So we can already eliminate most of the warning quite quickly. I will issue multiple patches to resolve most of these warnings. It might be a bit of a challenge to eliminate the raw types because the generics are not always deducable from the code especially when relying on external APIs -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Attachment: OFBIZ-6312.patch Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
Forrest Rae created OFBIZ-6312: -- Summary: Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: 13.07.01, 12.04.05, Trunk, Release Branch 14.12 Reporter: Forrest Rae Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: move to git.
On 04/28/2015 03:39 AM, Jacques Le Roux wrote: Le 25/04/2015 01:14, Adam Heath a écrit : On 04/23/2015 06:00 PM, David E. Jones wrote: An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there: https://github.com/apache/ofbiz/graphs/contributors If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts). Come on, everyone. It's a competition! See if you can beat Jacopo! No chances, guys, you are far behind me :D I was waiting for you to do that; I already new you were way out in front. I saw it last night. You're a machine(I mean that in the nicest way). Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers. Yes, hence my comments about quality and quantity, big data and our world ;) But, it's fun to play with gui graph libraries. What are we w/o fun? I dare to ask the question ;) Jacques PS: robots will do better... Something about the 3 laws?
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 03:27 AM, Jacopo Cappellato wrote:
On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
So you would like to suppress the concept of event?
Most of the events are currently implemented in Java and are already under src
folder.
Not what I mean. The following method definition pattern is the problem:
==
public static String $methodName(HttpServletRequest request,
HttpServletResponse response) {
Integer pageNum =
NumberParsingUtil.parseInt(request.getParameter(page));
...
// core logic starts here
ListMapString, Object searchDataResults =
dispatcher.runSync(doSearch, context);
MapString, Object parsedData = new HashMap();
int largeSizeCount = 0, smallSizeCount = 0;
for (MapString, Object data: searchDataResults) {
if (data.size() 10) largeSizeCount++;
if (data.size() 5) smallSizeCount++;
}
parsedData.put(largeSizeCount, largeSizeCount);
parsedData.put(smallSizeCount, smallSizeCount);
parsedData.put(totalCount, searchDataResults.size());
parsedData.put(results, searchDataResults);
..
request.setAttribute(search:parsedData, parsedData);
return success;
}
==
There are 3 things going on here. The first part reads the incoming
request data, fetching whatever it needs. The second does some kind of
business logic. The third then places the results of that back into the
request for later processing by further code.
The middle part needs to be extracted into a separate location that is
callable through the service engine.
ps: this is pseudo code
Re: Proposal: redefining the components' directory layout for source files
On 04/28/2015 08:22 AM, Ron Wheeler wrote: On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? You mis-parsed Jacques' statement. Remove the (no Ant) part, and it becomes: that would be a Maven only solution blocker. It is an issue with maven, not ant.
Re: Milestone: Re: svn commit: r1676405 - in /ofbiz/branches/OFBIZ-6271: applications/product/pom.xml pom.xml
On 04/28/2015 10:17 AM, Ron Wheeler wrote: 1) is probably not a problem but it does make it harder to get support if you run into a bug that has already been fixed. I find it hard to imagine a reason to use a piece of software that is known to be defective when there are several newer versions with those defects fixed (and perhaps some new ones added) :-) . 2) Removing your local repo will not add the parent pom to the repo. The message is pretty clear. You do not have org.apache.ofbiz:ofbiz-parent:pom:TRUNK in your local repo and it is not in Maven Central so Maven has no way to get it. You need to build and deploy the parent into your local repo. Ok, this is wrong. The issue you and Hans have reported has nothing to do at all with running install locally. I actually had bad relative paths. See r1676572. On a plus, running mvn at framework/start, applications/product, etc, is now also working(!). So, one actual sour point for maven has been dealt with. See r1676573. I still have an issue with the LICENSE+NOTICE stuff I'm doing, not being installed into the local repo. I'm attempting to see if there is another way to do that. ps: running mvn at the top level issues no dependency warnings. Running it at a sub level issues warnings about systemPath for deps. This is actually a bug with maven that it doesn't issue the warnings at the top level. These warnings will go away once we start downloading dependencies.
Re: move to git.
Le 28/04/2015 16:48, Adam Heath a écrit : Something about the 3 laws I'm more a Philip K. Dick aficionado, I believe robots will not follow the laws at some point, hu are we serious? ;D Jacques
Re: Milestone: Re: svn commit: r1676405 - in /ofbiz/branches/OFBIZ-6271: applications/product/pom.xml pom.xml
1) is probably not a problem but it does make it harder to get support if you run into a bug that has already been fixed. I find it hard to imagine a reason to use a piece of software that is known to be defective when there are several newer versions with those defects fixed (and perhaps some new ones added) :-) . 2) Removing your local repo will not add the parent pom to the repo. The message is pretty clear. You do not have org.apache.ofbiz:ofbiz-parent:pom:TRUNK in your local repo and it is not in Maven Central so Maven has no way to get it. You need to build and deploy the parent into your local repo. Ron On 28/04/2015 10:31 AM, Adam Heath wrote: 1) I'm using maven 3.0.4. I don't use the latest and greatest of everything. We(Brainfood) are currently utilizing Debian Wheezy, with backports, as are release platform target. 2) If I rm -rf $HOME/.m2/, I get the same problem. Issue confirmed. Thanks guys. I should have done step 2 before announcing. On 04/27/2015 11:57 PM, Ron Wheeler wrote: 1) Old version of Maven. running with the current version will make it easier to debug any problems 2) It looks like you have not built and deployed the parent project so the reference to the parent is not working. Ron On 28/04/2015 12:40 AM, Hans Bakker wrote: Hi Adam, tried it and found out on Ubuntu 14:04 the command is: mvn package -DskipTests and gives a number of errors maven version: Apache Maven 3.0.5 Maven home: /usr/share/maven Java version: 1.7.0_65, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-7-oracle/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.13.0-48-generic, arch: amd64, family: unix hans@hans:~/svn/OFBIZ-6271$ sudo bash errors: hans@hans:~/svn/OFBIZ-6271$ mvn package -DskipTests [INFO] Scanning for projects... [ERROR] The build could not read 45 projects - [Help 1] [ERROR] [ERROR] The project org.apache.ofbiz:ofbiz-start:TRUNK (/home/hans/svn/OFBIZ-6271/framework/start/pom.xml) has 1 error [ERROR] Non-resolvable parent POM for org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find org.apache.ofbiz:ofbiz-parent:pom:TRUNK in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ org.apache.ofbiz:ofbiz-component:TRUNK, /home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 - [Help 2] [ERROR] [ERROR] The project org.apache.ofbiz:ofbiz-base:TRUNK (/home/hans/svn/OFBIZ-6271/framework/base/pom.xml) has 1 error [ERROR] Non-resolvable parent POM for org.apache.ofbiz:ofbiz-component:TRUNK: Failure to find org.apache.ofbiz:ofbiz-parent:pom:TRUNK in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced and 'parent.relativePath' points at wrong local POM @ org.apache.ofbiz:ofbiz-component:TRUNK, /home/hans/svn/OFBIZ-6271/ofbiz-component-pom.xml, line 23, column 11 - [Help 2] [ERROR] [Eand more On 28/04/15 09:15, Adam Heath wrote: With this commit, all optionally detected libraries/features during the compilation with ant are now being done with maven. A maven clean and maven package -DskipTests is runnable with tools/startofbiz.sh. I have not run system integration tests(aka, any test that requires a running ofbiz instance). The startup code does proceed without any exceptions, so I think this is progressing rapidly. -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
[jira] [Commented] (OFBIZ-6313) change language cause exception
[ https://issues.apache.org/jira/browse/OFBIZ-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518676#comment-14518676 ] Wai commented on OFBIZ-6313: This issue seems related to https://issues.apache.org/jira/browse/OFBIZ-6309 Tried the patch and it fixes the problem. Closing issue. change language cause exception --- Key: OFBIZ-6313 URL: https://issues.apache.org/jira/browse/OFBIZ-6313 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Wai select the link to change language. ...console output... 2015-04-28 23:31:34,542 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getUserPreferenceGroup] finished in [5] milliseconds 2015-04-28 23:31:34,567 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getVisualThemeResources] finished in [24] milliseconds 2015-04-28 23:31:34,724 |http-bio-8443-exec-3 |ScreenFactory |I| Got 9 screens in 0.064s from: file:/home/wt/wt-mystuff/eclipse/workspace/ofbiz-trunk-wrk-restapi/framework/common/widget/LookupScreens.xml 2015-04-28 23:31:34,741 |http-bio-8443-exec-3 |ScreenFactory |I| Got 24 screens in 0.015s from: file:/home/wt/wt-mystuff/eclipse/workspace/ofbiz-trunk-wrk-restapi/framework/common/widget/CommonScreens.xml 2015-04-28 23:31:34,746 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getUserPreferenceGroup] finished in [1] milliseconds 2015-04-28 23:31:34,749 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getVisualThemeResources] finished in [2] milliseconds 2015-04-28 23:31:35,146 |http-bio-8443-exec-3 |runtime |E| Error executing FreeMarker template freemarker.core._TemplateModelException: ?substring(...) argument #2 had invalid value: The index mustn't be greater than the length of the string, 0, but it was 2. FTL stack trace (~ means nesting-related): - Failed at: #if ar.iw?contains(langAttr?substri... [in template component://common/webcommon/includes/listLocales.ftl at line 34, column 9] at freemarker.core.MessageUtil.newMethodArgInvalidValueException(MessageUtil.java:262) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.BuiltInsForStringsBasic$substringBI$1.newIndexGreaterThanLengthException(BuiltInsForStringsBasic.java:598) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.BuiltInsForStringsBasic$substringBI$1.exec(BuiltInsForStringsBasic.java:581) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.MethodCall._eval(MethodCall.java:62) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.eval(Expression.java:78) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.ListLiteral.getModelList(ListLiteral.java:89) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.MethodCall._eval(MethodCall.java:60) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.eval(Expression.java:78) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.evalToBoolean(Expression.java:118) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.evalToBoolean(Expression.java:110) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:46) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.MixedContent.accept(MixedContent.java:62) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visitByHiddingParent(Environment.java:333) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visitIteratorBlock(Environment.java:559) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.MixedContent.accept(MixedContent.java:62) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.process(Environment.java:290) [freemarker-2.3.22.jar:2.3.22] at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:257) [ofbiz-base.jar:?] at org.ofbiz.widget.model.HtmlWidget.renderHtmlTemplate(HtmlWidget.java:167) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.HtmlWidget$HtmlTemplate.renderWidgetString(HtmlWidget.java:216) [ofbiz-widget.jar:?] at
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Attachment: OFBIZ-6312.patch Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Description: Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. was:Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Comment: was deleted (was: I will need to also supply a patch for the Product Duplication form at the bottom of the screen as well.) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Description: Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. This should be useful in other areas of the system. was: Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6313) change language cause exception
Wai created OFBIZ-6313: -- Summary: change language cause exception Key: OFBIZ-6313 URL: https://issues.apache.org/jira/browse/OFBIZ-6313 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Wai select the link to change language. ...console output... 2015-04-28 23:31:34,542 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getUserPreferenceGroup] finished in [5] milliseconds 2015-04-28 23:31:34,567 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getVisualThemeResources] finished in [24] milliseconds 2015-04-28 23:31:34,724 |http-bio-8443-exec-3 |ScreenFactory |I| Got 9 screens in 0.064s from: file:/home/wt/wt-mystuff/eclipse/workspace/ofbiz-trunk-wrk-restapi/framework/common/widget/LookupScreens.xml 2015-04-28 23:31:34,741 |http-bio-8443-exec-3 |ScreenFactory |I| Got 24 screens in 0.015s from: file:/home/wt/wt-mystuff/eclipse/workspace/ofbiz-trunk-wrk-restapi/framework/common/widget/CommonScreens.xml 2015-04-28 23:31:34,746 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getUserPreferenceGroup] finished in [1] milliseconds 2015-04-28 23:31:34,749 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getVisualThemeResources] finished in [2] milliseconds 2015-04-28 23:31:35,146 |http-bio-8443-exec-3 |runtime |E| Error executing FreeMarker template freemarker.core._TemplateModelException: ?substring(...) argument #2 had invalid value: The index mustn't be greater than the length of the string, 0, but it was 2. FTL stack trace (~ means nesting-related): - Failed at: #if ar.iw?contains(langAttr?substri... [in template component://common/webcommon/includes/listLocales.ftl at line 34, column 9] at freemarker.core.MessageUtil.newMethodArgInvalidValueException(MessageUtil.java:262) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.BuiltInsForStringsBasic$substringBI$1.newIndexGreaterThanLengthException(BuiltInsForStringsBasic.java:598) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.BuiltInsForStringsBasic$substringBI$1.exec(BuiltInsForStringsBasic.java:581) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.MethodCall._eval(MethodCall.java:62) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.eval(Expression.java:78) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.ListLiteral.getModelList(ListLiteral.java:89) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.MethodCall._eval(MethodCall.java:60) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.eval(Expression.java:78) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.evalToBoolean(Expression.java:118) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.evalToBoolean(Expression.java:110) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:46) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.MixedContent.accept(MixedContent.java:62) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visitByHiddingParent(Environment.java:333) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visitIteratorBlock(Environment.java:559) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.MixedContent.accept(MixedContent.java:62) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.process(Environment.java:290) [freemarker-2.3.22.jar:2.3.22] at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:257) [ofbiz-base.jar:?] at org.ofbiz.widget.model.HtmlWidget.renderHtmlTemplate(HtmlWidget.java:167) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.HtmlWidget$HtmlTemplate.renderWidgetString(HtmlWidget.java:216) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.HtmlWidget.renderWidgetString(HtmlWidget.java:140) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.ModelScreenWidget$PlatformSpecific.renderWidgetString(ModelScreenWidget.java:1315) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.ModelScreenWidget.renderSubWidgetsString(ModelScreenWidget.java:98) [ofbiz-widget.jar:?]
[jira] [Comment Edited] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518716#comment-14518716 ] Forrest Rae edited comment on OFBIZ-6312 at 4/29/15 4:51 AM: - OFBIZ-6312.patch won't work against any other releases except trunk. Backporting is proving to be a pain. It's not to hard on 14.10, but does require manual effort. I imagine 13.07 will be the same. was (Author: f...@14x.net): OFBIZ-6312.patch won't work against release13.07 branch. It will need a different patch. Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (OFBIZ-6313) change language cause exception
[ https://issues.apache.org/jira/browse/OFBIZ-6313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wai closed OFBIZ-6313. -- Resolution: Fixed change language cause exception --- Key: OFBIZ-6313 URL: https://issues.apache.org/jira/browse/OFBIZ-6313 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Wai select the link to change language. ...console output... 2015-04-28 23:31:34,542 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getUserPreferenceGroup] finished in [5] milliseconds 2015-04-28 23:31:34,567 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getVisualThemeResources] finished in [24] milliseconds 2015-04-28 23:31:34,724 |http-bio-8443-exec-3 |ScreenFactory |I| Got 9 screens in 0.064s from: file:/home/wt/wt-mystuff/eclipse/workspace/ofbiz-trunk-wrk-restapi/framework/common/widget/LookupScreens.xml 2015-04-28 23:31:34,741 |http-bio-8443-exec-3 |ScreenFactory |I| Got 24 screens in 0.015s from: file:/home/wt/wt-mystuff/eclipse/workspace/ofbiz-trunk-wrk-restapi/framework/common/widget/CommonScreens.xml 2015-04-28 23:31:34,746 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getUserPreferenceGroup] finished in [1] milliseconds 2015-04-28 23:31:34,749 |http-bio-8443-exec-3 |ServiceDispatcher |T| Sync service [catalog/getVisualThemeResources] finished in [2] milliseconds 2015-04-28 23:31:35,146 |http-bio-8443-exec-3 |runtime |E| Error executing FreeMarker template freemarker.core._TemplateModelException: ?substring(...) argument #2 had invalid value: The index mustn't be greater than the length of the string, 0, but it was 2. FTL stack trace (~ means nesting-related): - Failed at: #if ar.iw?contains(langAttr?substri... [in template component://common/webcommon/includes/listLocales.ftl at line 34, column 9] at freemarker.core.MessageUtil.newMethodArgInvalidValueException(MessageUtil.java:262) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.BuiltInsForStringsBasic$substringBI$1.newIndexGreaterThanLengthException(BuiltInsForStringsBasic.java:598) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.BuiltInsForStringsBasic$substringBI$1.exec(BuiltInsForStringsBasic.java:581) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.MethodCall._eval(MethodCall.java:62) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.eval(Expression.java:78) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.ListLiteral.getModelList(ListLiteral.java:89) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.MethodCall._eval(MethodCall.java:60) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.eval(Expression.java:78) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.evalToBoolean(Expression.java:118) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Expression.evalToBoolean(Expression.java:110) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.ConditionalBlock.accept(ConditionalBlock.java:46) ~[freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.MixedContent.accept(MixedContent.java:62) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visitByHiddingParent(Environment.java:333) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.IteratorBlock$Context.runLoop(IteratorBlock.java:148) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visitIteratorBlock(Environment.java:559) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.IteratorBlock.accept(IteratorBlock.java:67) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.MixedContent.accept(MixedContent.java:62) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.visit(Environment.java:312) [freemarker-2.3.22.jar:2.3.22] at freemarker.core.Environment.process(Environment.java:290) [freemarker-2.3.22.jar:2.3.22] at org.ofbiz.base.util.template.FreeMarkerWorker.renderTemplate(FreeMarkerWorker.java:257) [ofbiz-base.jar:?] at org.ofbiz.widget.model.HtmlWidget.renderHtmlTemplate(HtmlWidget.java:167) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.HtmlWidget$HtmlTemplate.renderWidgetString(HtmlWidget.java:216) [ofbiz-widget.jar:?] at org.ofbiz.widget.model.HtmlWidget.renderWidgetString(HtmlWidget.java:140) [ofbiz-widget.jar:?] at
[jira] [Updated] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forrest Rae updated OFBIZ-6312: --- Attachment: (was: OFBIZ-6312.patch) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518716#comment-14518716 ] Forrest Rae commented on OFBIZ-6312: OFBIZ-6312.patch won't work against release13.07 branch. It will need a different patch. Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-6312) Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box
[ https://issues.apache.org/jira/browse/OFBIZ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14518716#comment-14518716 ] Forrest Rae edited comment on OFBIZ-6312 at 4/29/15 4:53 AM: - OFBIZ-6312.patch won't work against any other releases except trunk. Backporting is proving to be a pain. It's not to hard on 14.10, but does require manual effort. 13.07 will be harder as the same files don't exist, and it looks like the Widget framework was revamped between 13.07 and 14.10. was (Author: f...@14x.net): OFBIZ-6312.patch won't work against any other releases except trunk. Backporting is proving to be a pain. It's not to hard on 14.10, but does require manual effort. I imagine 13.07 will be the same. Catalog Manager's EditProduct screen HTML should place a limit on the size of text that can be entered in the Product Description box - Key: OFBIZ-6312 URL: https://issues.apache.org/jira/browse/OFBIZ-6312 Project: OFBiz Issue Type: Improvement Components: product Affects Versions: Release Branch 14.12, Trunk, 12.04.05, 13.07.01 Reporter: Forrest Rae Attachments: OFBIZ-6312.patch Catalog Manager's EditProduct and EditProductDup screens HTML should place a limit on the size of text that can be entered in the Product Description box. When more than 255 characters are entered an error is displayed. There is no easy way of knowing when you've hit the 255 character max without the HTML limiting it. The patch I'm including changes the TextArea to include the maxlength argument. This should be useful in other areas of the system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 15:22, Ron Wheeler a écrit : On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? No I meant if ever we would head to Maven only (no Ant build in the project) then it would be a blocker. Ant is the ultimate in flexibility. The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz. I would be tempted to look at providing alternative Ant builds. I'm undecided on this, but it seems redundant to me and duplicate to maintain. It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Having Ant scripts that build individual components or groups of components should be pretty simple. That exists already It is also possible to deploy artifacts built with Ant to Maven Central. http://central.sonatype.org/pages/apache-ant.html I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development tasks, it can be part of the move to Maven and any reorganization of the applications. This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven. I think, if ever we go the Maven way, we will still need Ant around and ready Jacques Ron
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 16:59, Adam Heath a écrit : On 04/28/2015 08:22 AM, Ron Wheeler wrote: On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? You mis-parsed Jacques' statement. Remove the (no Ant) part, and it becomes: that would be a Maven only solution blocker. It is an issue with maven, not ant. Yes, I'm a specialist of digressions in parenthesis, my mind is built that way it seems Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 16:47, Adam Heath a écrit : On 04/28/2015 03:16 AM, Jacques Le Roux wrote: Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote: src/main/java/org/ofbiz/product/ src/main/minilang/org/ofbiz/product/ src/main/groovy/... src/test/java/org/ofbiz/product/ I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project. When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications. Hmm, right. Good idea. We(Brainfood) would love it if all the action code was turned into services. But, even in that case, src/main/scripts would be used, as I think src/main/groovy is for groovyc. I'll find out today if that is the case. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend api layer. Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code. Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an architecture solution Jacques
Re: Milestone: Re: svn commit: r1676405 - in /ofbiz/branches/OFBIZ-6271: applications/product/pom.xml pom.xml
Le 28/04/2015 18:02, Adam Heath a écrit : On 04/28/2015 10:17 AM, Ron Wheeler wrote: 1) is probably not a problem but it does make it harder to get support if you run into a bug that has already been fixed. I find it hard to imagine a reason to use a piece of software that is known to be defective when there are several newer versions with those defects fixed (and perhaps some new ones added) :-) . 2) Removing your local repo will not add the parent pom to the repo. The message is pretty clear. You do not have org.apache.ofbiz:ofbiz-parent:pom:TRUNK in your local repo and it is not in Maven Central so Maven has no way to get it. You need to build and deploy the parent into your local repo. Ok, this is wrong. The issue you and Hans have reported has nothing to do at all with running install locally. I actually had bad relative paths. See r1676572. On a plus, running mvn at framework/start, applications/product, etc, is now also working(!). So, one actual sour point for maven has been dealt with. See r1676573. So no longer a blocker, OK Jacques I still have an issue with the LICENSE+NOTICE stuff I'm doing, not being installed into the local repo. I'm attempting to see if there is another way to do that. ps: running mvn at the top level issues no dependency warnings. Running it at a sub level issues warnings about systemPath for deps. This is actually a bug with maven that it doesn't issue the warnings at the top level. These warnings will go away once we start downloading dependencies.
Re: Proposal: redefining the components' directory layout for source files
On Apr 28, 2015, at 6:45 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Recently I have read in some ASF thread that the ASF prefers that source releases do not contain binaries; in light of this I would not be against a change in this direction. Jacopo
[jira] [Commented] (OFBIZ-6309) Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList
[ https://issues.apache.org/jira/browse/OFBIZ-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517956#comment-14517956 ] Adrian Crum commented on OFBIZ-6309: What JRE version are you using? There is no error on my local copy, so I suspect this is a bug in the JRE. Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList - Key: OFBIZ-6309 URL: https://issues.apache.org/jira/browse/OFBIZ-6309 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6309.patch For some reason Locale.getAvailableLocales() returns an array list whose first member is a locale without a display name which causes an FTL error at ListLocales page. The error is not occurring for the demo trunk. The attached patch adds a line to UtilMisc to check that a displayName exists before adding the locale to the list in case the same happens for other users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: OFBiz blog feeds
Hi, we currently maintain an OFBiz news section with monthly updates on our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The monthly update contains a summary of the latest community efforts, proposals and discussions and a more detailed summary of the changes in trunk with direct links to the issues. It is meant to be an information service for the german speaking OFBiz users to have easy access to the latest activities in the project without digging the MLs, commit history etc.. I could provide this also in english for the OFbiz community if you like. Michael ecomify GmbH www.ecomify.de Am 28.04.15 um 10:17 schrieb Jacopo Cappellato: On Apr 28, 2015, at 10:06 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 I like the idea of resurrecting the blog and use it for official announcements of the project. It would be great if we could include its feeds into the OFBiz main web page and replace the static News section we have now. Jacopo smime.p7s Description: S/MIME Cryptographic Signature
Re: Proposal: redefining the components' directory layout for source files
Interesting, it did not occur to me this was J2EE related +1 Jacques Le 24/04/2015 18:47, Adrian Crum a écrit : +1 OFBiz stopped following J2EE patterns years ago, so we might as well make it official. Adrian Crum Sandglass Software www.sandglass-software.com On 4/24/2015 3:57 PM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote: src/main/java/org/ofbiz/product/ src/main/minilang/org/ofbiz/product/ src/main/groovy/... src/test/java/org/ofbiz/product/ I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project. When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications. Jacopo
Re: move to git.
Le 25/04/2015 01:14, Adam Heath a écrit : On 04/23/2015 06:00 PM, David E. Jones wrote: An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there: https://github.com/apache/ofbiz/graphs/contributors If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts). Come on, everyone. It's a competition! See if you can beat Jacopo! No chances, guys, you are far behind me :D Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers. Yes, hence my comments about quality and quantity, big data and our world ;) But, it's fun to play with gui graph libraries. What are we w/o fun? I dare to ask the question ;) Jacques PS: robots will do better...
Re: move to git.
Le 25/04/2015 10:23, Pierre Smits a écrit : Creating the JIRA issue(s) early - not just after the commit, as a notification for release notes - will help increasing the awareness of all and opens the door to share insights before the commit and not after. Give the issue its obligatory waiting period (72 hrs) before the commit and due process is ensured. +1, I can't emphasize that more Jacques
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
+1 - with the clarification that to me begin replacing implies a PoC effort in a branch. I just saw this thread and need a little time to think over the best approach, but off the top of my head it would look something like: - add the moqui-framework-version.jar file and all dependent jars to a component directory under ofbiz/framework (these could go in the base or common components, but might be best separate for clarity); if needed update jars currently used in OFBiz where an older version is used (don't know if this is the case for any, mention for the sake of completeness) - add a Moqui runtime directory somewhere in the OFBiz directory tree (Moqui uses this for various things); this would contain the Moqui tools components (with the Tools and System apps) so we have a UI to look at Moqui internals, OFBiz data, etc - either in the Moqui runtime directory or as an OFBiz component add a webroot webapp; Moqui is designed to run in a single webapp, and I'd recommend this be separate from the existing OFBiz webapps for now; when this webapp loads it will init the Moqui ExecutionContextFactory, when it shuts down it will destroy it - because initializing Moqui when the webroot webapp starts may not be adequate, make sure the Moqui static init stuff is in place and working (in the Moqui.java class) - run my little templates to transform current OFBiz data model XML files into Moqui ones and put those in a Moqui component in the Moqui runtime directory This would be a basic PoC to get Moqui running inside OFBiz, and then we could start the real PoC of either a thunk layer as Adrian proposed, probably accessing the statically initialized Moqui ExecutionContextFactory since most OFBiz framework classes are statically initialized, or using the more dynamic initialization through the Moqui webroot webapp. For those who want a brief introduction to some of the differences between OFBiz Framework and Moqui Framework, see the OFBiz: How does it compare to Moqui? section at: http://www.moqui.org/framework/index.html That is an older document and isn't meant to be any sort of exhaustive list of the features of Moqui versus the features of OFBiz Framework, but gives a general idea about how some of the similar tools are different. For those who want to dive a bit deeper the Tutorial may be helpful: http://www.moqui.org/framework/docs/Tutorial.html For those who want to dive in neck deep the Making Apps with Moqui book is the more exhaustive reference to Moqui (though about 8 months old now and there are many new features, summarized in the ReleaseNotes.txt file for those curious): http://www.moqui.org/MakingAppsWithMoqui-1.0.pdf https://github.com/moqui/moqui/blob/master/ReleaseNotes.txt I would be happy to participate in this effort... if nothing else should be an interesting technical diversion. -David On 26 Apr 2015, at 07:44, Adrian Crum adrian.c...@sandglass-software.com wrote: As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote. -- Adrian Crum Sandglass Software www.sandglass-software.com
Re: Proposal: redefining the components' directory layout for source files
+1 Jacques Le 25/04/2015 12:39, Jacopo Cappellato a écrit : Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: I can imagine that some will vote a -1 regarding this reorganisation of the structure, as this will break backward compatibility and puts the pressure on all those users who have created extensions and replacements Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 25/04/2015 14:32, Michael Brohl a écrit : +1 for the mentioned statements, especially planning, an announced branch which is not backward compatible and a sensible look at users who build their business on the OFBiz foundation without denying serious changes just because of this fact. Maybe it is possible to provide some migration tools (scripts etc.) to help automate the migration and make it less painless for the users. At least a good documentation should be provided which should be started during development to get every change and best practice documented. Things often get lost when documenting later. It could be a must have for a patch for fundamental changes: no documentation, no commit. Indeed a bit like TDD. What Adam is doing with Git rebase and separated commit is heading in the right direction but we need also complete external documentation (wiki commits log) Jacques Michael ecomify GmbH www.ecomify.de Am 25.04.15 um 12:39 schrieb Jacopo Cappellato: Adrian, Pierre, this is exactly what I meant. Jacopo On Apr 25, 2015, at 11:36 AM, Pierre Smits pierre.sm...@gmail.com wrote: Migration plans help to ensure that external issues are addressed. It also helps to pick future release branch that will have these major changes, say r15 or 16 and plan/work towards having everything in place for that. I suggest we start working on getting the JIRA side first, before the creating the release branch so that we can get all issues identified and we don't get confronted with things overlooked. 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 Sat, Apr 25, 2015 at 11:24 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 25, 2015, at 10:39 AM, Pierre Smits pierre.sm...@gmail.com wrote: I can imagine that some will vote a -1 regarding this reorganisation of the structure, as this will break backward compatibility and puts the pressure on all those users who have created extensions and replacements Same here, and I really hope that people will not oppose to new ideas because of the concerns on backward incompatibilities or impact on existing investments. The OFBiz codebase needs to evolve into the future and this cannot be done if every new ideas gets a pushback because of impacts on other systems or user base: I see this trend happening lately and I think it is not wise. I am not saying that backward compatibility, stability and migration plans are not important factors: but I think they should not influence new ideas; only after a new ideas is considered valid for OFBiz, we should then focus on how to implement a roadmap to alleviate the pains of external codebases or users. We could create a stable release branch right before we start working to incompatible changes etc... but we should discuss what to do only after we have decided about the future. Jacopo
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 10:27, Jacopo Cappellato a écrit : On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: So you would like to suppress the concept of event? Most of the events are currently implemented in Java and are already under src folder. Jacopo In custom projects I like to use simple-methods events... Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques
Re: Proposal: redefining the components' directory layout for source files
Le 21/01/2015 16:08, Ron Wheeler a écrit : Very good reasons. I am excited by #7. If done correctly, it could make it much easier for new people to get involved since it should partition the application into chunks that are easier to learn. It will also relieve some of the management burden since the people reviewing code changes will be able to focus on key changes by ignoring check-ins that involve functions that they do not feel the need to examine closely and spending the time on check-ins to critical or complex code where there is a real danger that the code may pass the acceptance tests but have consequences for other modules or use cases. First step on the road to sub-projects? #2 does introduce the requirement for a sensible plan for the restructuring so that the impact on existing forks is controlled. It probably should be planned to coincide with a major release (so-called freeze) so that it is clear to everyone that the structure changed at a well-defined point. Might not be a bad time to look at changing org.ofbiz to org.apache.ofbiz since that will bring the code up to date and make the searching for modules in Maven Central a bit more sensible. I saw so far no really valuable reasons to change org.ofbiz to org.apache.ofbiz. Everybody knows I'm not a huge fan of currently planned changes, including and especially Maven. But if ever we get into this direction, I think this is a good reason... as you said to be carefully planned... and advertised, we have now also Twitter for that for people who have not enough time to follow the MLs. This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 Jacques It is also a simple but messy change that has a big impact of forks so it need to happen at a well defined point. It is a bigger project but not unmanageable with a bit of teamwork and a good IDE. Ron On 21/01/2015 4:06 AM, Jacopo Cappellato wrote: On Jan 20, 2015, at 1:49 PM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: Have you a clear idea of that this entails in term of migration, no only OOTB, but for custom projects which relies on trunk? I did some reasonings about it and it shouldn't be a big deal, especially on the programming side (it will require mostly search and replace sessions); of course I didn't do a thorough analysis, I just wanted to start the conversation here; the good news is that it can be done in chunks, hopefully with the help of the community (that could also support the migration of custom projects). I guess for Java it should not be so hard but for minilang and groovy could be harder, everybody does not use Idea (groovy part)... I am sorry but the above sentence doesn't make any sense to me... Also what does this bring to the project? Why do you want to do so (apart being in line with other projects)? And why should we be in line with them, do you envision something? The main advantages are the following: 1) standardize our layout structure to make it consistent with other projects (may make it easier for a new developer to understand OFBiz and appreciate it since the beginning) 2) review of past decision in light of the experience, lessons learned and established conventions: most of the decision we took for the project were optimal at that time but may be suboptimal in light of new technologies, standards, trends etc... in order for our (more than 10 years old) project to stay fresh and healthy we have to always revisit our decisions and keep it young; when the first objection to proposals is that this could impact custom projects or existing contributors, then in my opinion it is a sign of defensive mentality that could bring to staleness; these concerns and considerations are still important, but should be discussed (trying to propose a good migration plan) at a later point and not used to slow down or stop the change 3) simplify the pre compilation of Groovy (and possibly other) scripts: this could be done to spot coding errors in advance, to improve performance at runtime, or just to simplify the deployment 4) simplify our build scripts: right now the ant scripts do some funny/complex stuff in order to separate test classes from main ones 5) moving a step forward in the direction of allowing the adoption of Maven like tools (Maven, Gradle etc..) that could make it easier to share external components (grow the ecosystem) 6) right now there is not a standard place for non-Java services or events: the script folder is traditionally used for Minilang, where should Groovy (or other languages) service implementation live? 7) I have some, longer term, plans to make the OFBiz framework codebase more
OFBiz blog feeds
On Apr 28, 2015, at 10:06 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 I like the idea of resurrecting the blog and use it for official announcements of the project. It would be great if we could include its feeds into the OFBiz main web page and replace the static News section we have now. Jacopo
Re: Proposal: redefining the components' directory layout for source files
I agree with you. I have already committed to bilingualism in my development and system administration processes. Once we get through this discussion, I might put out an argument for an installer like IzPack that can make deployment into different environments with the appropriate seed data loaded a bit less transparent and more user friendly. Ron On 28/04/2015 12:45 PM, Jacques Le Roux wrote: Le 28/04/2015 15:22, Ron Wheeler a écrit : On 28/04/2015 3:31 AM, Jacques Le Roux wrote: Le 27/04/2015 16:52, Adam Heath a écrit : On 04/27/2015 09:40 AM, Jacques Le Roux wrote: You can already compile components separately by using the specific build files Yeah, I know, and it's a pain in my side. I actually like being able to *compile* each component separately, by changing to that folder, and running ant. I haven't yet been able to get maven to make that possible. Yikes, that would be a Maven only solution (no Ant) blocker :/ Jacques Why would Ant have trouble with a different project structure? No I meant if ever we would head to Maven only (no Ant build in the project) then it would be a blocker. Ant is the ultimate in flexibility. The change will affect the existing Ant processes but I find it hard to imagine how it would prevent Ant from building OFBiz. I would be tempted to look at providing alternative Ant builds. I'm undecided on this, but it seems redundant to me and duplicate to maintain. It might be nice to have a simple final assemble with Ant that pulls jar files from Maven Central and uses these jars to build OFBiz http://andreafrancia.it/2010/04/how-to-download-from-jars-from-mavencentral-with-ant-without-ivy.html This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Having Ant scripts that build individual components or groups of components should be pretty simple. That exists already It is also possible to deploy artifacts built with Ant to Maven Central. http://central.sonatype.org/pages/apache-ant.html I don't see Ant support as a difficult part of a move to Maven but if there is a real demand to support the use of Ant for 100% of the development tasks, it can be part of the move to Maven and any reorganization of the applications. This will require a high level of cooperation between the experts in the Ant build scripts and the experts promoting Maven. I think, if ever we go the Maven way, we will still need Ant around and ready Jacques Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102
Re: Proposal: redefining the components' directory layout for source files
And the reasoning behind that is quite simple: saving on storage and bandwidth, thus cost. Best regards, Pierre Op dinsdag 28 april 2015 heeft Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com het volgende geschreven: On Apr 28, 2015, at 6:45 PM, Jacques Le Roux jacques.le.r...@les7arts.com javascript:; wrote: This is interesting, now I wonder if Jacopo still think the same than at https://issues.apache.org/jira/browse/OFBIZ-5464?focusedCommentId=13947664 Recently I have read in some ASF thread that the ASF prefers that source releases do not contain binaries; in light of this I would not be against a change in this direction. Jacopo -- Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com
Re: Proposal: redefining the components' directory layout for source files
Le 28/04/2015 18:59, Jacques Le Roux a écrit : Le 28/04/2015 16:47, Adam Heath a écrit : On 04/28/2015 03:16 AM, Jacques Le Roux wrote: Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote: src/main/java/org/ofbiz/product/ src/main/minilang/org/ofbiz/product/ src/main/groovy/... src/test/java/org/ofbiz/product/ I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project. When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications. Hmm, right. Good idea. We(Brainfood) would love it if all the action code was turned into services. But, even in that case, src/main/scripts would be used, as I think src/main/groovy is for groovyc. I'll find out today if that is the case. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Way way way too much business logic is embedded and tied to events that *require* javax.servlet. This makes it hard to use ofbiz soley as a backend api layer. Not all servlet code can be removed. Aka, the aforementioned parameter validation/conversion logic. However, all such input methods should just pass the munged data stream(s) to the service engine, for processing. This includes the ShoppingCart code. Following Hans's initiative in r1163084 I used MockHttpServletRequest/Response in services but I must agree it's more a (interesting) hack than an architecture solution Jacques To clarify this was to reuse events inside services, notably the ShoppingCart... Jacques
[jira] [Created] (OFBIZ-6308) Form widget drop-down should reselect multiple submitted options
Christian Carlow created OFBIZ-6308: --- Summary: Form widget drop-down should reselect multiple submitted options Key: OFBIZ-6308 URL: https://issues.apache.org/jira/browse/OFBIZ-6308 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Christian Carlow Form widget multi-dropdowns only reselect single options submitted but should also reselect multiple options submitted. This was previously discussed back in 2011 on ML: http://mail-archives.apache.org/mod_mbox/ofbiz-user/201102.mbox/%3CFF794895DC4942FB9F3090336C3DC63A@inspiron530%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Fwd: [ANN] Apache Maven 3.3.3 Release
This is the latest version of Maven. Ron Forwarded Message Hi! The Apache Maven Team is pleased to announce the release of 3.3.3 The release notes can be found here: http://maven.apache.org/docs/3.3.3/release-notes.html The release can be downloaded from: http://maven.apache.org/download.cgi Full list of changes can be viewed in JIRA: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12332054 Thanks, The Maven Team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[jira] [Commented] (OFBIZ-6308) Form widget drop-down should reselect multiple submitted options
[ https://issues.apache.org/jira/browse/OFBIZ-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14517681#comment-14517681 ] Christian Carlow commented on OFBIZ-6308: - Adding encode-output=false allowed the existing functionality to work. The attached patch replaces the encoded open and close brackets with the decoded values so that the attribute isn't necessary before the functionality works. Form widget drop-down should reselect multiple submitted options - Key: OFBIZ-6308 URL: https://issues.apache.org/jira/browse/OFBIZ-6308 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6308.patch Form widget multi-dropdowns only reselect single options submitted but should also reselect multiple options submitted. This was previously discussed back in 2011 on ML: http://mail-archives.apache.org/mod_mbox/ofbiz-user/201102.mbox/%3CFF794895DC4942FB9F3090336C3DC63A@inspiron530%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6308) Form widget drop-down should reselect multiple submitted options
[ https://issues.apache.org/jira/browse/OFBIZ-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6308: Attachment: OFBIZ-6308.patch Form widget drop-down should reselect multiple submitted options - Key: OFBIZ-6308 URL: https://issues.apache.org/jira/browse/OFBIZ-6308 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6308.patch Form widget multi-dropdowns only reselect single options submitted but should also reselect multiple options submitted. This was previously discussed back in 2011 on ML: http://mail-archives.apache.org/mod_mbox/ofbiz-user/201102.mbox/%3CFF794895DC4942FB9F3090336C3DC63A@inspiron530%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: VOTE: Begin Replacing OFBiz Framework With Moqui
-1 currently for me If we are inspired of Moqui to improve OFBiz framework not to replace it, I will review my vote. For main framework components, I prefer keep the source code control under this community instead of load only jar Nicolas Le 26/04/2015 16:44, Adrian Crum a écrit : As was discussed last week, there is some interest in replacing some (or all) of OFBiz with Moqui (http://www.moqui.org/framework/index.html). To the scope reasonable, I propose that we begin by converting the following parts of the OFBiz framework with Moqui: Entity Engine Service Engine Security Other parts of the OFBiz framework could be converted as well, but I think this would be a good starting point, and if is successful, then more of OFBiz can be converted later. I believe we can create a thunk component to help solve compatibility problems, but that is a separate discussion. I only mention it here in case compatibility concerns might influence a vote.
Re: svn commit: r1675852 - in /ofbiz/trunk/applications/accounting/servicedef: secas.xml secas_invoice.xml
Hi Pranay, That's cool, but is it not worth a Jira for releases logs? Thanks Jacques Le 24/04/2015 15:29, pran...@apache.org a écrit : Author: pranayp Date: Fri Apr 24 13:29:56 2015 New Revision: 1675852 URL: http://svn.apache.org/r1675852 Log: Fixed the order in which invoice and payment transactions are created. Payment transactions were being created prior to invoice transactions, It causes confusion for accountants in real world. It was a seca execution order which was causing the issue on setInvoiceStatus. Moved the trigger on setInvoiceStatus for checkInvoicePaymentApplications and capturePaymentsByInvoice from secas.xml to secas_invoice.xml, so that we do invoice transactions prior to payment. Modified: ofbiz/trunk/applications/accounting/servicedef/secas.xml ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml Modified: ofbiz/trunk/applications/accounting/servicedef/secas.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/servicedef/secas.xml?rev=1675852r1=1675851r2=1675852view=diff == --- ofbiz/trunk/applications/accounting/servicedef/secas.xml (original) +++ ofbiz/trunk/applications/accounting/servicedef/secas.xml Fri Apr 24 13:29:56 2015 @@ -158,13 +158,4 @@ under the License. condition field-name=productTypeId operator=equals value=ASSET_USAGE/ action service=createFixedAssetAndLinkToProduct mode=sync/ /eca - -eca service=setInvoiceStatus event=commit -condition field-name=invoiceId operator=is-not-empty/ -condition field-name=statusId operator=equals value=INVOICE_READY/ -condition field-name=oldStatusId operator=not-equals value=INVOICE_READY/ -condition field-name=oldStatusId operator=not-equals value=INVOICE_PAID/ -action service=checkInvoicePaymentApplications mode=sync/ -action service=capturePaymentsByInvoice mode=sync/ -/eca /service-eca Modified: ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml URL: http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml?rev=1675852r1=1675851r2=1675852view=diff == --- ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml (original) +++ ofbiz/trunk/applications/accounting/servicedef/secas_invoice.xml Fri Apr 24 13:29:56 2015 @@ -47,4 +47,12 @@ under the License. action service=createMatchingPaymentApplication mode=sync/ /eca +eca service=setInvoiceStatus event=commit +condition field-name=invoiceId operator=is-not-empty/ +condition field-name=statusId operator=equals value=INVOICE_READY/ +condition field-name=oldStatusId operator=not-equals value=INVOICE_READY/ +condition field-name=oldStatusId operator=not-equals value=INVOICE_PAID/ +action service=checkInvoicePaymentApplications mode=sync/ +action service=capturePaymentsByInvoice mode=sync/ +/eca /service-eca
Re: OFBiz blog feeds
Hi Michael Thanks for the link and also the offer. It looks really good and I think it would be great to have something like this on our site. So yes it would be nice to have this information in English so that we can publish it as part of a our official resurrected blog. Thanks Sharan On 28.4.2015 10:32, Michael Brohl wrote: Hi, we currently maintain an OFBiz news section with monthly updates on our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The monthly update contains a summary of the latest community efforts, proposals and discussions and a more detailed summary of the changes in trunk with direct links to the issues. It is meant to be an information service for the german speaking OFBiz users to have easy access to the latest activities in the project without digging the MLs, commit history etc.. I could provide this also in english for the OFbiz community if you like. Michael ecomify GmbH www.ecomify.de Am 28.04.15 um 10:17 schrieb Jacopo Cappellato: On Apr 28, 2015, at 10:06 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 I like the idea of resurrecting the blog and use it for official announcements of the project. It would be great if we could include its feeds into the OFBiz main web page and replace the static News section we have now. Jacopo
Re: OFBiz blog feeds
With a blog by means of Apache Roller, the PMC can delegate authorship to cater for blog posts in various languages and for various focus areas. 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 Tue, Apr 28, 2015 at 11:17 AM, Sharan Foga sharan.f...@gmail.com wrote: Hi Michael Thanks for the link and also the offer. It looks really good and I think it would be great to have something like this on our site. So yes it would be nice to have this information in English so that we can publish it as part of a our official resurrected blog. Thanks Sharan On 28.4.2015 10:32, Michael Brohl wrote: Hi, we currently maintain an OFBiz news section with monthly updates on our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The monthly update contains a summary of the latest community efforts, proposals and discussions and a more detailed summary of the changes in trunk with direct links to the issues. It is meant to be an information service for the german speaking OFBiz users to have easy access to the latest activities in the project without digging the MLs, commit history etc.. I could provide this also in english for the OFbiz community if you like. Michael ecomify GmbH www.ecomify.de Am 28.04.15 um 10:17 schrieb Jacopo Cappellato: On Apr 28, 2015, at 10:06 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 I like the idea of resurrecting the blog and use it for official announcements of the project. It would be great if we could include its feeds into the OFBiz main web page and replace the static News section we have now. Jacopo
Re: Proposal: redefining the components' directory layout for source files
On Apr 28, 2015, at 10:52 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: In custom projects I like to use simple-methods events... We will not change your custom projects :-) Jacopo
Re: Proposal: redefining the components' directory layout for source files
Quoting: We will not change your custom projects :-) On top of that, with proper notification you can plan to address the migration aspects to your wishes. 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 Tue, Apr 28, 2015 at 11:07 AM, Jacopo Cappellato jacopo.cappell...@hotwaxsystems.com wrote: On Apr 28, 2015, at 10:52 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: In custom projects I like to use simple-methods events... We will not change your custom projects :-) Jacopo
Re: OFBiz blog feeds
Interesting proposition: +1 Jacques Le 28/04/2015 11:28, Pierre Smits a écrit : With a blog by means of Apache Roller, the PMC can delegate authorship to cater for blog posts in various languages and for various focus areas. 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 Tue, Apr 28, 2015 at 11:17 AM, Sharan Foga sharan.f...@gmail.com wrote: Hi Michael Thanks for the link and also the offer. It looks really good and I think it would be great to have something like this on our site. So yes it would be nice to have this information in English so that we can publish it as part of a our official resurrected blog. Thanks Sharan On 28.4.2015 10:32, Michael Brohl wrote: Hi, we currently maintain an OFBiz news section with monthly updates on our blog (see https://www.ecomify.de/blog/category/apache-ofbiz/). The monthly update contains a summary of the latest community efforts, proposals and discussions and a more detailed summary of the changes in trunk with direct links to the issues. It is meant to be an information service for the german speaking OFBiz users to have easy access to the latest activities in the project without digging the MLs, commit history etc.. I could provide this also in english for the OFbiz community if you like. Michael ecomify GmbH www.ecomify.de Am 28.04.15 um 10:17 schrieb Jacopo Cappellato: On Apr 28, 2015, at 10:06 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: This reminds me that long ago I created an Apache Roller blog for OFBiz but we never used it. This is a good reason to resurrect it. Some people don't use Twitter, don't follow the MLs, but they could still register to a blog which is only sending few messages/year! I spoke about it with Sharan the week ago https://blogs.apache.org/ofbiz/entry/apache_ofbiz_new_blog1 I like the idea of resurrecting the blog and use it for official announcements of the project. It would be great if we could include its feeds into the OFBiz main web page and replace the static News section we have now. Jacopo
[jira] [Updated] (OFBIZ-6309) Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList
[ https://issues.apache.org/jira/browse/OFBIZ-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6309: Issue Type: Bug (was: Improvement) Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList - Key: OFBIZ-6309 URL: https://issues.apache.org/jira/browse/OFBIZ-6309 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow For some reason Locale.getAvailableLocales() returns an array list whose first member is a locale without a display name which causes an FTL error at ListLocales page. The error is not occurring for the demo trunk. The attached patch adds a line to UtilMisc to check that a displayName exists before adding the locale to the list in case the same happens for other users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OFBIZ-6309) Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList
Christian Carlow created OFBIZ-6309: --- Summary: Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList Key: OFBIZ-6309 URL: https://issues.apache.org/jira/browse/OFBIZ-6309 Project: OFBiz Issue Type: Improvement Components: framework Affects Versions: Trunk Reporter: Christian Carlow For some reason Locale.getAvailableLocales() returns an array list whose first member is a locale without a display name which causes an FTL error at ListLocales page. The error is not occurring for the demo trunk. The attached patch adds a line to UtilMisc to check that a displayName exists before adding the locale to the list in case the same happens for other users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6308) Form widget drop-down should reselect multiple submitted options
[ https://issues.apache.org/jira/browse/OFBIZ-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6308: Issue Type: Bug (was: Improvement) Form widget drop-down should reselect multiple submitted options - Key: OFBIZ-6308 URL: https://issues.apache.org/jira/browse/OFBIZ-6308 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6308.patch Form widget multi-dropdowns only reselect single options submitted but should also reselect multiple options submitted. This was previously discussed back in 2011 on ML: http://mail-archives.apache.org/mod_mbox/ofbiz-user/201102.mbox/%3CFF794895DC4942FB9F3090336C3DC63A@inspiron530%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OFBIZ-6309) Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList
[ https://issues.apache.org/jira/browse/OFBIZ-6309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Carlow updated OFBIZ-6309: Attachment: OFBIZ-6309.patch Freemarker errors at lanaguge change page due to locale with no display name returned by Locale.getAvailableLocales() in UtilMisc.java#getAvailableLocaleList - Key: OFBIZ-6309 URL: https://issues.apache.org/jira/browse/OFBIZ-6309 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Trunk Reporter: Christian Carlow Attachments: OFBIZ-6309.patch For some reason Locale.getAvailableLocales() returns an array list whose first member is a locale without a display name which causes an FTL error at ListLocales page. The error is not occurring for the demo trunk. The attached patch adds a line to UtilMisc to check that a displayName exists before adding the locale to the list in case the same happens for other users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OFBIZ-5847) If define the amp; and combine with part that encode to ∂
[ https://issues.apache.org/jira/browse/OFBIZ-5847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14300211#comment-14300211 ] Jacques Le Roux edited comment on OFBIZ-5847 at 4/28/15 7:20 AM: - Maybe this issue is (also) a good moment to rethink how we render linking within menu items, screens, screenlets and forms... See: OFBIZ-6034 So that we have a solution that works consistently wherever it is applied. was (Author: pfm.smits): Maybe this issue is (also) a good moment to rethink how we render linking within menu items, screens, screenlets and forms... See: [https://issues.apache.org/jira/browse/OFBIZ-6034] So that we have a solution that works consistently wherever it is applied. If define the amp; and combine with part that encode to ∂ Key: OFBIZ-5847 URL: https://issues.apache.org/jira/browse/OFBIZ-5847 Project: OFBiz Issue Type: Bug Components: ALL APPLICATIONS Affects Versions: Trunk Reporter: Supachai Chaima-ngua Assignee: Nicolas Malin Labels: encode, url Fix For: Trunk, 12.04.06, 13.07.02 Attachments: OFBIZ-5847.patch, OFBiz WorkEffort Manager Calendar.png XML widget problems: If define the amp; and combine with part that encode to ∂ Example BEFORE: viewprofile?status=Yamp;partyId=Demo AFTER: viewprofile?status=Y∂yId=Demo -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proposal: redefining the components' directory layout for source files
Le 24/04/2015 17:01, Adam Heath a écrit : On 04/24/2015 09:57 AM, Jacopo Cappellato wrote: On Apr 24, 2015, at 4:36 PM, Adam Heath doo...@brainfood.com wrote: src/main/java/org/ofbiz/product/ src/main/minilang/org/ofbiz/product/ src/main/groovy/... src/test/java/org/ofbiz/product/ I haven't yet gotten to integrating a groovy compiler plugin, I see only one .groovy in framework/service/src, for the entire project. When I proposed this I was also thinking about to move the groovy (data preparation) scripts that are currently under WEB-INF/actions folders; most of them could be used in non web applications. Hmm, right. Good idea. We(Brainfood) would love it if all the action code was turned into services. But, even in that case, src/main/scripts would be used, as I think src/main/groovy is for groovyc. I'll find out today if that is the case. So you would like to suppress the concept of event? What about the validation and conversion with the map-processor (only in simple-method) and the convenience of events in some cases? https://cwiki.apache.org/confluence/display/OFBIZ/FAQ+-+Tips+-+Tricks+-+Cookbook+-+HowTo#FAQ-Tips-Tricks-Cookbook-HowTo-DifferenceBetweenEventAndService Jacques
Re: Proposal: redefining the components' directory layout for source files
On Apr 28, 2015, at 10:16 AM, Jacques Le Roux jacques.le.r...@les7arts.com wrote: So you would like to suppress the concept of event? Most of the events are currently implemented in Java and are already under src folder. Jacopo
