date:20120323


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-4464.
--

   Resolution: Fixed
Fix Version/s: Release 10.04
   SVN trunk
   Release Branch 11.04
 Assignee: Jacques Le Roux

Thanks Kiran,

Your patch is in 
trunk r1304200
R11.04 r1304202
R10.04 r1304201




 StringIndexOutOfBoundsException in OfbizContentTransform
 

 Key: OFBIZ-4464
 URL: https://issues.apache.org/jira/browse/OFBIZ-4464
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
 Fix For: Release Branch 11.04, SVN trunk, Release 10.04

 Attachments: OFBIZ-4464-OfbizContentTransformJava.patch


  exception report 
 --
 Error in request handler: 
 Exception: org.ofbiz.widget.screen.ScreenRenderException
 Message: Error rendering screen 
 [component://ecommerce/widget/CommonScreens.xml#main-decorator]: 
 java.lang.StringIndexOutOfBoundsException: String index out of range: 0 
 (String index out of range: 0)
  cause 
 -
 Exception: java.lang.StringIndexOutOfBoundsException
 Message: String index out of range: 0
  stack trace 
 ---
 java.lang.StringIndexOutOfBoundsException: String index out of range: 0
 java.lang.String.charAt(String.java:686)
 org.ofbiz.webapp.ftl.OfbizContentTransform$1.close(OfbizContentTransform.java:97)
 freemarker.core.Environment.visit(Environment.java:265)
 freemarker.core.UnifiedCall.accept(UnifiedCall.java:116)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4669) sessionAttributes doesn't work from screen widget

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236400#comment-13236400
 ] 

Jacques Le Roux commented on OFBIZ-4669:


Bump... A patch?

 sessionAttributes doesn't work from screen widget
 -

 Key: OFBIZ-4669
 URL: https://issues.apache.org/jira/browse/OFBIZ-4669
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk
Reporter: Kiran Gawde

 In the screen widget, add a set action that refers to sessionAttributes, it 
 doesn't work. 
 e.g: Following doesn't work:
 set field=titleProperty value=${sessionAttributes.autoName}/
 Following works:
  set field=titleProperty from-field=autoName from-scope=user/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (OFBIZ-4580) Categories - calculated trails

2012-03-23 Thread Jacques Le Roux (Resolved) (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux resolved OFBIZ-4580.


   Resolution: Fixed
Fix Version/s: SVN trunk

Thanks Paul,

I committed your patch in trunk at r1304205. I wait Kiran's anwser before 
closing

 Categories - calculated trails
 --

 Key: OFBIZ-4580
 URL: https://issues.apache.org/jira/browse/OFBIZ-4580
 Project: OFBiz
  Issue Type: Improvement
Reporter: Paul Piper
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: CategoryWorker-with-trail-export.patch, 
 CategoryWorker.patch, OFBIZ-4580-CategoryWorker-with-trail-export.patch


 Hey folks,
 been a while since I contributed. I noticed that currently ofbiz misses a 
 simple function to generate a category trail. Generating a trail, however, is 
 often useful when generating breadcrums, facetted search results, and proper 
 category trees in general. Hence I created the following as a timesaver:
 {code:title=getCategoryTrail|borderStyle=solid}
 public static  List getCategoryTrail(String productCategoryId,DispatchContext 
 dctx){
   GenericDelegator delegator = (GenericDelegator) 
 dctx.getDelegator();
   ListString trailElements = FastList.newInstance();
 trailElements.add(productCategoryId);
 String parentProductCategoryId = productCategoryId;
 while (UtilValidate.isNotEmpty(parentProductCategoryId)) {
 // find product category rollup
 try {
 ListEntityCondition rolllupConds = FastList.newInstance();
 
 rolllupConds.add(EntityCondition.makeCondition(productCategoryId, 
 parentProductCategoryId));
 rolllupConds.add(EntityUtil.getFilterByDateExpr());
 ListGenericValue productCategoryRollups = 
 delegator.findList(ProductCategoryRollup, 
 EntityCondition.makeCondition(rolllupConds), null, 
 UtilMisc.toList(-fromDate), null, true);
 if (UtilValidate.isNotEmpty(productCategoryRollups)) {
 // add only categories that belong to the top category to 
 trail
 for (GenericValue productCategoryRollup : 
 productCategoryRollups) {
 String trailCategoryId = 
 productCategoryRollup.getString(parentProductCategoryId);
 parentProductCategoryId = trailCategoryId;
 if (trailElements.contains(trailCategoryId)) {
 break;
 }else{
   trailElements.add(trailCategoryId);
 }
 }
 } else {
 parentProductCategoryId = null;
 }
 } catch (GenericEntityException e) {
 Debug.logError(e, Cannot generate trail from product 
 category, module);
 }
 }
 Collections.reverse(trailElements);
 return trailElements;
   }
 {code}
 I suggest to add this to the CategoryWorker.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (OFBIZ-4738) Minor Refactoring in CategoryWorker - use delegator instead of request in getRelatedCategoriesRet


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-4738.
--

Resolution: Fixed
  Assignee: Jacques Le Roux

Thanks Marcus,

Your patch is in trunk at r1304207  


 Minor Refactoring in CategoryWorker - use delegator instead of request in 
 getRelatedCategoriesRet
 -

 Key: OFBIZ-4738
 URL: https://issues.apache.org/jira/browse/OFBIZ-4738
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: SVN trunk
Reporter: Markus M. May
Assignee: Jacques Le Roux
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-refactor_category_worker.patch


 The method getRelatedCategoriesRet uses the request, the final called method 
 could be called using the delegator directly easily. I have refactored the 
 method accordingly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1304061 - /ofbiz/trunk/.classpath


I put Aptana (better free js Eclipse.plugin editor I found) and explained at
https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions

So it's also at 
https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766052
So we could get rid of it, yes

Other opinions?

Jacques


From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com

I have mixed feelings about this:

1) it is not nice to see the IDE specific files in the OFBiz home: .project, .classpath (for Eclipse) and 
ofbiz.aptana.js.format.xml (for Aptana)

** off topic question: why do we have the .hgignore file? (ignore file for 
Mercurial?)
2) in the same time the Eclipse files are very well maintained by the community (it is clear that the user base is large) and so I 
would tend to keep them... also we do not update jars so frequently
3) even if I don't use Eclipse, most editors provide the ability to load a project from an Eclipse project (or similar) so this is 
not only a benefit for Eclipse users


All in all I would say, we could keep/tolerate Eclipse specific files (I would get rid of Aptana, unless there is a large user 
base); but the implied message is not: please contribute the configuration for your IDE; the more we have the better is.


Jacopo

On Mar 22, 2012, at 11:40 PM, Jacques Le Roux wrote:


+1, this is also the conclusion I came out (with a slow brain)

Jacques

From: Scott Gray scott.g...@hotwaxmedia.com
The flip side of the argument would be that everyone who is using eclipse would then have to maintain it themselves, not sure 
that

would be more efficient for the community.

Personally I don't really mind cleaning it up myself when I see an error, takes a few minutes at most.  And I think that's the 
way

it should be, the users of a specific IDE should bear the burden of keeping it 
up to date, others shouldn't have to worry about
it.  If we started including some other IDE's config files I certainly wouldn't 
want to have to deal with them.

Regards
Scott

On 23/03/2012, at 10:26 AM, J. Eckard wrote:


Do we really want to keep IDE-specific support files in the repository (and 
keep them updated by hand in perpetuity)? I ask
because it seems like a fragile (and tedious) process… for instance, I don't use eclipse and I have no idea if or how this 
change

will affect an existing eclipse project.

Joe

On Mar 22, 2012, at 5:05 PM, eckar...@apache.org wrote:


Author: eckardjf
Date: Thu Mar 22 21:05:17 2012
New Revision: 1304061

URL: http://svn.apache.org/viewvc?rev=1304061view=rev
Log:
update eclipse classpath file to reflect jetty container upgrade

Modified:
 ofbiz/trunk/.classpath

Modified: ofbiz/trunk/.classpath
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.classpath?rev=1304061r1=1304060r2=1304061view=diff
==
--- ofbiz/trunk/.classpath (original)
+++ ofbiz/trunk/.classpath Thu Mar 22 21:05:17 2012
@@ -138,12 +138,21 @@
  classpathentry kind=lib 
path=framework/jcr/lib/jackrabbit-spi-commons-2.3.3.jar/
  classpathentry kind=lib path=framework/jcr/lib/jackrabbit-ocm-2.0.jar 
sourcepath=/ocm/
  classpathentry kind=lib path=framework/jcr/lib/jcr-2.0.jar/
-classpathentry kind=lib 
path=framework/jetty/lib/jasper-compiler-5.5.15.jar/
-classpathentry kind=lib 
path=framework/jetty/lib/jasper-runtime-5.5.15.jar/
-classpathentry kind=lib path=framework/jetty/lib/jetty-6.1.11.jar/
-classpathentry kind=lib 
path=framework/jetty/lib/jetty-ajp-6.1.11.jar/
-classpathentry kind=lib 
path=framework/jetty/lib/jetty-sslengine-6.1.11.jar/
-classpathentry kind=lib 
path=framework/jetty/lib/jetty-util-6.1.11.jar/
+classpathentry kind=lib 
path=framework/jetty/com.sun.el-2.2.0.v20110806.jar/
+classpathentry kind=lib 
path=framework/jetty/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-ajp-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-continuation-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-http-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-io-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-security-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-server-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-servlet-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-util-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-webapp-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/jetty-xml-8.1.2.v20120308.jar/
+classpathentry kind=lib 
path=framework/jetty/org.apache.jasper.glassfish-2.2.2.v201112011158.jar/
+classpathentry kind=lib 
path=framework/jetty/org.apache.taglibs.standard.glassfish-1.2.0.v201112081803.jar/
+classpathentry kind=lib

Re: svn commit: r1304061 - /ofbiz/trunk/.classpath

2012-03-23 Thread Nicolas Malin


It would be interesting to put all configuration file on tools :
* tools/ide/eclipse
* tools/ide/netbeans
and load configuration by ant ?

Nicolas

Le 23/03/2012 07:49, Jacques Le Roux a écrit :
I put Aptana (better free js Eclipse.plugin editor I found) and 
explained at

https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions

So it's also at 
https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766052

So we could get rid of it, yes

Other opinions?

Jacques


From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com

I have mixed feelings about this:

1) it is not nice to see the IDE specific files in the OFBiz home: 
.project, .classpath (for Eclipse) and ofbiz.aptana.js.format.xml 
(for Aptana)
** off topic question: why do we have the .hgignore file? (ignore 
file for Mercurial?)
2) in the same time the Eclipse files are very well maintained by the 
community (it is clear that the user base is large) and so I would 
tend to keep them... also we do not update jars so frequently
3) even if I don't use Eclipse, most editors provide the ability to 
load a project from an Eclipse project (or similar) so this is not 
only a benefit for Eclipse users


All in all I would say, we could keep/tolerate Eclipse specific files 
(I would get rid of Aptana, unless there is a large user base); but 
the implied message is not: please contribute the configuration for 
your IDE; the more we have the better is.


Jacopo

On Mar 22, 2012, at 11:40 PM, Jacques Le Roux wrote:


+1, this is also the conclusion I came out (with a slow brain)

Jacques

From: Scott Gray scott.g...@hotwaxmedia.com
The flip side of the argument would be that everyone who is using 
eclipse would then have to maintain it themselves, not sure that

would be more efficient for the community.

Personally I don't really mind cleaning it up myself when I see an 
error, takes a few minutes at most.  And I think that's the way
it should be, the users of a specific IDE should bear the burden of 
keeping it up to date, others shouldn't have to worry about
it.  If we started including some other IDE's config files I 
certainly wouldn't want to have to deal with them.


Regards
Scott

On 23/03/2012, at 10:26 AM, J. Eckard wrote:

Do we really want to keep IDE-specific support files in the 
repository (and keep them updated by hand in perpetuity)? I ask
because it seems like a fragile (and tedious) process… for 
instance, I don't use eclipse and I have no idea if or how this 
change

will affect an existing eclipse project.

Joe

On Mar 22, 2012, at 5:05 PM, eckar...@apache.org wrote:


Author: eckardjf
Date: Thu Mar 22 21:05:17 2012
New Revision: 1304061

URL: http://svn.apache.org/viewvc?rev=1304061view=rev
Log:
update eclipse classpath file to reflect jetty container upgrade

Modified:
 ofbiz/trunk/.classpath

Modified: ofbiz/trunk/.classpath
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.classpath?rev=1304061r1=1304060r2=1304061view=diff
== 


--- ofbiz/trunk/.classpath (original)
+++ ofbiz/trunk/.classpath Thu Mar 22 21:05:17 2012
@@ -138,12 +138,21 @@
classpathentry kind=lib 
path=framework/jcr/lib/jackrabbit-spi-commons-2.3.3.jar/
classpathentry kind=lib 
path=framework/jcr/lib/jackrabbit-ocm-2.0.jar sourcepath=/ocm/

classpathentry kind=lib path=framework/jcr/lib/jcr-2.0.jar/
- classpathentry kind=lib 
path=framework/jetty/lib/jasper-compiler-5.5.15.jar/
- classpathentry kind=lib 
path=framework/jetty/lib/jasper-runtime-5.5.15.jar/
- classpathentry kind=lib 
path=framework/jetty/lib/jetty-6.1.11.jar/
- classpathentry kind=lib 
path=framework/jetty/lib/jetty-ajp-6.1.11.jar/
- classpathentry kind=lib 
path=framework/jetty/lib/jetty-sslengine-6.1.11.jar/
- classpathentry kind=lib 
path=framework/jetty/lib/jetty-util-6.1.11.jar/
+ classpathentry kind=lib 
path=framework/jetty/com.sun.el-2.2.0.v20110806.jar/
+ classpathentry kind=lib 
path=framework/jetty/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-ajp-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-continuation-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-http-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-io-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-security-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-server-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-servlet-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-util-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-webapp-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/jetty-xml-8.1.2.v20120308.jar/
+ classpathentry kind=lib 
path=framework/jetty/org.apache.jasper.glassfish-2.2.2.v201112011158.jar/
+ classpathentry kind=lib

Re: svn commit: r1304061 - /ofbiz/trunk/.classpath

Keep it simple.  Just keep the files for 1 or 2 IDEs and 1 or 2 VCSs and be 
done with it.

I do think we should get rid of Aptana.

Regards
Scott

On 23/03/2012, at 8:40 PM, Nicolas Malin wrote:

 It would be interesting to put all configuration file on tools :
 * tools/ide/eclipse
 * tools/ide/netbeans
 and load configuration by ant ?
 
 Nicolas
 
 Le 23/03/2012 07:49, Jacques Le Roux a écrit :
 I put Aptana (better free js Eclipse.plugin editor I found) and explained at
 https://cwiki.apache.org/confluence/display/OFBADMIN/Coding+Conventions
 
 So it's also at 
 https://cwiki.apache.org/confluence/pages/viewpageattachments.action?pageId=7766052
 So we could get rid of it, yes
 
 Other opinions?
 
 Jacques
 
 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 I have mixed feelings about this:
 
 1) it is not nice to see the IDE specific files in the OFBiz home: 
 .project, .classpath (for Eclipse) and ofbiz.aptana.js.format.xml (for 
 Aptana)
 ** off topic question: why do we have the .hgignore file? (ignore file for 
 Mercurial?)
 2) in the same time the Eclipse files are very well maintained by the 
 community (it is clear that the user base is large) and so I would tend to 
 keep them... also we do not update jars so frequently
 3) even if I don't use Eclipse, most editors provide the ability to load a 
 project from an Eclipse project (or similar) so this is not only a benefit 
 for Eclipse users
 
 All in all I would say, we could keep/tolerate Eclipse specific files (I 
 would get rid of Aptana, unless there is a large user base); but the 
 implied message is not: please contribute the configuration for your IDE; 
 the more we have the better is.
 
 Jacopo
 
 On Mar 22, 2012, at 11:40 PM, Jacques Le Roux wrote:
 
 +1, this is also the conclusion I came out (with a slow brain)
 
 Jacques
 
 From: Scott Gray scott.g...@hotwaxmedia.com
 The flip side of the argument would be that everyone who is using eclipse 
 would then have to maintain it themselves, not sure that
 would be more efficient for the community.
 
 Personally I don't really mind cleaning it up myself when I see an error, 
 takes a few minutes at most.  And I think that's the way
 it should be, the users of a specific IDE should bear the burden of 
 keeping it up to date, others shouldn't have to worry about
 it.  If we started including some other IDE's config files I certainly 
 wouldn't want to have to deal with them.
 
 Regards
 Scott
 
 On 23/03/2012, at 10:26 AM, J. Eckard wrote:
 
 Do we really want to keep IDE-specific support files in the repository 
 (and keep them updated by hand in perpetuity)? I ask
 because it seems like a fragile (and tedious) process… for instance, I 
 don't use eclipse and I have no idea if or how this change
 will affect an existing eclipse project.
 
 Joe
 
 On Mar 22, 2012, at 5:05 PM, eckar...@apache.org wrote:
 
 Author: eckardjf
 Date: Thu Mar 22 21:05:17 2012
 New Revision: 1304061
 
 URL: http://svn.apache.org/viewvc?rev=1304061view=rev
 Log:
 update eclipse classpath file to reflect jetty container upgrade
 
 Modified:
 ofbiz/trunk/.classpath
 
 Modified: ofbiz/trunk/.classpath
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/.classpath?rev=1304061r1=1304060r2=1304061view=diff
 ==
  
 --- ofbiz/trunk/.classpath (original)
 +++ ofbiz/trunk/.classpath Thu Mar 22 21:05:17 2012
 @@ -138,12 +138,21 @@
 classpathentry kind=lib 
 path=framework/jcr/lib/jackrabbit-spi-commons-2.3.3.jar/
 classpathentry kind=lib 
 path=framework/jcr/lib/jackrabbit-ocm-2.0.jar sourcepath=/ocm/
 classpathentry kind=lib path=framework/jcr/lib/jcr-2.0.jar/
 - classpathentry kind=lib 
 path=framework/jetty/lib/jasper-compiler-5.5.15.jar/
 - classpathentry kind=lib 
 path=framework/jetty/lib/jasper-runtime-5.5.15.jar/
 - classpathentry kind=lib 
 path=framework/jetty/lib/jetty-6.1.11.jar/
 - classpathentry kind=lib 
 path=framework/jetty/lib/jetty-ajp-6.1.11.jar/
 - classpathentry kind=lib 
 path=framework/jetty/lib/jetty-sslengine-6.1.11.jar/
 - classpathentry kind=lib 
 path=framework/jetty/lib/jetty-util-6.1.11.jar/
 + classpathentry kind=lib 
 path=framework/jetty/com.sun.el-2.2.0.v20110806.jar/
 + classpathentry kind=lib 
 path=framework/jetty/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-ajp-8.1.2.v20120308.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-continuation-8.1.2.v20120308.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-http-8.1.2.v20120308.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-io-8.1.2.v20120308.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-security-8.1.2.v20120308.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-server-8.1.2.v20120308.jar/
 + classpathentry kind=lib 
 path=framework/jetty/jetty-servlet-8.1.2.v20120308.jar/
 + classpathentry kind=lib

What is the purpose of .jj files?

What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?

Thanks,

Jacopo

Re: What is the purpose of .jj files?

I think they're for Adam's sql component, no idea if that work was ever 
finished.

Regards
Scott

On 23/03/2012, at 8:58 PM, Jacopo Cappellato wrote:

 What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
 JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?
 
 Thanks,
 
 Jacopo

Re: What is the purpose of .jj files?

can we remove them? If we get rid of this we will be able to clean a few things 
(i.e. remove $OFBIZ_HOME/lib/build/javac and a few more tasks)

Jacopo

On Mar 23, 2012, at 9:00 AM, Scott Gray wrote:

 I think they're for Adam's sql component, no idea if that work was ever 
 finished.
 
 Regards
 Scott
 
 On 23/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
 
 What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
 JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?
 
 Thanks,
 
 Jacopo

Re: What is the purpose of .jj files?

My general rule of thumb is that if the application components aren't using it 
then it doesn't belong in the framework.

Regards
Scott

On 23/03/2012, at 9:07 PM, Jacopo Cappellato wrote:

 can we remove them? If we get rid of this we will be able to clean a few 
 things (i.e. remove $OFBIZ_HOME/lib/build/javac and a few more tasks)
 
 Jacopo
 
 On Mar 23, 2012, at 9:00 AM, Scott Gray wrote:
 
 I think they're for Adam's sql component, no idea if that work was ever 
 finished.
 
 Regards
 Scott
 
 On 23/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
 
 What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
 JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?
 
 Thanks,
 
 Jacopo

[jira] [Commented] (OFBIZ-4580) Categories - calculated trails

2012-03-23 Thread Paul Piper (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236456#comment-13236456
 ] 

Paul Piper commented on OFBIZ-4580:
---

Just to clarify: The attached feature is not meant to be run on every request, 
its best use is to generate the trail every so often and store somewhere (a 
lucene/solr tree, entities, cache or so). 

 Categories - calculated trails
 --

 Key: OFBIZ-4580
 URL: https://issues.apache.org/jira/browse/OFBIZ-4580
 Project: OFBiz
  Issue Type: Improvement
Reporter: Paul Piper
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: CategoryWorker-with-trail-export.patch, 
 CategoryWorker.patch, OFBIZ-4580-CategoryWorker-with-trail-export.patch


 Hey folks,
 been a while since I contributed. I noticed that currently ofbiz misses a 
 simple function to generate a category trail. Generating a trail, however, is 
 often useful when generating breadcrums, facetted search results, and proper 
 category trees in general. Hence I created the following as a timesaver:
 {code:title=getCategoryTrail|borderStyle=solid}
 public static  List getCategoryTrail(String productCategoryId,DispatchContext 
 dctx){
   GenericDelegator delegator = (GenericDelegator) 
 dctx.getDelegator();
   ListString trailElements = FastList.newInstance();
 trailElements.add(productCategoryId);
 String parentProductCategoryId = productCategoryId;
 while (UtilValidate.isNotEmpty(parentProductCategoryId)) {
 // find product category rollup
 try {
 ListEntityCondition rolllupConds = FastList.newInstance();
 
 rolllupConds.add(EntityCondition.makeCondition(productCategoryId, 
 parentProductCategoryId));
 rolllupConds.add(EntityUtil.getFilterByDateExpr());
 ListGenericValue productCategoryRollups = 
 delegator.findList(ProductCategoryRollup, 
 EntityCondition.makeCondition(rolllupConds), null, 
 UtilMisc.toList(-fromDate), null, true);
 if (UtilValidate.isNotEmpty(productCategoryRollups)) {
 // add only categories that belong to the top category to 
 trail
 for (GenericValue productCategoryRollup : 
 productCategoryRollups) {
 String trailCategoryId = 
 productCategoryRollup.getString(parentProductCategoryId);
 parentProductCategoryId = trailCategoryId;
 if (trailElements.contains(trailCategoryId)) {
 break;
 }else{
   trailElements.add(trailCategoryId);
 }
 }
 } else {
 parentProductCategoryId = null;
 }
 } catch (GenericEntityException e) {
 Debug.logError(e, Cannot generate trail from product 
 category, module);
 }
 }
 Collections.reverse(trailElements);
 return trailElements;
   }
 {code}
 I suggest to add this to the CategoryWorker.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-4627.
--

Resolution: Fixed

Thanks Tri,

Your patch is in trunk at r1304237

Perfect job, I just had to re-add by hand the line
value xml:lang=viLỗi cơ sở dữ liệu/value
because, 2 hours ago, I improved lines around at 
[r1304206|http://svn.apache.org/viewvc?rev=1304206view=rev] and it did not 
apply. Of course I also improved to 
value xml:lang=viLỗi cơ sở dữ liệu ${errMessage}/value




 contribute Ofbiz Vietnamese tranlasting to community from HaNoi
 ---

 Key: OFBIZ-4627
 URL: https://issues.apache.org/jira/browse/OFBIZ-4627
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Tri Duc Vo
Assignee: Jacques Le Roux
  Labels: features
 Fix For: SVN trunk

 Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, 
 CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 OFBIZ-427_VietnameseCommonUiLabels.patch, 
 OFBIZ-427_VietnameseEcommerceUiLabels.patch, 
 OFBIZ-427_VietnameseMarketingUiLabels.patch, 
 OFBIZ-427_VietnameseOrderEntityLabels.patch, 
 OFBIZ-427_VietnameseOrderUiLabels.patch, 
 OFBIZ-427_VietnameseProductEntityLabels.patch, 
 OFBIZ-427_VietnameseProductUiLabels.patch, 
 OFBIZ-427_VietnameseUiLabels.patch, OFBIZ-427_VietnameseUiLabels.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, 
 OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductUiLabels.xml, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch

   Original Estimate: 1,344h
  Remaining Estimate: 1,344h

Dear Ofbiz community
I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz 
 opensource. 
Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And 
 we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them 
 to community.
We'll attach files soon
Thank you

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236467#comment-13236467
 ] 

Jacques Le Roux commented on OFBIZ-4627:


Ha, also 
ProductCreateNewInventoryItemFacility in th was not closed by /value
I guess it was due to a quirk during patching because you patch is ok for this 
point.

 contribute Ofbiz Vietnamese tranlasting to community from HaNoi
 ---

 Key: OFBIZ-4627
 URL: https://issues.apache.org/jira/browse/OFBIZ-4627
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Tri Duc Vo
Assignee: Jacques Le Roux
  Labels: features
 Fix For: SVN trunk

 Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, 
 CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 OFBIZ-427_VietnameseCommonUiLabels.patch, 
 OFBIZ-427_VietnameseEcommerceUiLabels.patch, 
 OFBIZ-427_VietnameseMarketingUiLabels.patch, 
 OFBIZ-427_VietnameseOrderEntityLabels.patch, 
 OFBIZ-427_VietnameseOrderUiLabels.patch, 
 OFBIZ-427_VietnameseProductEntityLabels.patch, 
 OFBIZ-427_VietnameseProductUiLabels.patch, 
 OFBIZ-427_VietnameseUiLabels.patch, OFBIZ-427_VietnameseUiLabels.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, 
 OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductUiLabels.xml, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch

   Original Estimate: 1,344h
  Remaining Estimate: 1,344h

Dear Ofbiz community
I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz 
 opensource. 
Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And 
 we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them 
 to community.
We'll attach files soon
Thank you

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Stable demo: Address already in use


Not sure why we got this on stable demo

Set OFBIZ_HOME to - /home/ofbiz/branch9
Exception in thread main java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.init(ServerSocket.java:194)
at org.ofbiz.base.start.Start.initListenerThread(Start.java:159)
at org.ofbiz.base.start.Start.init(Start.java:86)
at org.ofbiz.base.start.Start.main(Start.java:398)

Restarted

Jacques

Re: Stable demo: Address already in use


started two times?

On 03/23/2012 04:29 PM, Jacques Le Roux wrote:

Not sure why we got this on stable demo

Set OFBIZ_HOME to - /home/ofbiz/branch9
Exception in thread main java.net.BindException: Address already in use
at java.net.PlainSocketImpl.socketBind(Native Method)
at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
at java.net.ServerSocket.bind(ServerSocket.java:328)
at java.net.ServerSocket.init(ServerSocket.java:194)
at org.ofbiz.base.start.Start.initListenerThread(Start.java:159)
at org.ofbiz.base.start.Start.init(Start.java:86)
at org.ofbiz.base.start.Start.main(Start.java:398)

Restarted

Jacques

[jira] [Commented] (OFBIZ-4580) Categories - calculated trails

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236478#comment-13236478
 ] 

Jacques Le Roux commented on OFBIZ-4580:


Thanks Paul I will add your comment in the method and service. We still want to 
wait for Kiran's answer, right?

 Categories - calculated trails
 --

 Key: OFBIZ-4580
 URL: https://issues.apache.org/jira/browse/OFBIZ-4580
 Project: OFBiz
  Issue Type: Improvement
Reporter: Paul Piper
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: CategoryWorker-with-trail-export.patch, 
 CategoryWorker.patch, OFBIZ-4580-CategoryWorker-with-trail-export.patch


 Hey folks,
 been a while since I contributed. I noticed that currently ofbiz misses a 
 simple function to generate a category trail. Generating a trail, however, is 
 often useful when generating breadcrums, facetted search results, and proper 
 category trees in general. Hence I created the following as a timesaver:
 {code:title=getCategoryTrail|borderStyle=solid}
 public static  List getCategoryTrail(String productCategoryId,DispatchContext 
 dctx){
   GenericDelegator delegator = (GenericDelegator) 
 dctx.getDelegator();
   ListString trailElements = FastList.newInstance();
 trailElements.add(productCategoryId);
 String parentProductCategoryId = productCategoryId;
 while (UtilValidate.isNotEmpty(parentProductCategoryId)) {
 // find product category rollup
 try {
 ListEntityCondition rolllupConds = FastList.newInstance();
 
 rolllupConds.add(EntityCondition.makeCondition(productCategoryId, 
 parentProductCategoryId));
 rolllupConds.add(EntityUtil.getFilterByDateExpr());
 ListGenericValue productCategoryRollups = 
 delegator.findList(ProductCategoryRollup, 
 EntityCondition.makeCondition(rolllupConds), null, 
 UtilMisc.toList(-fromDate), null, true);
 if (UtilValidate.isNotEmpty(productCategoryRollups)) {
 // add only categories that belong to the top category to 
 trail
 for (GenericValue productCategoryRollup : 
 productCategoryRollups) {
 String trailCategoryId = 
 productCategoryRollup.getString(parentProductCategoryId);
 parentProductCategoryId = trailCategoryId;
 if (trailElements.contains(trailCategoryId)) {
 break;
 }else{
   trailElements.add(trailCategoryId);
 }
 }
 } else {
 parentProductCategoryId = null;
 }
 } catch (GenericEntityException e) {
 Debug.logError(e, Cannot generate trail from product 
 category, module);
 }
 }
 Collections.reverse(trailElements);
 return trailElements;
   }
 {code}
 I suggest to add this to the CategoryWorker.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: bin folder for executable files/scripts

2012-03-23 Thread Tri Duc Vo (Issue Comment Edited) (JIRA)

I did progress on this: I was able to move all the scripts to the tools 
folder; I didn't add the bin subfolder to it because the existing files in 
the tools folder are not used and can be removed: in this way we will have a 
tools folder containing all the platform dependent scripts.
But now I need some help from Windows users:

could you please try to create a startofbiz.bat file in the tools folder 
with the following content:
===
echo off
set OFBIZ_HOME=%0\..\..\
echo on
cd /d %OFBIZ_HOME%
%JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
echo off
===

Then you should try to run it from the home folder:

tools\startorfbiz.bat

and from the tools folder:

cd tools
startorfbiz.bat

Both should work fine: I already did this work for the sh files but I couldn't 
test the above mechanism for Windows.

I would really appreciate your feedback.

Thanks,

Jacopo


On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote:

 Well the 'bin' clashing with eclipse default is really a concern
 to being with, the learning curve is yet steep, and with to dos of IDE's as 
 of now,
 everyone is pretty much acquainted. Also in-case we change it to 'bin' in the 
 main folder,
 then there'll be an additional set of documentation required for that to help 
 users on different Operating systems.
 
 Unless we go like opentaps (felt that on a few things) and then one is not 
 really able to use it (Just a comment No offense).
 
 
 tools/bin sounds great, unless that also doesn't call of any other clash or 
 so.
 
 Regards
 Prince
 
 
 
 
 
 From: Mansour Al Akeel mansour.alak...@gmail.com
 To: dev@ofbiz.apache.org 
 Sent: Monday, March 19, 2012 4:13 PM
 Subject: Re: bin folder for executable files/scripts
 
 bin is good enough.
 
 
 On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux
 jacques.le.r...@les7arts.com wrote:
 Hi Jacopo,
 
 tools/bin  sounds good to me
 
 Jacques
 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 
 Thanks everyone for the valuable comments!
 I am trying to finalize this thread: there seems to be consensus to move
 all the executable scripts into a folder to keep things organized.
 For the name of the folder:
 * some of you think that the bin (as I originally suggested) should be
 used because it is often used for this purpose
 * some of you are worried that this could interfere with some commonly
 used IDEs (e.g. Eclipse) that use the bin folder for output and need to be
 configured to use a different standard name
 
 After reviewing what we have now in OFBiz I am wondering if we could use
 the already existing tools folder; its current layout is:
 tools/api-java16
 tools/src
 
 option a: add all the executables to tools/ folder directly
 option b: create a subfolder tools/bin and add all the executables there
 
 What do you think?
 
 Jacopo
 
 On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote:
 
 Then we could recommend to name .bin for instance
 But I wonder if this will not be a source of problem for newbies...
 
 And also for Windows users, bin is not a standard name at all
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
 
 That's fine with me. We just need to update the Eclipse configuration
 files.
 
 -Adrian
 
 On 2/29/2012 3:20 PM, J. Eckard wrote:
 
 I think that eclipse / eclipse users should have to accommodate the
 directory structure of OFBiz, not the other way around.
 
 
 On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote:
 
 Thanks for the feedback! Any suggestion for the name of the folder? I
 was hoping to use a standard name, that is why I initially proposed 
 the
 bin folder... but since that is not an option we will have to think to
 something else (unless we use the existing tools folder but I am not 
 sure
 about the intended usage of that).
 
 Jacopo
 
 
 On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote:
 
 +1
 
 Jacques
 
 From: Adrian Crumadrian.c...@sandglass-software.com
 
 Sounds great, but don't use bin - that folder is created by
 Eclipse and it is in the SVN ignore list.
 
 -Adrian
 
 On 2/27/2012 7:10 PM, Jacopo Cappellato wrote:
 
 The number of executable files (*.sh and *bat) in the OFBiz home
 folder is rather big: what if we create a bin folder and we move 
 all of
 them there? In this way users will have a place where they will find 
 all the
 executable files only and the main folder will be cleaner.
 
 Jacopo

[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi

2012-03-23 Thread Tri Duc Vo (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236485#comment-13236485
 ] 

Tri Duc Vo commented on OFBIZ-4627:
---

Meri Jacques / All
Because of CRLF before /value of TH language keys, then overwrite VI key when 
SVN diff you know. Much and much raised my missing...
Will be easier for you and me if there is better approach
See you next our Vietnamese translation commitment, man
Cheers


 contribute Ofbiz Vietnamese tranlasting to community from HaNoi
 ---

 Key: OFBIZ-4627
 URL: https://issues.apache.org/jira/browse/OFBIZ-4627
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Tri Duc Vo
Assignee: Jacques Le Roux
  Labels: features
 Fix For: SVN trunk

 Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, 
 CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 OFBIZ-427_VietnameseCommonUiLabels.patch, 
 OFBIZ-427_VietnameseEcommerceUiLabels.patch, 
 OFBIZ-427_VietnameseMarketingUiLabels.patch, 
 OFBIZ-427_VietnameseOrderEntityLabels.patch, 
 OFBIZ-427_VietnameseOrderUiLabels.patch, 
 OFBIZ-427_VietnameseProductEntityLabels.patch, 
 OFBIZ-427_VietnameseProductUiLabels.patch, 
 OFBIZ-427_VietnameseUiLabels.patch, OFBIZ-427_VietnameseUiLabels.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, 
 OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductUiLabels.xml, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch

   Original Estimate: 1,344h
  Remaining Estimate: 1,344h

Dear Ofbiz community
I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz 
 opensource. 
Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And 
 we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them 
 to community.
We'll attach files soon
Thank you

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi


[ 
https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236485#comment-13236485
 ] 

Tri Duc Vo edited comment on OFBIZ-4627 at 3/23/12 9:59 AM:


Meri Jacques / All
Because of CRLF before /value of TH language keys, then overwrite VI key when 
SVN diff you know. Much and much raised my missing...
Will be easier for you and me if there is better approach
See you next our Vietnamese translation commitment, man
Merci again becaused of training me
Cheers


  was (Author: djjava):
Meri Jacques / All
Because of CRLF before /value of TH language keys, then overwrite VI key when 
SVN diff you know. Much and much raised my missing...
Will be easier for you and me if there is better approach
See you next our Vietnamese translation commitment, man
Cheers

  
 contribute Ofbiz Vietnamese tranlasting to community from HaNoi
 ---

 Key: OFBIZ-4627
 URL: https://issues.apache.org/jira/browse/OFBIZ-4627
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Tri Duc Vo
Assignee: Jacques Le Roux
  Labels: features
 Fix For: SVN trunk

 Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, 
 CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 OFBIZ-427_VietnameseCommonUiLabels.patch, 
 OFBIZ-427_VietnameseEcommerceUiLabels.patch, 
 OFBIZ-427_VietnameseMarketingUiLabels.patch, 
 OFBIZ-427_VietnameseOrderEntityLabels.patch, 
 OFBIZ-427_VietnameseOrderUiLabels.patch, 
 OFBIZ-427_VietnameseProductEntityLabels.patch, 
 OFBIZ-427_VietnameseProductUiLabels.patch, 
 OFBIZ-427_VietnameseUiLabels.patch, OFBIZ-427_VietnameseUiLabels.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, 
 OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductUiLabels.xml, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch

   Original Estimate: 1,344h
  Remaining Estimate: 1,344h

Dear Ofbiz community
I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz 
 opensource. 
Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And 
 we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them 
 to community.
We'll attach files soon
Thank you

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: bin folder for executable files/scripts

Actually, the /d shouldn't be required:

===
echo off
set OFBIZ_HOME=%0\..\..\
echo on
cd %OFBIZ_HOME%
%JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
echo off
===

Thanks,

Jacopo

On Mar 23, 2012, at 10:57 AM, Jacopo Cappellato wrote:

 I did progress on this: I was able to move all the scripts to the tools 
 folder; I didn't add the bin subfolder to it because the existing files in 
 the tools folder are not used and can be removed: in this way we will have 
 a tools folder containing all the platform dependent scripts.
 But now I need some help from Windows users:
 
 could you please try to create a startofbiz.bat file in the tools folder 
 with the following content:
 ===
 echo off
 set OFBIZ_HOME=%0\..\..\
 echo on
 cd /d %OFBIZ_HOME%
 %JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
 echo off
 ===
 
 Then you should try to run it from the home folder:
 
 tools\startorfbiz.bat
 
 and from the tools folder:
 
 cd tools
 startorfbiz.bat
 
 Both should work fine: I already did this work for the sh files but I 
 couldn't test the above mechanism for Windows.
 
 I would really appreciate your feedback.
 
 Thanks,
 
 Jacopo
 
 
 On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote:
 
 Well the 'bin' clashing with eclipse default is really a concern
 to being with, the learning curve is yet steep, and with to dos of IDE's as 
 of now,
 everyone is pretty much acquainted. Also in-case we change it to 'bin' in 
 the main folder,
 then there'll be an additional set of documentation required for that to 
 help users on different Operating systems.
 
 Unless we go like opentaps (felt that on a few things) and then one is not 
 really able to use it (Just a comment No offense).
 
 
 tools/bin sounds great, unless that also doesn't call of any other clash 
 or so.
 
 Regards
 Prince
 
 
 
 
 
 From: Mansour Al Akeel mansour.alak...@gmail.com
 To: dev@ofbiz.apache.org 
 Sent: Monday, March 19, 2012 4:13 PM
 Subject: Re: bin folder for executable files/scripts
 
 bin is good enough.
 
 
 On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux
 jacques.le.r...@les7arts.com wrote:
 Hi Jacopo,
 
 tools/bin  sounds good to me
 
 Jacques
 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 
 Thanks everyone for the valuable comments!
 I am trying to finalize this thread: there seems to be consensus to move
 all the executable scripts into a folder to keep things organized.
 For the name of the folder:
 * some of you think that the bin (as I originally suggested) should be
 used because it is often used for this purpose
 * some of you are worried that this could interfere with some commonly
 used IDEs (e.g. Eclipse) that use the bin folder for output and need to be
 configured to use a different standard name
 
 After reviewing what we have now in OFBiz I am wondering if we could use
 the already existing tools folder; its current layout is:
 tools/api-java16
 tools/src
 
 option a: add all the executables to tools/ folder directly
 option b: create a subfolder tools/bin and add all the executables there
 
 What do you think?
 
 Jacopo
 
 On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote:
 
 Then we could recommend to name .bin for instance
 But I wonder if this will not be a source of problem for newbies...
 
 And also for Windows users, bin is not a standard name at all
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
 
 That's fine with me. We just need to update the Eclipse configuration
 files.
 
 -Adrian
 
 On 2/29/2012 3:20 PM, J. Eckard wrote:
 
 I think that eclipse / eclipse users should have to accommodate the
 directory structure of OFBiz, not the other way around.
 
 
 On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote:
 
 Thanks for the feedback! Any suggestion for the name of the folder? I
 was hoping to use a standard name, that is why I initially proposed 
 the
 bin folder... but since that is not an option we will have to think 
 to
 something else (unless we use the existing tools folder but I am not 
 sure
 about the intended usage of that).
 
 Jacopo
 
 
 On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote:
 
 +1
 
 Jacques
 
 From: Adrian Crumadrian.c...@sandglass-software.com
 
 Sounds great, but don't use bin - that folder is created by
 Eclipse and it is in the SVN ignore list.
 
 -Adrian
 
 On 2/27/2012 7:10 PM, Jacopo Cappellato wrote:
 
 The number of executable files (*.sh and *bat) in the OFBiz home
 folder is rather big: what if we create a bin folder and we move 
 all of
 them there? In this way users will have a place where they will 
 find all the
 executable files only and the main folder will be cleaner.
 
 Jacopo

Re: Some ideas to prepare our first community roadmap

I'm in favor of all of those things so +1 from me.

For a JIRA version, how about 13.04? :-)

One other topic that's been on my mind, payment gateway implementations:
- Move the test implementation into it's own class so that it isn't 
overcrowding PaymentGatewayServices and is consistent with the others
- Refactor the test implementation so that you can use the CVV code to test 
different behaviors instead of having a bunch of different methods like 
alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
- Ensure consistency between the implementations and better document the 
gateway interfaces.  Also remove virtually all database calls from the 
implementations (they run in their own transaction which can be painful when 
querying new data).
- After cleaning them up, consider moving some of the implementations to 
Extras, I would prefer all of them except test but we could start with some of 
the more obscure ones at least

Oh and another one on my wish list:
- Finish the query builder implementation that I started a year or two ago and 
deprecate the bulk of the delegator find methods.

Regards
Scott

On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:

 Hi all,
 
 now that the great community discussion about the Lose Weight Program for 
 OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm 
 and participation) we can start to wrap up a roadmap (it would be nice to set 
 it up in Jira, using a specific Jira version so that we can keep track of 
 progress together... any ideas for a good name for it?) by listing the 
 actionable items and also by considering other topics that may be of interest 
 to the community.
 This thread is an attempt to integrate the roadmap with some additional tasks 
 if the community will consider them a priority.
 
 But first of all, here is the list with a categorization/summary of the tasks 
 being discussed so far:
 
 (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we 
 will create tasks in Jira for each):
 * setup a nice page in the OFBiz website to describe the OFBiz Extras 
 ecosystem (external project names will be added there); the OFBiz PMC will 
 have to work on this (also check if there is additional paperwork to do)
 * move some of the component/code to Extras: we will create individual Jira 
 tasks for each component and then design details (how to move) will be 
 discussed in the task; we will need volunteers (committers and not) to 
 contribute patches/commits and also at least one maintainer (OFBiz committer 
 or not) for each component
 * move some of the component/code to Attic: we will create individual Jira 
 tasks for each removal and then design details (how to remove) will be 
 discussed in the tasks; we will need volunteers (committers and not) to 
 contribute patches/commits
 
 The above will form the first part of the roadmap.
 
 
 
 The following list is simply my personal attempt to propose some priorities 
 for the community; some of them are based on comments from people on the dev 
 list, some of them are personal ideas based on some reviews I did to the 
 OFBiz codebase.
 Feel free to add/remove items to the list but please while doing this 
 consider that we are discussing candidate tasks for an OFBiz roadmap shared 
 by the community: when the list will be discussed, approved and finalized the 
 community will have a clear roadmap to focus on (with all 
 contributions/commits going in this direction); but this also means that the 
 tasks/goals need to be enough generic to gather consensus on a larger group 
 of people (otherwise each individual committer will end up proposing her own 
 specific item to the list, of less interest to the community, and then she 
 will start working on it... instead of better spending the time that she 
 decided to contribute to tasks that the community really considers 
 important) and they shouldn't be too big (gathering consensus and 
 implementing as a community will take a lot of time). If we will not find an 
 agreement on some items or a large consensus then it will be fine: the 
 roadmap will be lighter and will be completed earlier; at that point we will 
 discuss again what we want to do next.
 Even if no big tasks will be added to the roadmap, I think it will still be 
 an interesting one focused on maintenance and quality.
 
 BIG TASKS (these are potentially big tasks that may be difficult to plan in 
 this first roadmap... but it may make sense to try to see if we can find an 
 agreement for some actionable tasks)
 * resolving framework dependencies on applications (this is *not* about 
 refactoring the framework, simply to resolve its dependencies on 
 applications)
 * gather requirements (from existing applications), design and implement 
 JCR/Jackrabbit and replace parts of the existing Content Framework with it
 * discuss, design and implement (if needed) or define best practices for a 
 plug in architecture
 * discuss, design and implement

[jira] [Commented] (OFBIZ-4627) contribute Ofbiz Vietnamese tranlasting to community from HaNoi

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236492#comment-13236492
 ] 

Jacques Le Roux commented on OFBIZ-4627:


The easier for you would be to change/edit the labels files in Eclipse and then 
to create the patch from root. But I guess you need to introduce the .po (using 
an external editor? why?), and there I can't help you.

 contribute Ofbiz Vietnamese tranlasting to community from HaNoi
 ---

 Key: OFBIZ-4627
 URL: https://issues.apache.org/jira/browse/OFBIZ-4627
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: SVN trunk
Reporter: Tri Duc Vo
Assignee: Jacques Le Roux
  Labels: features
 Fix For: SVN trunk

 Attachments: CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, 
 CommonUiLabels.xml.patch, CommonUiLabels.xml.patch, EcommerceUiLabels.xml, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 EcommerceUiLabels.xml.patch, EcommerceUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 MarketingUiLabels.xml.patch, MarketingUiLabels.xml.patch, 
 OFBIZ-427_VietnameseCommonUiLabels.patch, 
 OFBIZ-427_VietnameseEcommerceUiLabels.patch, 
 OFBIZ-427_VietnameseMarketingUiLabels.patch, 
 OFBIZ-427_VietnameseOrderEntityLabels.patch, 
 OFBIZ-427_VietnameseOrderUiLabels.patch, 
 OFBIZ-427_VietnameseProductEntityLabels.patch, 
 OFBIZ-427_VietnameseProductUiLabels.patch, 
 OFBIZ-427_VietnameseUiLabels.patch, OFBIZ-427_VietnameseUiLabels.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderEntityLabels.xml.patch, OrderEntityLabels.xml.patch, 
 OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, OrderUiLabels.xml.patch, 
 OrderUiLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductEntityLabels.xml.patch, 
 ProductEntityLabels.xml.patch, ProductUiLabels.xml, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch, 
 ProductUiLabels.xml.patch, ProductUiLabels.xml.patch

   Original Estimate: 1,344h
  Remaining Estimate: 1,344h

Dear Ofbiz community
I'm Tri, from HaNoi, VietNam, and now our team build ERP based on Ofbiz 
 opensource. 
Now we're completed translating 80% Ecommerce , 50% Catalog of Ofbiz. And 
 we're going to complete 100% Vietnamese Ofbiz tranlasting and contribute them 
 to community.
We'll attach files soon
Thank you

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Some ideas to prepare our first community roadmap

2012-03-23 Thread Pierre Smits

Hi Jacopo,

This is a sound approach, so a +1 from me. Specifically on using JIRA for
this. It will help keeping focus. If the set of actions is to big to
completed in a reasonable time frame, it might be wise to split it over
multiple releases (All great works of art weren't there over night).

I would like to propose to cancel the 12.04 release, so that this roadmap
will lead to the new release and keep the old ones open for bug fixing
only. For the next release I wouldn't use 13 as well, given that might be
people having some superstition about this.

Regards,

Pierre

Op 22 maart 2012 12:06 schreef Jacopo Cappellato 
jacopo.cappell...@hotwaxmedia.com het volgende:

 Hi all,

 now that the great community discussion about the Lose Weight Program
 for OFBiz is settling down (thanks to all of you for the great ideas,
 enthusiasm and participation) we can start to wrap up a roadmap (it would
 be nice to set it up in Jira, using a specific Jira version so that we
 can keep track of progress together... any ideas for a good name for it?)
 by listing the actionable items and also by considering other topics that
 may be of interest to the community.
 This thread is an attempt to integrate the roadmap with some additional
 tasks if the community will consider them a priority.

 But first of all, here is the list with a categorization/summary of the
 tasks being discussed so far:

 (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we
 will create tasks in Jira for each):
 * setup a nice page in the OFBiz website to describe the OFBiz Extras
 ecosystem (external project names will be added there); the OFBiz PMC will
 have to work on this (also check if there is additional paperwork to do)
 * move some of the component/code to Extras: we will create individual
 Jira tasks for each component and then design details (how to move) will be
 discussed in the task; we will need volunteers (committers and not) to
 contribute patches/commits and also at least one maintainer (OFBiz
 committer or not) for each component
 * move some of the component/code to Attic: we will create individual Jira
 tasks for each removal and then design details (how to remove) will be
 discussed in the tasks; we will need volunteers (committers and not) to
 contribute patches/commits

 The above will form the first part of the roadmap.

 

 The following list is simply my personal attempt to propose some
 priorities for the community; some of them are based on comments from
 people on the dev list, some of them are personal ideas based on some
 reviews I did to the OFBiz codebase.
 Feel free to add/remove items to the list but please while doing this
 consider that we are discussing candidate tasks for an OFBiz roadmap shared
 by the community: when the list will be discussed, approved and finalized
 the community will have a clear roadmap to focus on (with all
 contributions/commits going in this direction); but this also means that
 the tasks/goals need to be enough generic to gather consensus on a larger
 group of people (otherwise each individual committer will end up proposing
 her own specific item to the list, of less interest to the community, and
 then she will start working on it... instead of better spending the time
 that she decided to contribute to tasks that the community really
 considers important) and they shouldn't be too big (gathering consensus and
 implementing as a community will take a lot of time). If we will not find
 an agreement on some items or a large consensus then it will be fine: the
 roadmap will be lighter and will be completed earlier; at that point we
 will discuss again what we want to do next.
 Even if no big tasks will be added to the roadmap, I think it will still
 be an interesting one focused on maintenance and quality.

 BIG TASKS (these are potentially big tasks that may be difficult to plan
 in this first roadmap... but it may make sense to try to see if we can find
 an agreement for some actionable tasks)
 * resolving framework dependencies on applications (this is *not* about
 refactoring the framework, simply to resolve its dependencies on
 applications)
 * gather requirements (from existing applications), design and implement
 JCR/Jackrabbit and replace parts of the existing Content Framework with it
 * discuss, design and implement (if needed) or define best practices for a
 plug in architecture
 * discuss, design and implement (if needed) or define best practices for
 an integrated reporting tool for OFBiz

 MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that
 should be easy to include in the roadmap because they don't require big
 design and discussions and are mostly all actionable)
 * bug fixes
 * automated tests
 * migration from Beanshell to Groovy (i.e. continue in the trunk the work
 started in the branch)
 * check proper handling of EntityListIterators
 * check proper handling of errors and exceptions in services, events,
 scripts
 * check

Re: bin folder for executable files/scripts

2012-03-23 Thread Jose F. Fernandez

Hi Jacopo!

your script works, but I think that more correct one will be:
===
echo off
%~d0
set OFBIZ_HOME=%~p0..\
echo on
cd %OFBIZ_HOME%
%JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
echo off
===

wich produces:

D:\Java\workspace2\ofbiztools\startofbiz.bat
D:\Java\workspace2\ofbizecho off
D:\Java\workspace2\ofbizcd \Java\workspace2\ofbiz\tools\..\
D:\Java\workspace2\ofbizREM D:\Java\jdk1.6.0_29_i586\bin\java -Xms128M 
-Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
D:\Java\workspace2\ofbizecho off

and

D:\Java\workspace2\ofbiz\toolsstartofbiz.bat
D:\Java\workspace2\ofbiz\toolsecho off
D:\Java\workspace2\ofbiz\toolscd \Java\workspace2\ofbiz\tools\..\
D:\Java\workspace2\ofbizREM D:\Java\jdk1.6.0_29_i586\bin\java -Xms128M 
-Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
D:\Java\workspace2\ofbizecho off

With yours, the cd command is pretty ugly (note the filename inline) even it 
works (not from another drive letter):

D:\Java\workspace2\ofbiztools\startofbiz.bat
D:\Java\workspace2\ofbizecho off
D:\Java\workspace2\ofbizcd tools\startofbiz.bat\..\..\
D:\Java\workspace2\ofbizREM D:\Java\jdk1.6.0_29_i586\bin\java -Xms128M 
-Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
D:\Java\workspace2\ofbizecho off

Thats because %0 returns the script name but %~p0 returns the path portion of 
the command.
Also note that I added one more line:
%~d0

That is to ensure that it will work if called from a diferent drive letter 
(nothing to do on Linux):

C:\Windows\System32D:\Java\workspace2\ofbiz\tools\startofbiz.bat
C:\Windows\System32echo off
D:\Java\workspace2\ofbizcd \Java\workspace2\ofbiz\tools\..\
D:\Java\workspace2\ofbizREM D:\Java\jdk1.6.0_29_i586\bin\java -Xms128M 
-Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
D:\Java\workspace2\ofbizecho off

Someone else could test and report?

ThankU!!

Jose F.



- Mensaje original - 

 De: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 Para: dev@ofbiz.apache.org
 Enviados: Viernes, 23 de Marzo 2012 11:02:16
 Asunto: Re: bin folder for executable files/scripts

 Actually, the /d shouldn't be required:

 ===
 echo off
 set OFBIZ_HOME=%0\..\..\
 echo on
 cd %OFBIZ_HOME%
 %JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar
 ofbiz.jar
 echo off
 ===

 Thanks,

 Jacopo

 On Mar 23, 2012, at 10:57 AM, Jacopo Cappellato wrote:

  I did progress on this: I was able to move all the scripts to the
  tools folder; I didn't add the bin subfolder to it because the
  existing files in the tools folder are not used and can be
  removed: in this way we will have a tools folder containing all
  the platform dependent scripts.
  But now I need some help from Windows users:
 
  could you please try to create a startofbiz.bat file in the
  tools folder with the following content:
  ===
  echo off
  set OFBIZ_HOME=%0\..\..\
  echo on
  cd /d %OFBIZ_HOME%
  %JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar
  ofbiz.jar
  echo off
  ===
 
  Then you should try to run it from the home folder:
 
  tools\startorfbiz.bat
 
  and from the tools folder:
 
  cd tools
  startorfbiz.bat
 
  Both should work fine: I already did this work for the sh files but
  I couldn't test the above mechanism for Windows.
 
  I would really appreciate your feedback.
 
  Thanks,
 
  Jacopo
 
 
  On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote:
 
  Well the 'bin' clashing with eclipse default is really a concern
  to being with, the learning curve is yet steep, and with to dos of
  IDE's as of now,
  everyone is pretty much acquainted. Also in-case we change it to
  'bin' in the main folder,
  then there'll be an additional set of documentation required for
  that to help users on different Operating systems.
 
  Unless we go like opentaps (felt that on a few things) and then
  one is not really able to use it (Just a comment No offense).
 
 
  tools/bin sounds great, unless that also doesn't call of any
  other clash or so.
 
  Regards
  Prince
 
 
 
 
  
  From: Mansour Al Akeel mansour.alak...@gmail.com
  To: dev@ofbiz.apache.org
  Sent: Monday, March 19, 2012 4:13 PM
  Subject: Re: bin folder for executable files/scripts
 
  bin is good enough.
 
 
  On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux
  jacques.le.r...@les7arts.com wrote:
  Hi Jacopo,
 
  tools/bin sounds good to me
 
  Jacques
 
  From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 
  Thanks everyone for the valuable comments!
  I am trying to finalize this thread: there seems to be consensus
  to move
  all the executable scripts into a folder to keep things
  organized.
  For the name of the folder:
  * some of you think that the bin (as I originally suggested)
  should be
  used because it is often used for

Re: bin folder for executable files/scripts

Hi Jacopo,

Although I'm not a windows user but yes it works fine from the tools folder on 
windows. 


Regards
Prince




 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
To: dev@ofbiz.apache.org 
Sent: Friday, March 23, 2012 3:32 PM
Subject: Re: bin folder for executable files/scripts
 
Actually, the /d shouldn't be required:

===
echo off
set OFBIZ_HOME=%0\..\..\
echo on
cd %OFBIZ_HOME%
%JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
echo off
===

Thanks,

Jacopo

On Mar 23, 2012, at 10:57 AM, Jacopo Cappellato wrote:

 I did progress on this: I was able to move all the scripts to the tools 
 folder; I didn't add the bin subfolder to it because the existing files in 
 the tools folder are not used and can be removed: in this way we will have 
 a tools folder containing all the platform dependent scripts.
 But now I need some help from Windows users:
 
 could you please try to create a startofbiz.bat file in the tools folder 
 with the following content:
 ===
 echo off
 set OFBIZ_HOME=%0\..\..\
 echo on
 cd /d %OFBIZ_HOME%
 %JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
 echo off
 ===
 
 Then you should try to run it from the home folder:
 
 tools\startorfbiz.bat
 
 and from the tools folder:
 
 cd tools
 startorfbiz.bat
 
 Both should work fine: I already did this work for the sh files but I 
 couldn't test the above mechanism for Windows.
 
 I would really appreciate your feedback.
 
 Thanks,
 
 Jacopo
 
 
 On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote:
 
 Well the 'bin' clashing with eclipse default is really a concern
 to being with, the learning curve is yet steep, and with to dos of IDE's as 
 of now,
 everyone is pretty much acquainted. Also in-case we change it to 'bin' in 
 the main folder,
 then there'll be an additional set of documentation required for that to 
 help users on different Operating systems.
 
 Unless we go like opentaps (felt that on a few things) and then one is not 
 really able to use it (Just a comment No offense).
 
 
 tools/bin sounds great, unless that also doesn't call of any other clash 
 or so.
 
 Regards
 Prince
 
 
 
 
 
 From: Mansour Al Akeel mansour.alak...@gmail.com
 To: dev@ofbiz.apache.org 
 Sent: Monday, March 19, 2012 4:13 PM
 Subject: Re: bin folder for executable files/scripts
 
 bin is good enough.
 
 
 On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux
 jacques.le.r...@les7arts.com wrote:
 Hi Jacopo,
 
 tools/bin  sounds good to me
 
 Jacques
 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 
 Thanks everyone for the valuable comments!
 I am trying to finalize this thread: there seems to be consensus to move
 all the executable scripts into a folder to keep things organized.
 For the name of the folder:
 * some of you think that the bin (as I originally suggested) should be
 used because it is often used for this purpose
 * some of you are worried that this could interfere with some commonly
 used IDEs (e.g. Eclipse) that use the bin folder for output and need to be
 configured to use a different standard name
 
 After reviewing what we have now in OFBiz I am wondering if we could use
 the already existing tools folder; its current layout is:
 tools/api-java16
 tools/src
 
 option a: add all the executables to tools/ folder directly
 option b: create a subfolder tools/bin and add all the executables there
 
 What do you think?
 
 Jacopo
 
 On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote:
 
 Then we could recommend to name .bin for instance
 But I wonder if this will not be a source of problem for newbies...
 
 And also for Windows users, bin is not a standard name at all
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
 
 That's fine with me. We just need to update the Eclipse configuration
 files.
 
 -Adrian
 
 On 2/29/2012 3:20 PM, J. Eckard wrote:
 
 I think that eclipse / eclipse users should have to accommodate the
 directory structure of OFBiz, not the other way around.
 
 
 On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote:
 
 Thanks for the feedback! Any suggestion for the name of the folder? I
 was hoping to use a standard name, that is why I initially proposed 
 the
 bin folder... but since that is not an option we will have to think 
 to
 something else (unless we use the existing tools folder but I am not 
 sure
 about the intended usage of that).
 
 Jacopo
 
 
 On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote:
 
 +1
 
 Jacques
 
 From: Adrian Crumadrian.c...@sandglass-software.com
 
 Sounds great, but don't use bin - that folder is created by
 Eclipse and it is in the SVN ignore list.
 
 -Adrian
 
 On 2/27/2012 7:10 PM, Jacopo Cappellato wrote:
 
 The number of executable files (*.sh and *bat) in the OFBiz home
 folder

Re: Some ideas to prepare our first community roadmap

2012-03-23 Thread Nicolas Malin


+1 a greate roadmap with lot of works

On refactoring idea :
 * review/improve best pratice screen (to manage icons, strong table 
line, ...), I had started on this subject but not finalize.


Nicolas

Le 23/03/2012 11:07, Scott Gray a écrit :

I'm in favor of all of those things so +1 from me.

For a JIRA version, how about 13.04? :-)

One other topic that's been on my mind, payment gateway implementations:
- Move the test implementation into it's own class so that it isn't 
overcrowding PaymentGatewayServices and is consistent with the others
- Refactor the test implementation so that you can use the CVV code to test 
different behaviors instead of having a bunch of different methods like 
alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
- Ensure consistency between the implementations and better document the 
gateway interfaces.  Also remove virtually all database calls from the 
implementations (they run in their own transaction which can be painful when 
querying new data).
- After cleaning them up, consider moving some of the implementations to 
Extras, I would prefer all of them except test but we could start with some of 
the more obscure ones at least

Oh and another one on my wish list:
- Finish the query builder implementation that I started a year or two ago and 
deprecate the bulk of the delegator find methods.

Regards
Scott

On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:


Hi all,

now that the great community discussion about the Lose Weight Program for OFBiz is 
settling down (thanks to all of you for the great ideas, enthusiasm and participation) we can start 
to wrap up a roadmap (it would be nice to set it up in Jira, using a specific Jira 
version so that we can keep track of progress together... any ideas for a good name for it?) 
by listing the actionable items and also by considering other topics that may be of interest to the 
community.
This thread is an attempt to integrate the roadmap with some additional tasks 
if the community will consider them a priority.

But first of all, here is the list with a categorization/summary of the tasks 
being discussed so far:

(MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will 
create tasks in Jira for each):
* setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem 
(external project names will be added there); the OFBiz PMC will have to work 
on this (also check if there is additional paperwork to do)
* move some of the component/code to Extras: we will create individual Jira 
tasks for each component and then design details (how to move) will be 
discussed in the task; we will need volunteers (committers and not) to 
contribute patches/commits and also at least one maintainer (OFBiz committer or 
not) for each component
* move some of the component/code to Attic: we will create individual Jira 
tasks for each removal and then design details (how to remove) will be 
discussed in the tasks; we will need volunteers (committers and not) to 
contribute patches/commits

The above will form the first part of the roadmap.



The following list is simply my personal attempt to propose some priorities for 
the community; some of them are based on comments from people on the dev list, 
some of them are personal ideas based on some reviews I did to the OFBiz 
codebase.
Feel free to add/remove items to the list but please while doing this consider that we 
are discussing candidate tasks for an OFBiz roadmap shared by the community: when the 
list will be discussed, approved and finalized the community will have a clear roadmap to 
focus on (with all contributions/commits going in this direction); but this also means 
that the tasks/goals need to be enough generic to gather consensus on a larger group of 
people (otherwise each individual committer will end up proposing her own specific item 
to the list, of less interest to the community, and then she will start working on it... 
instead of better spending the time that she decided to contribute to tasks 
that the community really considers important) and they shouldn't be too big (gathering 
consensus and implementing as a community will take a lot of time). If we will not find 
an agreement on some items or a large consensus then it will be fine: the roadmap will be 
lighter and will be completed earlier; at that point we will discuss again what we want 
to do next.
Even if no big tasks will be added to the roadmap, I think it will still be an interesting one 
focused on maintenance and quality.

BIG TASKS (these are potentially big tasks that may be difficult to plan in 
this first roadmap... but it may make sense to try to see if we can find an 
agreement for some actionable tasks)
* resolving framework dependencies on applications (this is *not* about 
refactoring the framework, simply to resolve its dependencies on applications)
* gather requirements (from existing applications), design and implement 
JCR/Jackrabbit and replace

Re: What is the purpose of .jj files?

Scott you are right. But the components wont compile without them.
I recommend, refactor the components first, then we can tell what is
needed and what is not.

For example, base and start wont compile separately. Either move the
classes that are needed by base to base, or merge them for now, until
we know for sure what is needed by other component.

I mean by wont compile separately, is you can not compile base as a
component, then included in the classpath while compiling start
Same thing applies to start.



On Fri, Mar 23, 2012 at 4:33 AM, Scott Gray scott.g...@hotwaxmedia.com wrote:
 My general rule of thumb is that if the application components aren't using 
 it then it doesn't belong in the framework.

 Regards
 Scott

 On 23/03/2012, at 9:07 PM, Jacopo Cappellato wrote:

 can we remove them? If we get rid of this we will be able to clean a few 
 things (i.e. remove $OFBIZ_HOME/lib/build/javac and a few more tasks)

 Jacopo

 On Mar 23, 2012, at 9:00 AM, Scott Gray wrote:

 I think they're for Adam's sql component, no idea if that work was ever 
 finished.

 Regards
 Scott

 On 23/03/2012, at 8:58 PM, Jacopo Cappellato wrote:

 What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
 JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?

 Thanks,

 Jacopo

Re: What is the purpose of .jj files?

Hi Mansour,

I was talking more about framework features that go unused, you're talking 
about parts of the framework that are fundamental to the framework itself.

For example my understanding of the sql component was that it would allow SQL 
queries against the delegator e.g. SQL - Delegator - SQL to database.  I 
don't know if it was ever finished and I don't know if anyone knows how to use 
it, it certainly isn't used anywhere in the applications.  Even if it were 
finished, I don't know that it needs to be in the framework but then it 
probably doesn't help that I don't really understand its purpose.

Regards
Scott

On 23/03/2012, at 11:59 PM, Mansour Al Akeel wrote:

 Scott you are right. But the components wont compile without them.
 I recommend, refactor the components first, then we can tell what is
 needed and what is not.
 
 For example, base and start wont compile separately. Either move the
 classes that are needed by base to base, or merge them for now, until
 we know for sure what is needed by other component.
 
 I mean by wont compile separately, is you can not compile base as a
 component, then included in the classpath while compiling start
 Same thing applies to start.
 
 
 
 On Fri, Mar 23, 2012 at 4:33 AM, Scott Gray scott.g...@hotwaxmedia.com 
 wrote:
 My general rule of thumb is that if the application components aren't using 
 it then it doesn't belong in the framework.
 
 Regards
 Scott
 
 On 23/03/2012, at 9:07 PM, Jacopo Cappellato wrote:
 
 can we remove them? If we get rid of this we will be able to clean a few 
 things (i.e. remove $OFBIZ_HOME/lib/build/javac and a few more tasks)
 
 Jacopo
 
 On Mar 23, 2012, at 9:00 AM, Scott Gray wrote:
 
 I think they're for Adam's sql component, no idea if that work was ever 
 finished.
 
 Regards
 Scott
 
 On 23/03/2012, at 8:58 PM, Jacopo Cappellato wrote:
 
 What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
 JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?
 
 Thanks,
 
 Jacopo

Re: What is the purpose of .jj files?

Scott,

thank you for the clarification.


On Fri, Mar 23, 2012 at 7:07 AM, Scott Gray scott.g...@hotwaxmedia.com wrote:
 Hi Mansour,

 I was talking more about framework features that go unused, you're talking 
 about parts of the framework that are fundamental to the framework itself.

 For example my understanding of the sql component was that it would allow SQL 
 queries against the delegator e.g. SQL - Delegator - SQL to database.  I 
 don't know if it was ever finished and I don't know if anyone knows how to 
 use it, it certainly isn't used anywhere in the applications.  Even if it 
 were finished, I don't know that it needs to be in the framework but then it 
 probably doesn't help that I don't really understand its purpose.

 Regards
 Scott

 On 23/03/2012, at 11:59 PM, Mansour Al Akeel wrote:

 Scott you are right. But the components wont compile without them.
 I recommend, refactor the components first, then we can tell what is
 needed and what is not.

 For example, base and start wont compile separately. Either move the
 classes that are needed by base to base, or merge them for now, until
 we know for sure what is needed by other component.

 I mean by wont compile separately, is you can not compile base as a
 component, then included in the classpath while compiling start
 Same thing applies to start.



 On Fri, Mar 23, 2012 at 4:33 AM, Scott Gray scott.g...@hotwaxmedia.com 
 wrote:
 My general rule of thumb is that if the application components aren't using 
 it then it doesn't belong in the framework.

 Regards
 Scott

 On 23/03/2012, at 9:07 PM, Jacopo Cappellato wrote:

 can we remove them? If we get rid of this we will be able to clean a few 
 things (i.e. remove $OFBIZ_HOME/lib/build/javac and a few more tasks)

 Jacopo

 On Mar 23, 2012, at 9:00 AM, Scott Gray wrote:

 I think they're for Adam's sql component, no idea if that work was ever 
 finished.

 Regards
 Scott

 On 23/03/2012, at 8:58 PM, Jacopo Cappellato wrote:

 What is the purpose of the two .jj files we have in OFBiz (Parser.jj and 
 JSON.jj) and the associated ant tasks ofbiz-javacc and ofbiz-jjtree?

 Thanks,

 Jacopo

Re: Lose Weight Program for OFBiz - Birt and BI

in the config for base:

base/config/ofbiz-containers.xml:!-- load the BIRT container --
base/config/ofbiz-containers.xml:container name=birt-container
class=org.ofbiz.birt.container.BirtContainer/


This is what loads Birt. Not sure if there's something else needed to load it.
Can this be temporary used until OSGI is introduced. OSGI makes it
easy to load and unload any component. So (if done properly), no
integration in the framework should be done. In this case Birt
component should contain the logic to load its self when deployed into
OSGI container. So those who needs it can just install it with one
command.

In the mean while, cleaning the code base will make it easier to look
into the messy code in framework, and remove what is not needed. Which
will help bringing new things like OSGI to the table.


On Thu, Mar 22, 2012 at 7:58 PM, Anne a...@cohsoft.com.au wrote:
 +1 to Mansour's comments.

 I don't use Birt. I use JasperReports (GPL/LGPL). With JasperReports and
 Groovy I currently

 2. can use ofbiz fieldnames and entity names. (not databasenames)
 3. can use OFBiz views.
 4. can fully integrate in the ERP application.
 5. has many inbuilt output formats.

 (points are from Hans earlier email, though maybe my idea of fully
 integrate isn't the same as Hans). I presume I can also incorporate the
 warehouse entities, and use minilang (Hans' other two points), though I
 haven't yet tried either. Maybe it is easier to do these things with Birt,
 but I don't have any difficulty with JasperReports.

 More importantly to me, if I decide to drop JasperReports and move to
 something else later, it won't be very difficult.

 I am sure Hans integration of Birt would be very useful for those who use
 Birt, and I expect they appreciate his effort. If Birt was in Extras,
 perhaps some of those people would be more likely to contribute to its
 maintenance.

 Cheers,
 Anne.

 On 23 March 2012 01:37, Mansour Al Akeel mansour.alak...@gmail.com wrote:

 I don't know why birt is integrated with Ofbiz. A reporting tools, is
 an add-on to any database driven system, and not essential for the
 over all functionality. Yes all of us need reports, and most of the
 time we use a reporting engine, but why can't it be separated from the
 code base, and used as a separate application ?

 From my perspective, the core should contain only components needed to
 bring it up to a functional state. Entity Engine, Service Engine, fall
 under this category. Some may argue that UI should be considered as
 well, and this is valid argument. But when it comes to reporting
 engine, I don't think so.



 On Thu, Mar 22, 2012 at 7:43 AM, Erwan de FERRIERES
 erwan.de-ferrie...@nereide.fr wrote:
  Le 22/03/2012 02:38, Hans Bakker a écrit :
 
  Jacopo,
 
  you are making here a very negative review of the Birt integrationas
  any component sure there is room for improvement however
 
  Some positives you did not even notice?
 
  1. can use minilanguage for the retrieval
  2. can use ofbiz fieldnames and entity names. (not databasenames)
  3. can use OFBiz views.
  4. can fully integrate in the ERP application.
  5. has many inbuilt output formats.
  6. Incorporates the warehouse entities.
 
  Created/extended the datawarehouse which is essential for ordereporting.
  We have very big customers where using order reports directly on the
  OFBiz database was not possible.
 
  This warehouse function is essential for large customers
 
  I very strongly think about keeping this in the framework.
 
  BI component I agree, can go
 
  Regards,
  Hans
 
 
 
  I'm in two minds about BIRT. It's a fine tool to make reports, but
 underused
  in OFBiz.
  If the concerns Jacopo has about it were resolved, will it be kept in
  framework ?
  Also, creating more of those reports (with not available features in
 FOP),
  will this go in the right way to keep it there ?
 
 
  --
  Erwan de FERRIERES
  www.nereide.biz




 --
 Coherent Software Australia Pty Ltd
 PO Box 2773
 Cheltenham Vic 3192
 Phone: (03) 9585 6788
 Fax: (03) 9585 1086
 Web: http://www.cohsoft.com.au/
 Email: sa...@cohsoft.com.au

 Bonsai ERP, the all-inclusive ERP system
 http://www.bonsaierp.com.au/

Re: Some ideas to prepare our first community roadmap



+1 to the Refractor, Have a few questions and a few suggestions :
Questions : 


Are we looking to improve upon the ORM as well ?

And what about the OSGI stuff, are we planning something on that to enhance the 
plug-in approach?

What's all about the extra stuff? are we just gonna keep 'em separately and 
maintain 'em separately or are we
really commercializing? 

Also, What all is that we're thinking to add on to the existing application or 
are we just looking to reduce/resize and enhance what all
is there?


Suggestions :

Google Base Component : Google has upgraded to Google Content API long back so 
the one in 10.04 no more works to upload products to Google merchant
haven't checked 11.04 yet.

eBay and eBay Store could be merged together and there's also no functionality 
to post variants to eBay, I wrote some custom code as

part of a POC for that, also customer grievances from eBay is something that's 
missing.

Integration with Amazon using Amazon MWS will be cool.

Upgrade for Fedex API as they're retiring the SOAP API that is currently used, 
on 31st may 2012.

Also I'm ready to volunteer any component at any level, be it a committer or 
not.
I'm very much excited about the massive change that we're about to bring as a 
community to 

the application.

Regards
Prince





 From: Nicolas Malin malin.nico...@librenberry.net
To: dev@ofbiz.apache.org 
Sent: Friday, March 23, 2012 4:21 PM
Subject: Re: Some ideas to prepare our first community roadmap
 
+1 a greate roadmap with lot of works

On refactoring idea :
  * review/improve best pratice screen (to manage icons, strong table 
line, ...), I had started on this subject but not finalize.

Nicolas

Le 23/03/2012 11:07, Scott Gray a écrit :
 I'm in favor of all of those things so +1 from me.

 For a JIRA version, how about 13.04? :-)

 One other topic that's been on my mind, payment gateway implementations:
 - Move the test implementation into it's own class so that it isn't 
 overcrowding PaymentGatewayServices and is consistent with the others
 - Refactor the test implementation so that you can use the CVV code to test 
 different behaviors instead of having a bunch of different methods like 
 alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
 - Ensure consistency between the implementations and better document the 
 gateway interfaces.  Also remove virtually all database calls from the 
 implementations (they run in their own transaction which can be painful when 
 querying new data).
 - After cleaning them up, consider moving some of the implementations to 
 Extras, I would prefer all of them except test but we could start with some 
 of the more obscure ones at least

 Oh and another one on my wish list:
 - Finish the query builder implementation that I started a year or two ago 
 and deprecate the bulk of the delegator find methods.

 Regards
 Scott

 On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:

 Hi all,

 now that the great community discussion about the Lose Weight Program for 
 OFBiz is settling down (thanks to all of you for the great ideas, enthusiasm 
 and participation) we can start to wrap up a roadmap (it would be nice to 
 set it up in Jira, using a specific Jira version so that we can keep track 
 of progress together... any ideas for a good name for it?) by listing the 
 actionable items and also by considering other topics that may be of 
 interest to the community.
 This thread is an attempt to integrate the roadmap with some additional 
 tasks if the community will consider them a priority.

 But first of all, here is the list with a categorization/summary of the 
 tasks being discussed so far:

 (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we 
 will create tasks in Jira for each):
 * setup a nice page in the OFBiz website to describe the OFBiz Extras 
 ecosystem (external project names will be added there); the OFBiz PMC will 
 have to work on this (also check if there is additional paperwork to do)
 * move some of the component/code to Extras: we will create individual Jira 
 tasks for each component and then design details (how to move) will be 
 discussed in the task; we will need volunteers (committers and not) to 
 contribute patches/commits and also at least one maintainer (OFBiz committer 
 or not) for each component
 * move some of the component/code to Attic: we will create individual Jira 
 tasks for each removal and then design details (how to remove) will be 
 discussed in the tasks; we will need volunteers (committers and not) to 
 contribute patches/commits

 The above will form the first part of the roadmap.

 

 The following list is simply my personal attempt to propose some priorities 
 for the community; some of them are based on comments from people on the dev 
 list, some of them are personal ideas based on some reviews I did to the 
 OFBiz codebase.
 Feel free to add/remove items to the list but please while doing this

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

+1 to what Anne said, even I used to think that special-purpose is all the 
extra stuff accept e-commerce which I wondered why it lies there,
pretty much everything is captured in applications if we consider a complete 
ERP accept assetmaint and and projectmgr, these two should also have been a 
part of applications,
and if not atleast assetmaint, as any organization has assets and its 
accounted. Projectmgr could stay in special-purpose. 


Regards
Prince




 From: Anne a...@cohsoft.com.au
To: dev@ofbiz.apache.org 
Sent: Thursday, March 22, 2012 7:16 AM
Subject: Re: Lose Weight Program for OFBiz - what should go to specialpurpose
 
If we can agree on exactly what specialpurpose will be for in future, we
might find it easy to decide what to move.

My original thought was that specialpurpose is for the extras that most
people won't want. But in future Apache Extras will be doing that. So
should we remove specialpurpose totally? Everything in it goes either to
Extras or to Applications?

I have not decided whether I like that idea. Only thing I am sure of is
that ecommerce should stay somewhere in core, but it looks like everyone
else agrees on that.

Cheers,
Anne.

On 22 March 2012 07:06, Mansour Al Akeel mansour.alak...@gmail.com wrote:

 Thank you Jacques. XUL is the mozilla UI thing.
 I didn't use any of the framework mentioned her :)


 On Wed, Mar 21, 2012 at 2:24 PM, Jacques Le Roux
 jacques.le.r...@les7arts.com wrote:
  From: Mansour Al Akeel mansour.alak...@gmail.com
 
  Anil,
 
  I did not mean that putting a component under specialpurposes will
  make it used more by developers.
  I meant because it will be used more than other component, let's not
 move
  it.
  From Jacopo's first email about the Lose Weight :
 
  Legenda for what I propose for each piece of code:
  * Attic: remove from code base and document the removal for future
  reference in this page
  * Extras: identify a person interested in maintaining the code as a
  separate project hosted as an Apache Extra project (not officially
  under the ASF); add a link to it from the page that will contain
  OFBiz Extras
 
  He didn't mention anything about what type of applications should
  go/remain under specialpurposes.
  Since (I think), pos is used more than what went into Exta or Attic, I
  suggested keeping it where it's.
  The question is, will POS be maintained by ofbiz community or another
  party ? If it's will be separated from ofbiz, what about XUL
  integration code?
 
 
  It's not XUL but XUI (which is a dead project, replaced by Aria which now
  smells* almost as much)
  http://xui.sourceforge.net/index.html
  http://www.formaria.org/
  This does not prevent the POS to work well...
 
  Jacques
  PS: *smells like Frank Zappa said about Jazz: Jazz isn't dead. It just
  smells funny.
  http://www.goodreads.com/quotes/show/3092
  Jazz has much evolved since...Not Aria...
 
 
  should it remain part of  the core ofbiz (framework), or moved to the
  component that needs it, and becomes the responsibility of the POS
  maintainer ?
 
 
  With regard to changing the License, I think it's possible on any part
  of Ofbiz and not only components under Extra.
  In all cases, users who uses POS more than I do, can give better
  suggestion.
 
 
 
  On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel 
 anil.pa...@hotwaxmedia.com
  wrote:
 
 
  Jacques,
  I don't use pos, but I think it's good idea to keep it where it's. I
  think it's more likely, it will be used more than what goes in Extra.
  It fits specialpurpose.
 
 
  Why do you think a component will be used more if its in specialpurpose
  section, instead of Extras.
 
  Personally think it opposite, If a business is interested in using POS,
  they will find be able to find it from Extras as well.
  Like any other Ofbiz application, The Users of POS application will
 will
  respond by saying UX sucks :). At that point Company
  who deployed the POS will be motivated to improve it. If POS is in
 Extras
  its will be much easy for new developer to become
  active committer.
 
  In some cases, contributor may want to change License on a components.
  Doing such thing will be possible for Ofbiz Extras.
 
  One of the reasons (I am sure there were many) why OpenTaps was started
  is License.
 
  I will personally like to have more freedom around UI toolset. Ofbiz
  Extras will make it possible. And if application is well
  accepted by users then it will get popular and community will grow.
 
  Regards
  Anil Patel
 
 
 
  On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel
  anil.pa...@hotwaxmedia.com wrote:
 
  People are really worried on the idea of moving certain components
 from
  Ofbiz trunk to Ofbiz Extras. Why is it so?
 
  Moving a component from Ofbiz trunk to Ofbiz Extras does not mean
 that
  the component is not good and so we are throwing it out.
  Instead idea is to allow components to grow by giving them little
 more
  freedom.
 
  Like Jacopo mentioned in

Re: Lose Weight Program for OFBiz - what should go to specialpurpose

Well pretty much all that we think is an additional integration to the core 
concept of the application,
like LDAP,Shark, Workfolw, crowd,  all that that is already there seems pretty 
much thoughtful already.

Regards
Prince




 From: Mansour Al Akeel mansour.alak...@gmail.com
To: dev@ofbiz.apache.org 
Sent: Thursday, March 22, 2012 1:36 AM
Subject: Re: Lose Weight Program for OFBiz - what should go to specialpurpose
 
Thank you Jacques. XUL is the mozilla UI thing.
I didn't use any of the framework mentioned her :)


On Wed, Mar 21, 2012 at 2:24 PM, Jacques Le Roux
jacques.le.r...@les7arts.com wrote:
 From: Mansour Al Akeel mansour.alak...@gmail.com

 Anil,

 I did not mean that putting a component under specialpurposes will
 make it used more by developers.
 I meant because it will be used more than other component, let's not move
 it.
 From Jacopo's first email about the Lose Weight :

 Legenda for what I propose for each piece of code:
 * Attic: remove from code base and document the removal for future
 reference in this page
 * Extras: identify a person interested in maintaining the code as a
 separate project hosted as an Apache Extra project (not officially
 under the ASF); add a link to it from the page that will contain
 OFBiz Extras

 He didn't mention anything about what type of applications should
 go/remain under specialpurposes.
 Since (I think), pos is used more than what went into Exta or Attic, I
 suggested keeping it where it's.
 The question is, will POS be maintained by ofbiz community or another
 party ? If it's will be separated from ofbiz, what about XUL
 integration code?


 It's not XUL but XUI (which is a dead project, replaced by Aria which now
 smells* almost as much)
 http://xui.sourceforge.net/index.html
 http://www.formaria.org/
 This does not prevent the POS to work well...

 Jacques
 PS: *smells like Frank Zappa said about Jazz: Jazz isn't dead. It just
 smells funny.
 http://www.goodreads.com/quotes/show/3092
 Jazz has much evolved since...Not Aria...


 should it remain part of  the core ofbiz (framework), or moved to the
 component that needs it, and becomes the responsibility of the POS
 maintainer ?


 With regard to changing the License, I think it's possible on any part
 of Ofbiz and not only components under Extra.
 In all cases, users who uses POS more than I do, can give better
 suggestion.



 On Wed, Mar 21, 2012 at 11:16 AM, Anil Patel anil.pa...@hotwaxmedia.com
 wrote:


 Jacques,
 I don't use pos, but I think it's good idea to keep it where it's. I
 think it's more likely, it will be used more than what goes in Extra.
 It fits specialpurpose.


 Why do you think a component will be used more if its in specialpurpose
 section, instead of Extras.

 Personally think it opposite, If a business is interested in using POS,
 they will find be able to find it from Extras as well.
 Like any other Ofbiz application, The Users of POS application will will
 respond by saying UX sucks :). At that point Company
 who deployed the POS will be motivated to improve it. If POS is in Extras
 its will be much easy for new developer to become
 active committer.

 In some cases, contributor may want to change License on a components.
 Doing such thing will be possible for Ofbiz Extras.

 One of the reasons (I am sure there were many) why OpenTaps was started
 is License.

 I will personally like to have more freedom around UI toolset. Ofbiz
 Extras will make it possible. And if application is well
 accepted by users then it will get popular and community will grow.

 Regards
 Anil Patel



 On Wed, Mar 21, 2012 at 10:48 AM, Anil Patel
 anil.pa...@hotwaxmedia.com wrote:

 People are really worried on the idea of moving certain components from
 Ofbiz trunk to Ofbiz Extras. Why is it so?

 Moving a component from Ofbiz trunk to Ofbiz Extras does not mean that
 the component is not good and so we are throwing it out.
 Instead idea is to allow components to grow by giving them little more
 freedom.

 Like Jacopo mentioned in one of his responses, Projects from Ofbiz
 Extras can still post updates on Ofbiz lists.

 Finally if a Project in Extras is useful for business, people will keep
 improving it and community will grow.

 Thanks and Regards
 Anil Patel
 HotWax Media Inc

 On Mar 21, 2012, at 8:34 AM, Jacques Le Roux wrote:

 They are more generic sure, I wonder for the pos...

 Jacques

 From: Mansour Al Akeel mansour.alak...@gmail.com

 Jacques,
 Yes. You are right. I meant projectmgr. :)
 I believe assetmaint and projectmgr are used more than others and
 good
 to keep them where they are.
 Thank you.
 On Wed, Mar 21, 2012 at 10:02 AM, Jacques Le Roux
 jacques.le.r...@les7arts.com wrote:

 partymgr is in application will not move, you meant ProjectMgr
 right?

 Jacques

 From: Mansour Al Akeel mansour.alak...@gmail.com

 I would recommend keeping partymgr and assetmaint.
 I am not sure if accounting depends on assetmain.


 On Wed, Mar 21, 2012 at

[jira] [Commented] (OFBIZ-4130) Tenant super user (tenant admin) can view all database details of all tenants

2012-03-23 Thread Pierre Smits (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236552#comment-13236552
 ] 

Pierre Smits commented on OFBIZ-4130:
-

Defus,

You changed the status of this issue to Patch Available, but you did not 
provide the patch. Can you please do so? I will then evaluate as soon as 
possible.

Regards,

Pierre

 Tenant super user (tenant admin) can view all database details of all tenants
 -

 Key: OFBIZ-4130
 URL: https://issues.apache.org/jira/browse/OFBIZ-4130
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 10.04, SVN trunk
Reporter: Pierre Smits
Priority: Critical
 Fix For: Release Branch 10.04, SVN trunk


 When a new tenant is created and the super user of the tenant (the 
 tenant-admin) logs in to WebTools and views the tables Tenant and 
 TenantDataSource he/she can see all details of the tenant databases, incl 
 TenantName, userID and password of the tenant databases.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Some ideas to prepare our first community roadmap

2012-03-23 Thread Erwan de FERRIERES


 eBay and eBay Store could be merged together and there's also no 
 functionality to post variants to eBay, I wrote some custom code as

Hi Prince,

this should have been merged a long time ago. Thanks for volunteering
on this task !

Cheers,


-- 
Erwan de FERRIERES

Re: Some ideas to prepare our first community roadmap

For me +1 to refactor.

I am not sure the ORM needs any work. May be I am missing something.
Please let me know what part ?

Just cleaning the entity engine code a bit, and make it more OO, will
make it easier to work with.
For example, I like to add a custom Delegator that will append some
fields to each query and will enforce Row Level Security.
For example, adding something like acl.xml next to the entity
definitions, which contains the rules about the access.
I know Oracle database has what is called virtual Private Database,
and will be nice to have something similar instead of checking for
access control in each service call.
Just looking at the code currently there, makes the idea goes away.
Refactoring the code will make things a bit easier.

Ofbiz currently uses its own container to load all it's component. I
was not able to find a lot of docs. May be missed them.
I don't know if using alternative container is a reasonable suggestion.

I see a lot of documentations and examples about using IoC containers
with tomcat/jetty/geronimo and OSGI.


On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani princesew...@ymail.com wrote:


 +1 to the Refractor, Have a few questions and a few suggestions :
 Questions :


 Are we looking to improve upon the ORM as well ?

 And what about the OSGI stuff, are we planning something on that to enhance 
 the plug-in approach?

 What's all about the extra stuff? are we just gonna keep 'em separately and 
 maintain 'em separately or are we
 really commercializing?

 Also, What all is that we're thinking to add on to the existing application 
 or are we just looking to reduce/resize and enhance what all
 is there?


 Suggestions :

 Google Base Component : Google has upgraded to Google Content API long back 
 so the one in 10.04 no more works to upload products to Google merchant
 haven't checked 11.04 yet.

 eBay and eBay Store could be merged together and there's also no 
 functionality to post variants to eBay, I wrote some custom code as

 part of a POC for that, also customer grievances from eBay is something 
 that's missing.

 Integration with Amazon using Amazon MWS will be cool.

 Upgrade for Fedex API as they're retiring the SOAP API that is currently 
 used, on 31st may 2012.

 Also I'm ready to volunteer any component at any level, be it a committer or 
 not.
 I'm very much excited about the massive change that we're about to bring as a 
 community to

 the application.

 Regards
 Prince




 
  From: Nicolas Malin malin.nico...@librenberry.net
 To: dev@ofbiz.apache.org
 Sent: Friday, March 23, 2012 4:21 PM
 Subject: Re: Some ideas to prepare our first community roadmap

 +1 a greate roadmap with lot of works

 On refactoring idea :
   * review/improve best pratice screen (to manage icons, strong table
 line, ...), I had started on this subject but not finalize.

 Nicolas

 Le 23/03/2012 11:07, Scott Gray a écrit :
 I'm in favor of all of those things so +1 from me.

 For a JIRA version, how about 13.04? :-)

 One other topic that's been on my mind, payment gateway implementations:
 - Move the test implementation into it's own class so that it isn't 
 overcrowding PaymentGatewayServices and is consistent with the others
 - Refactor the test implementation so that you can use the CVV code to test 
 different behaviors instead of having a bunch of different methods like 
 alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
 - Ensure consistency between the implementations and better document the 
 gateway interfaces.  Also remove virtually all database calls from the 
 implementations (they run in their own transaction which can be painful when 
 querying new data).
 - After cleaning them up, consider moving some of the implementations to 
 Extras, I would prefer all of them except test but we could start with some 
 of the more obscure ones at least

 Oh and another one on my wish list:
 - Finish the query builder implementation that I started a year or two ago 
 and deprecate the bulk of the delegator find methods.

 Regards
 Scott

 On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:

 Hi all,

 now that the great community discussion about the Lose Weight Program for 
 OFBiz is settling down (thanks to all of you for the great ideas, 
 enthusiasm and participation) we can start to wrap up a roadmap (it would 
 be nice to set it up in Jira, using a specific Jira version so that we 
 can keep track of progress together... any ideas for a good name for it?) 
 by listing the actionable items and also by considering other topics that 
 may be of interest to the community.
 This thread is an attempt to integrate the roadmap with some additional 
 tasks if the community will consider them a priority.

 But first of all, here is the list with a categorization/summary of the 
 tasks being discussed so far:

 (MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we 
 will create tasks in Jira for each):
 * setup a nice

Re: Some ideas to prepare our first community roadmap

Yeah making it more OO is what I'm actually referring  to, OFBiz entity-engine 
is
a different architecture altogether if we compare it to other existing 
counter-parts like hibernate and 

Ibatis, I haven't really looked at the query generation code, but does anyone 
thinks that it needs a 

bit more optimization?  I know I'm talking at a very high level despite of 
checking out the 
implementation, Also for cases where we need to plug-in our queries (And I 
really mean SQL Queries)  there should be additional methods in 

GenericDelegator to achieve it, in the current scenario we've to make an 
instace of SQLProcessor to get that done,
I'm not sure, but it must be a singleton as per my understanding, Is there any 
way to get that existing Singleton 

in our code using some method, If not we should think of that too, it would 
make OFBiz Entity  Engine 

superior to its counterparts and that idea of permissions at the entity level 
is awesome!!

P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be 
done.

Regards
Prince




 From: Mansour Al Akeel mansour.alak...@gmail.com
To: dev@ofbiz.apache.org; Prince Sewani princesew...@ymail.com 
Sent: Friday, March 23, 2012 6:37 PM
Subject: Re: Some ideas to prepare our first community roadmap
 
For me +1 to refactor.

I am not sure the ORM needs any work. May be I am missing something.
Please let me know what part ?

Just cleaning the entity engine code a bit, and make it more OO, will
make it easier to work with.
For example, I like to add a custom Delegator that will append some
fields to each query and will enforce Row Level Security.
For example, adding something like acl.xml next to the entity
definitions, which contains the rules about the access.
I know Oracle database has what is called virtual Private Database,
and will be nice to have something similar instead of checking for
access control in each service call.
Just looking at the code currently there, makes the idea goes away.
Refactoring the code will make things a bit easier.

Ofbiz currently uses its own container to load all it's component. I
was not able to find a lot of docs. May be missed them.
I don't know if using alternative container is a reasonable suggestion.

I see a lot of documentations and examples about using IoC containers
with tomcat/jetty/geronimo and OSGI.


On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani princesew...@ymail.com wrote:


 +1 to the Refractor, Have a few questions and a few suggestions :
 Questions :


 Are we looking to improve upon the ORM as well ?

 And what about the OSGI stuff, are we planning something on that to enhance 
 the plug-in approach?

 What's all about the extra stuff? are we just gonna keep 'em separately and 
 maintain 'em separately or are we
 really commercializing?

 Also, What all is that we're thinking to add on to the existing application 
 or are we just looking to reduce/resize and enhance what all
 is there?


 Suggestions :

 Google Base Component : Google has upgraded to Google Content API long back 
 so the one in 10.04 no more works to upload products to Google merchant
 haven't checked 11.04 yet.

 eBay and eBay Store could be merged together and there's also no 
 functionality to post variants to eBay, I wrote some custom code as

 part of a POC for that, also customer grievances from eBay is something 
 that's missing.

 Integration with Amazon using Amazon MWS will be cool.

 Upgrade for Fedex API as they're retiring the SOAP API that is currently 
 used, on 31st may 2012.

 Also I'm ready to volunteer any component at any level, be it a committer or 
 not.
 I'm very much excited about the massive change that we're about to bring as a 
 community to

 the application.

 Regards
 Prince




 
  From: Nicolas Malin malin.nico...@librenberry.net
 To: dev@ofbiz.apache.org
 Sent: Friday, March 23, 2012 4:21 PM
 Subject: Re: Some ideas to prepare our first community roadmap

 +1 a greate roadmap with lot of works

 On refactoring idea :
   * review/improve best pratice screen (to manage icons, strong table
 line, ...), I had started on this subject but not finalize.

 Nicolas

 Le 23/03/2012 11:07, Scott Gray a écrit :
 I'm in favor of all of those things so +1 from me.

 For a JIRA version, how about 13.04? :-)

 One other topic that's been on my mind, payment gateway implementations:
 - Move the test implementation into it's own class so that it isn't 
 overcrowding PaymentGatewayServices and is consistent with the others
 - Refactor the test implementation so that you can use the CVV code to test 
 different behaviors instead of having a bunch of different methods like 
 alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
 - Ensure consistency between the implementations and better document the 
 gateway interfaces.  Also remove virtually all database calls from the 
 implementations (they run in their own transaction which can be painful

[jira] [Updated] (OFBIZ-3638) Assigning a resource to a task is not reflected in the resource's tasks view.

2012-03-23 Thread Pierre Smits (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-3638:


Attachment: OFBIZ-3638-AssigningResourceIsNotReflected.patch

This patch will fix the overview.

 Assigning a resource to a task is not reflected in the resource's tasks view.
 -

 Key: OFBIZ-3638
 URL: https://issues.apache.org/jira/browse/OFBIZ-3638
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/projectmgr
Affects Versions: SVN trunk
 Environment: Windows 7
Reporter: Peter Radkov
 Attachments: OFBIZ-3638-AssigningResourceIsNotReflected.patch


 Steps to reproduce the bug:
 1) Create a Project, a Phase and a Task (say Observe the Bug).
 2) Select the Observe the Bug task, go to its [Resources] sub-tab and 
 assign a resource (Say Tester) to it.
 3) Now go to the resource Tester that you just assigned (from the Project's 
 application main menu select [Resoruces] and then select Tester from the 
 list).
 4) Click on the Tester's [Tasks] sub-tab and observe that the task Observe 
 the Bug is NOT listed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (OFBIZ-3638) Assigning a resource to a task is not reflected in the resource's tasks view.

2012-03-23 Thread Erwan de FERRIERES (Assigned) (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwan de FERRIERES reassigned OFBIZ-3638:
-

Assignee: Erwan de FERRIERES

 Assigning a resource to a task is not reflected in the resource's tasks view.
 -

 Key: OFBIZ-3638
 URL: https://issues.apache.org/jira/browse/OFBIZ-3638
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/projectmgr
Affects Versions: SVN trunk
 Environment: Windows 7
Reporter: Peter Radkov
Assignee: Erwan de FERRIERES
 Attachments: OFBIZ-3638-AssigningResourceIsNotReflected.patch


 Steps to reproduce the bug:
 1) Create a Project, a Phase and a Task (say Observe the Bug).
 2) Select the Observe the Bug task, go to its [Resources] sub-tab and 
 assign a resource (Say Tester) to it.
 3) Now go to the resource Tester that you just assigned (from the Project's 
 application main menu select [Resoruces] and then select Tester from the 
 list).
 4) Click on the Tester's [Tasks] sub-tab and observe that the task Observe 
 the Bug is NOT listed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-3639) Can not distinguish entries in the Resource's tasks list view.

2012-03-23 Thread Pierre Smits (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236615#comment-13236615
 ] 

Pierre Smits commented on OFBIZ-3639:
-

It is better not to add a task twice to a person. If the project manager made 
such a mistake, he can always click the [Remove]-button to correct it.

Regards,

Pierre

 Can not distinguish entries in the Resource's tasks list view.
 --

 Key: OFBIZ-3639
 URL: https://issues.apache.org/jira/browse/OFBIZ-3639
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/projectmgr
Affects Versions: SVN trunk
 Environment: Windows 7
Reporter: Peter Radkov

 Steps to reproduce the bug:
 1) Create a resource say Tester with 2 roles having the Project Team parent 
 role - say Clicker drone and Unit tests coder.
 3) Go to the resources's [Tasks] view from  [Project Manager Main Menu / 
 Resources / Select Tester / Tasks]
 2) Assign this resource to a task (say Catch the bug) first in its first 
 role, then in its second role.
 4) Observe that now there are 2 indistinguishable lines for Catch the bug 
 in the Tester's tasks list.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: bin folder for executable files/scripts

Jose, Price,

thank you for your feedback, it really helps.
Jose, I have modified the script according to your suggestions, thank you.
I am going to commit the changes shortly.

Thanks,

Jacopo


On Mar 23, 2012, at 11:43 AM, Prince Sewani wrote:

 Hi Jacopo,
 
 Although I'm not a windows user but yes it works fine from the tools folder 
 on windows. 
 
 
 Regards
 Prince
 
 
 
 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 To: dev@ofbiz.apache.org 
 Sent: Friday, March 23, 2012 3:32 PM
 Subject: Re: bin folder for executable files/scripts
 
 Actually, the /d shouldn't be required:
 
 ===
 echo off
 set OFBIZ_HOME=%0\..\..\
 echo on
 cd %OFBIZ_HOME%
 %JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
 echo off
 ===
 
 Thanks,
 
 Jacopo
 
 On Mar 23, 2012, at 10:57 AM, Jacopo Cappellato wrote:
 
 I did progress on this: I was able to move all the scripts to the tools 
 folder; I didn't add the bin subfolder to it because the existing files in 
 the tools folder are not used and can be removed: in this way we will have 
 a tools folder containing all the platform dependent scripts.
 But now I need some help from Windows users:
 
 could you please try to create a startofbiz.bat file in the tools folder 
 with the following content:
 ===
 echo off
 set OFBIZ_HOME=%0\..\..\
 echo on
 cd /d %OFBIZ_HOME%
 %JAVA_HOME%\bin\java -Xms128M -Xmx512M -XX:MaxPermSize=512m -jar ofbiz.jar
 echo off
 ===
 
 Then you should try to run it from the home folder:
 
 tools\startorfbiz.bat
 
 and from the tools folder:
 
 cd tools
 startorfbiz.bat
 
 Both should work fine: I already did this work for the sh files but I 
 couldn't test the above mechanism for Windows.
 
 I would really appreciate your feedback.
 
 Thanks,
 
 Jacopo
 
 
 On Mar 21, 2012, at 11:34 AM, Prince Sewani wrote:
 
 Well the 'bin' clashing with eclipse default is really a concern
 to being with, the learning curve is yet steep, and with to dos of IDE's as 
 of now,
 everyone is pretty much acquainted. Also in-case we change it to 'bin' in 
 the main folder,
 then there'll be an additional set of documentation required for that to 
 help users on different Operating systems.
 
 Unless we go like opentaps (felt that on a few things) and then one is not 
 really able to use it (Just a comment No offense).
 
 
 tools/bin sounds great, unless that also doesn't call of any other clash 
 or so.
 
 Regards
 Prince
 
 
 
 
 
 From: Mansour Al Akeel mansour.alak...@gmail.com
 To: dev@ofbiz.apache.org 
 Sent: Monday, March 19, 2012 4:13 PM
 Subject: Re: bin folder for executable files/scripts
 
 bin is good enough.
 
 
 On Mon, Mar 19, 2012 at 3:34 AM, Jacques Le Roux
 jacques.le.r...@les7arts.com wrote:
 Hi Jacopo,
 
 tools/bin  sounds good to me
 
 Jacques
 
 From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com
 
 Thanks everyone for the valuable comments!
 I am trying to finalize this thread: there seems to be consensus to move
 all the executable scripts into a folder to keep things organized.
 For the name of the folder:
 * some of you think that the bin (as I originally suggested) should be
 used because it is often used for this purpose
 * some of you are worried that this could interfere with some commonly
 used IDEs (e.g. Eclipse) that use the bin folder for output and need to be
 configured to use a different standard name
 
 After reviewing what we have now in OFBiz I am wondering if we could use
 the already existing tools folder; its current layout is:
 tools/api-java16
 tools/src
 
 option a: add all the executables to tools/ folder directly
 option b: create a subfolder tools/bin and add all the executables there
 
 What do you think?
 
 Jacopo
 
 On Feb 29, 2012, at 5:45 PM, Jacques Le Roux wrote:
 
 Then we could recommend to name .bin for instance
 But I wonder if this will not be a source of problem for newbies...
 
 And also for Windows users, bin is not a standard name at all
 
 Jacques
 
 From: Adrian Crum adrian.c...@sandglass-software.com
 
 That's fine with me. We just need to update the Eclipse configuration
 files.
 
 -Adrian
 
 On 2/29/2012 3:20 PM, J. Eckard wrote:
 
 I think that eclipse / eclipse users should have to accommodate the
 directory structure of OFBiz, not the other way around.
 
 
 On Feb 29, 2012, at 9:58 AM, Jacopo Cappellato wrote:
 
 Thanks for the feedback! Any suggestion for the name of the folder? I
 was hoping to use a standard name, that is why I initially proposed 
 the
 bin folder... but since that is not an option we will have to think 
 to
 something else (unless we use the existing tools folder but I am 
 not sure
 about the intended usage of that).
 
 Jacopo
 
 
 On Feb 27, 2012, at 8:45 PM, Jacques Le Roux wrote:
 
 +1
 
 Jacques
 
 From: Adrian

Re: Some ideas to prepare our first community roadmap

Ok,
let's be clear about what I mean here, and explain a bit about what I think.
I think it's better to keep the entity engine as is, with regard to
handling data, where it return records and not objects.

However, OO can be done in the framework level. Cleaning the code a
bit, removing deprecated methods, rely less on static methods,
and use dependency injection. For example:

public static DelegatorInfo getDelegatorInfo(String name) {
return configRef.get().delegatorInfos.get(name);
}

can be replace by a little more verbose, but more readable:

public static DelegatorInfo getDelegatorInfo(String name) {
EntityConfigUtil configUtil = configRef.get();
MapString, DelegatorInfo map = configUtil.delegatorInfos;
DelegatorInfo tmp = map.get(name);
return tmp;
}

And really, instead of using static methods to lookup objects by name,
a container can used to track all this and
lookup those instances when needed. For example,
org.ofbiz.entity.model.ModelReader doesn't have to provide a static
method to be used a factory, so it can keep on tracking instances
created of itself. It's the job of the container.
Same thing applies to caching. We see caching code all over the place.
Code that does the lookup, but checking a
hashtable used as a cache before deciding to create an object.

Cleaning the code, a bit and make it OO, will allow using Aspects for
things like this.

This is what I meant by making the code more OO.

Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
While I didn't do a practical comparison with OfBiz entity engine, I
think ofbiz entity engine is the most optimized, and fastest,
because it's closer to JDBC than any other ORM framework. I am not
sure if any optimization can be with the EE beside cleaning the code
a bit, and refactoring.



On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani princesew...@ymail.com wrote:
 Yeah making it more OO is what I'm actually referring  to, OFBiz 
 entity-engine is
 a different architecture altogether if we compare it to other existing 
 counter-parts like hibernate and

 Ibatis, I haven't really looked at the query generation code, but does anyone 
 thinks that it needs a

 bit more optimization?  I know I'm talking at a very high level despite of 
 checking out the
 implementation, Also for cases where we need to plug-in our queries (And I 
 really mean SQL Queries)  there should be additional methods in

 GenericDelegator to achieve it, in the current scenario we've to make an 
 instace of SQLProcessor to get that done,
 I'm not sure, but it must be a singleton as per my understanding, Is there 
 any way to get that existing Singleton

 in our code using some method, If not we should think of that too, it would 
 make OFBiz Entity  Engine

 superior to its counterparts and that idea of permissions at the entity level 
 is awesome!!

 P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be 
 done.

 Regards
 Prince



 
  From: Mansour Al Akeel mansour.alak...@gmail.com
 To: dev@ofbiz.apache.org; Prince Sewani princesew...@ymail.com
 Sent: Friday, March 23, 2012 6:37 PM
 Subject: Re: Some ideas to prepare our first community roadmap

 For me +1 to refactor.

 I am not sure the ORM needs any work. May be I am missing something.
 Please let me know what part ?

 Just cleaning the entity engine code a bit, and make it more OO, will
 make it easier to work with.
 For example, I like to add a custom Delegator that will append some
 fields to each query and will enforce Row Level Security.
 For example, adding something like acl.xml next to the entity
 definitions, which contains the rules about the access.
 I know Oracle database has what is called virtual Private Database,
 and will be nice to have something similar instead of checking for
 access control in each service call.
 Just looking at the code currently there, makes the idea goes away.
 Refactoring the code will make things a bit easier.

 Ofbiz currently uses its own container to load all it's component. I
 was not able to find a lot of docs. May be missed them.
 I don't know if using alternative container is a reasonable suggestion.

 I see a lot of documentations and examples about using IoC containers
 with tomcat/jetty/geronimo and OSGI.


 On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani princesew...@ymail.com wrote:


 +1 to the Refractor, Have a few questions and a few suggestions :
 Questions :


 Are we looking to improve upon the ORM as well ?

 And what about the OSGI stuff, are we planning something on that to enhance 
 the plug-in approach?

 What's all about the extra stuff? are we just gonna keep 'em separately and 
 maintain 'em separately or are we
 really commercializing?

 Also, What all is that we're thinking to add on to the existing application 
 or

[jira] [Commented] (OFBIZ-4585) Cannot save scrum preferences

2012-03-23 Thread Pierre Smits (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236648#comment-13236648
 ] 

Pierre Smits commented on OFBIZ-4585:
-

Apparently the querystring ?partyId=admin was missing from the url. If 
preferences are accessed through the 'My Profile' menu item in the top menu of 
scrum, then this will not occur.

 Cannot save scrum preferences
 -

 Key: OFBIZ-4585
 URL: https://issues.apache.org/jira/browse/OFBIZ-4585
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/scrum
Affects Versions: SVN trunk
Reporter: Wai

 https://demo-trunk.ofbiz.apache.org:8443/scrum/control/Preferences
 Logged in as admin.
 The preferences shown on this page cannot be saved.  The submit button is not 
 available.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: svn commit: r1304061 - /ofbiz/trunk/.classpath

2012-03-23 Thread adrian . crum

If those files were not there when I first used OFBiz, I would not  
have known how to set up Eclipse. I agree with Scott - let the Eclipse  
users worry about them.


-Adrian

Quoting Scott Gray scott.g...@hotwaxmedia.com:

The flip side of the argument would be that everyone who is using  
eclipse would then have to maintain it themselves, not sure that  
would be more efficient for the community.


Personally I don't really mind cleaning it up myself when I see an  
error, takes a few minutes at most.  And I think that's the way it  
should be, the users of a specific IDE should bear the burden of  
keeping it up to date, others shouldn't have to worry about it.  If  
we started including some other IDE's config files I certainly  
wouldn't want to have to deal with them.


Regards
Scott

On 23/03/2012, at 10:26 AM, J. Eckard wrote:

Do we really want to keep IDE-specific support files in the  
repository (and keep them updated by hand in perpetuity)? I ask  
because it seems like a fragile (and tedious) process... for  
instance, I don't use eclipse and I have no idea if or how this  
change will affect an existing eclipse project.


Joe

On Mar 22, 2012, at 5:05 PM, eckar...@apache.org wrote:


Author: eckardjf
Date: Thu Mar 22 21:05:17 2012
New Revision: 1304061

URL: http://svn.apache.org/viewvc?rev=1304061view=rev
Log:
update eclipse classpath file to reflect jetty container upgrade

Modified:
  ofbiz/trunk/.classpath

Modified: ofbiz/trunk/.classpath
URL:  
http://svn.apache.org/viewvc/ofbiz/trunk/.classpath?rev=1304061r1=1304060r2=1304061view=diff

==
--- ofbiz/trunk/.classpath (original)
+++ ofbiz/trunk/.classpath Thu Mar 22 21:05:17 2012
@@ -138,12 +138,21 @@
   classpathentry kind=lib  
path=framework/jcr/lib/jackrabbit-spi-commons-2.3.3.jar/
   classpathentry kind=lib  
path=framework/jcr/lib/jackrabbit-ocm-2.0.jar sourcepath=/ocm/

   classpathentry kind=lib path=framework/jcr/lib/jcr-2.0.jar/
-classpathentry kind=lib  
path=framework/jetty/lib/jasper-compiler-5.5.15.jar/
-classpathentry kind=lib  
path=framework/jetty/lib/jasper-runtime-5.5.15.jar/
-classpathentry kind=lib  
path=framework/jetty/lib/jetty-6.1.11.jar/
-classpathentry kind=lib  
path=framework/jetty/lib/jetty-ajp-6.1.11.jar/
-classpathentry kind=lib  
path=framework/jetty/lib/jetty-sslengine-6.1.11.jar/
-classpathentry kind=lib  
path=framework/jetty/lib/jetty-util-6.1.11.jar/
+classpathentry kind=lib  
path=framework/jetty/com.sun.el-2.2.0.v20110806.jar/
+classpathentry kind=lib  
path=framework/jetty/javax.servlet.jsp.jstl-1.2.0.v201105211821.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-ajp-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-continuation-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-http-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-io-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-security-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-server-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-servlet-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-util-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-webapp-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/jetty-xml-8.1.2.v20120308.jar/
+classpathentry kind=lib  
path=framework/jetty/org.apache.jasper.glassfish-2.2.2.v201112011158.jar/
+classpathentry kind=lib  
path=framework/jetty/org.apache.taglibs.standard.glassfish-1.2.0.v201112081803.jar/
+classpathentry kind=lib  
path=framework/jetty/org.eclipse.jdt.core-3.7.1.jar/

   classpathentry kind=lib path=framework/service/lib/axis.jar/
   classpathentry kind=lib path=framework/service/lib/axis-ant.jar/
   classpathentry kind=lib path=framework/service/lib/wsdl4j.jar/

[jira] [Commented] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices

2012-03-23 Thread Martin Kreidenweis (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236663#comment-13236663
]

Martin Kreidenweis commented on OFBIZ-4514:
---

Hi,

I've found some time now to explain what our patch is doing.

The changes are actually in production in our system and generate correct
accounting for the German tax system.
When we have sales tax in a purchase invoice it means that we actually get a
tax refund/rebate (Vorsteuer).

The change at @@ -2144,6 +2122,18 @@ sets the glAccountId in the
acctgTransEntry according to the tax authority party and geo id found in the
invoice items. This is necessary so that the right account for the tax
authority is used in the posting of the transaction.
The changes were basically copied from the {{createAcctgTransForSalesInvoice}}
method, where the same logic is implemented. (For sales invoices we have to pay
taxes, so it is a creditEntry. For purchase invoices we get a tax rebate, so it
is a debitEntry.)
The change at @@ -2165,6 +2155,7 @@ also just makes the purchase invoice code
more like the sales invoice code. The unattributedTaxTotal has to be posted to
a tax account. In the sales invoice this is already set, in the purchase
invoice it isn't -- the patch fixes that. This is basically like the fallback
in the change @@ -2144,6 +2122,18 @@, where we set the same value when we can't
find a matching configuration for the tax authority. In case we have
unattributed tax entries, we don't even need to try to find a tax authority
configuration and simply set the fallback account type, so it gets posted to
the default tax account.

Regarding @@ -2173,6 +2164,10 @@: The call to {{getInvoiceTaxTotal}} was simply
missing here. A few lines down the variable {{invoiceTaxTotal}} is accessed.
Without applying the patch it is never set.

Jacopo is right for @@ -1841,28 +1841,6 @@ and @@ -2359,39 +2354,6 @@ -- they
are just (unrelated) cleanup. Like the comment says, the functionality has
moved to the createAcctgTransAndEntriesForPaymentApplication method, and as far
as I can tell is working correctly.

I hope the changes make more sense now.

Best Regards,
Martin

Taxes are not handled correctly when creating accounting transactions from
purchase invoices

Key: OFBIZ-4514
URL: https://issues.apache.org/jira/browse/OFBIZ-4514
Project: OFBiz
Issue Type: Wish
Components: accounting
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Priority: Trivial
Attachments: OFBIZ-4514.patch

Taxes are not handled correctly when creating accounting transactions from
purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices

2012-03-23 Thread Martin Kreidenweis (Updated) (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Kreidenweis updated OFBIZ-4514:
--

Issue Type: Bug  (was: Wish)

I still think at least part of this issue is definitely a bug. (@@ -2173,6 
+2164,10 @@)

I'd also consider the other issues fixed by the patch a bug from the German 
point of view, but I cannot speak for other tax systems. 

 Taxes are not handled correctly when creating accounting transactions from 
 purchase invoices
 

 Key: OFBIZ-4514
 URL: https://issues.apache.org/jira/browse/OFBIZ-4514
 Project: OFBiz
  Issue Type: Bug
  Components: accounting
Affects Versions: SVN trunk
Reporter: Martin Kreidenweis
Priority: Trivial
 Attachments: OFBIZ-4514.patch


 Taxes are not handled correctly when creating accounting transactions from 
 purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4496) Quick complete Drop Shipment on purchase order causes many warning messages

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236682#comment-13236682
 ] 

Jacques Le Roux commented on OFBIZ-4496:


Patches welcome...

 Quick complete Drop Shipment on purchase order causes many warning messages
 -

 Key: OFBIZ-4496
 URL: https://issues.apache.org/jira/browse/OFBIZ-4496
 Project: OFBiz
  Issue Type: Bug
  Components: order, specialpurpose/ecommerce
Affects Versions: Release Branch 11.04, SVN trunk
Reporter: Kiran Gawde

 Got following warnings during: Quick complete Drop Shipment on purchase 
 order
 [ServiceEcaCondition.java:156:WARN ] From Field (originFacilityId) is not 
 found in context for createShipment, defaulting to null.
 [ServiceEcaCondition.java:156:WARN ] From Field (destinationFacilityId) is 
 not found in context for createShipment, defaulting to null.
 [Log.java:117:WARN ] 
 [ShipmentServices.xml#setShipmentSettingsFromPrimaryOrder line 532] Cannot 
 find a shipping origin address for WS10123
 [Log.java:117:WARN ] 
 [ShipmentServices.xml#setShipmentSettingsFromPrimaryOrder line 554] Cannot 
 find a shipping destination phone number for WS10123
 [Log.java:117:WARN ] 
 [ShipmentServices.xml#setShipmentSettingsFromPrimaryOrder line 568] Cannot 
 find a shipping origin phone number for WS10123
 [  FieldToResult.java:77 :WARN ] Field value not found with name 
 lookedUpValue.originFacilityId in Map with name 
 [  FieldToResult.java:77 :WARN ] Field value not found with name 
 lookedUpValue.destinationFacilityId in Map with name 
 [Log.java:117:WARN ] [InvoiceServices.xml#getNextInvoiceId 
 line 35] errorPartyPerf
 [InvoiceServices.java:323:WARN ] No billing locations found for order 
 [WS10123] and none were created for Invoice [10061]
 [  FieldToResult.java:77 :WARN ] Field value not found with name 
 contactMechId in Map with name 
 [ServiceEcaCondition.java:156:WARN ] From Field (originFacilityId) is not 
 found in context for updateShipment, defaulting to null.
 [ServiceEcaCondition.java:156:WARN ] From Field (destinationFacilityId) is 
 not found in context for updateShipment, defaulting to null.
 [ServiceEcaCondition.java:156:WARN ] From Field (primaryOrderId) is not found 
 in context for updateShipment, defaulting to null.
 [TransactionUtil.java:375:WARN ] 
  exception report 
 --
 [TransactionUtil.setRollbackOnly] Calling transaction setRollbackOnly; this 
 stack trace shows where this is happening:
 Exception: java.lang.Exception
 Message: Error in simple-method [ 
 [file:/D:/EclipseWorkspaces/Autogoza/ofbiz/applications/accounting/script/org/ofbiz/accounting/olap/FactServices.xml#loadSalesInvoiceFact]]:
  ; {Invoice with id AI14 doesn't exist.}
  stack trace 
 ---
 java.lang.Exception: Error in simple-method [ 
 [file:/D:/EclipseWorkspaces/Autogoza/ofbiz/applications/accounting/script/org/ofbiz/accounting/olap/FactServices.xml#loadSalesInvoiceFact]]:
  ; {Invoice with id AI14 doesn't exist.}
 org.ofbiz.entity.transaction.TransactionUtil.setRollbackOnly(TransactionUtil.java:375)
 org.ofbiz.entity.transaction.TransactionUtil.rollback(TransactionUtil.java:317)
 org.ofbiz.minilang.SimpleMethod.exec(SimpleMethod.java:870)
 org.ofbiz.minilang.SimpleMethod.runSimpleMethod(SimpleMethod.java:160)
 org.ofbiz.minilang.SimpleMethod.runSimpleService(SimpleMethod.java:142)
 org.ofbiz.minilang.SimpleServiceEngine.serviceInvoker(SimpleServiceEngine.java:78)
 org.ofbiz.minilang.SimpleServiceEngine.runSync(SimpleServiceEngine.java:53)
 org.ofbiz.service.ModelServiceReader$GenericInvokerImpl.runSync(ModelServiceReader.java:761)
 _$gen.file_58$.D_58$.EclipseWorkspaces.Autogoza.ofbiz.applications.accounting.servicedef.services_95$olap_46$xml_35$loadSalesInvoiceFact.runSync(file:/D:/EclipseWorkspaces/Autogoza/ofbiz/applications/accounting/servicedef/services_olap.xml#loadSalesInvoiceFact:37)
 org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:399)
 org.ofbiz.service.ServiceDispatcher.runSync(ServiceDispatcher.java:226)
 org.ofbiz.service.GenericDispatcher.runSync(GenericDispatcher.java:163)
 org.ofbiz.service.job.GenericServiceJob.exec(GenericServiceJob.java:71)
 org.ofbiz.service.job.JobInvoker.run(JobInvoker.java:242)
 java.lang.Thread.run(Thread.java:662)
 
 2011-10-20 12:01:00,823 (default-invoker-Thread-12) [  
 ServiceDispatcher.java:543:ERROR] Error in Service [loadSalesInvoiceFact]: 
 Invoice with id AI14 doesn't exist.
 2011-10-20 12:01:00,823 (default-invoker-Thread-12) [

[jira] [Commented] (OFBIZ-4580) Categories - calculated trails

2012-03-23 Thread Kiran Gawde (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236720#comment-13236720
 ] 

Kiran Gawde commented on OFBIZ-4580:


Friends, my concern was that the solution was using findList for each 
productCategoryId. And that would hit the database(?).
My suggestion was to use existing setTrail/getTrail method from CategoryWorker.

 Categories - calculated trails
 --

 Key: OFBIZ-4580
 URL: https://issues.apache.org/jira/browse/OFBIZ-4580
 Project: OFBiz
  Issue Type: Improvement
Reporter: Paul Piper
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: SVN trunk

 Attachments: CategoryWorker-with-trail-export.patch, 
 CategoryWorker.patch, OFBIZ-4580-CategoryWorker-with-trail-export.patch


 Hey folks,
 been a while since I contributed. I noticed that currently ofbiz misses a 
 simple function to generate a category trail. Generating a trail, however, is 
 often useful when generating breadcrums, facetted search results, and proper 
 category trees in general. Hence I created the following as a timesaver:
 {code:title=getCategoryTrail|borderStyle=solid}
 public static  List getCategoryTrail(String productCategoryId,DispatchContext 
 dctx){
   GenericDelegator delegator = (GenericDelegator) 
 dctx.getDelegator();
   ListString trailElements = FastList.newInstance();
 trailElements.add(productCategoryId);
 String parentProductCategoryId = productCategoryId;
 while (UtilValidate.isNotEmpty(parentProductCategoryId)) {
 // find product category rollup
 try {
 ListEntityCondition rolllupConds = FastList.newInstance();
 
 rolllupConds.add(EntityCondition.makeCondition(productCategoryId, 
 parentProductCategoryId));
 rolllupConds.add(EntityUtil.getFilterByDateExpr());
 ListGenericValue productCategoryRollups = 
 delegator.findList(ProductCategoryRollup, 
 EntityCondition.makeCondition(rolllupConds), null, 
 UtilMisc.toList(-fromDate), null, true);
 if (UtilValidate.isNotEmpty(productCategoryRollups)) {
 // add only categories that belong to the top category to 
 trail
 for (GenericValue productCategoryRollup : 
 productCategoryRollups) {
 String trailCategoryId = 
 productCategoryRollup.getString(parentProductCategoryId);
 parentProductCategoryId = trailCategoryId;
 if (trailElements.contains(trailCategoryId)) {
 break;
 }else{
   trailElements.add(trailCategoryId);
 }
 }
 } else {
 parentProductCategoryId = null;
 }
 } catch (GenericEntityException e) {
 Debug.logError(e, Cannot generate trail from product 
 category, module);
 }
 }
 Collections.reverse(trailElements);
 return trailElements;
   }
 {code}
 I suggest to add this to the CategoryWorker.java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (OFBIZ-4696) Performance issue: Excessive querying for UserLoginSecurityGroup

[
https://issues.apache.org/jira/browse/OFBIZ-4696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jacques Le Roux closed OFBIZ-4696.
--

Resolution: Not A Problem
Assignee: Jacques Le Roux

I don't think we need to worry: Ran query in 0 milli-seconds

Performance issue: Excessive querying for UserLoginSecurityGroup

Key: OFBIZ-4696
URL: https://issues.apache.org/jira/browse/OFBIZ-4696
Project: OFBiz
Issue Type: Bug
Components: framework
Affects Versions: Release Branch 11.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux

Turn on the timing logging for GenericDAO. And comment out the code that
checks for 'queryTotalTime 150' in GenericDAO class. Then you will notice
that following query gets executed many times when you are browsing ofbiz
backend applications. At least 40 times. It's a lightweight query, and
backend application user may be limited. It would be nice to use cache.
[ GenericDAO.java:753:INFO ] Ran query in 0 milli-seconds:
EntityName: UserLoginSecurityGroup Sql: SELECT USER_LOGIN_ID, GROUP_ID,
FROM_DATE, THRU_DATE, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP,
CREATED_STAMP, CREATED_TX_STAMP FROM USER_LOGIN_SECURITY_GROUP WHERE
((USER_LOGIN_ID = ?)) where clause:{USER_LOGIN_ID=admin}

[jira] [Commented] (OFBIZ-4501) Incorrect use of eca for create/updateShipment

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236743#comment-13236743
 ] 

Jacques Le Roux commented on OFBIZ-4501:


Hi Anil,

Did you get chances to review and test?

 Incorrect use of eca for create/updateShipment
 --

 Key: OFBIZ-4501
 URL: https://issues.apache.org/jira/browse/OFBIZ-4501
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Release Branch 11.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
 Attachments: OFBIZ-4501-ModifiedCreateUpdateShipmentService.patch, 
 OFBIZ-4501-ModifiedCreateUpdateShipmentService.patch, 
 OFBIZ-4501-ShipmentServiceXml.patch, OFBIZ-4501-ShipmentServiceXml.patch, 
 OFBIZ-4501-ShipmentServiceXml.patch


 createShipment service doesn't populate the facility and order info into 
 shipment. Instead it is handled by eca rules. This is wrong. ECA rules should 
 be used to update other objects or cause other actions and not update the 
 object that is being committed. This makes it difficult to traverse the code. 
 Can also cause bugs that are difficult troubleshoot. e.g: In this case, 
 facilities are populated in shipment by method 
 setShipmentSettingsFromPrimaryOrder, but eca rule checking for 
 originFacilityId gets executed before it is populated. Following eca rules 
 should be removed and instead the code should be added to 
 create/updateshipment methods.
 !-- if new originFacilityId or destinationFacilityId, get settings from 
 facilities --
 eca service=createShipment event=commit
 condition field-name=originFacilityId operator=is-not-empty/
 action service=setShipmentSettingsFromFacilities mode=sync/
 /eca
 eca service=createShipment event=commit
 condition field-name=destinationFacilityId 
 operator=is-not-empty/
 action service=setShipmentSettingsFromFacilities mode=sync/
 /eca
 eca service=updateShipment event=commit
 condition-field field-name=originFacilityId operator=not-equals 
 to-field-name=oldOriginFacilityId/
 condition field-name=originFacilityId operator=is-not-empty/
 action service=setShipmentSettingsFromFacilities mode=sync/
 /eca
 eca service=updateShipment event=commit
 condition-field field-name=destinationFacilityId 
 operator=not-equals to-field-name=oldDestinationFacilityId/
 condition field-name=destinationFacilityId 
 operator=is-not-empty/
 action service=setShipmentSettingsFromFacilities mode=sync/
 /eca
 !-- if new primaryOrderId, get settings from order --
 eca service=createShipment event=commit
 condition field-name=primaryOrderId operator=is-not-empty/
 action service=setShipmentSettingsFromPrimaryOrder mode=sync/
 /eca
 eca service=updateShipment event=commit
 condition-field field-name=primaryOrderId operator=not-equals 
 to-field-name=oldPrimaryOrderId/
 condition field-name=primaryOrderId operator=is-not-empty/
 action service=setShipmentSettingsFromPrimaryOrder mode=sync/
 /eca

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Some ideas to prepare our first community roadmap

2012-03-23 Thread Erwan de FERRIERES


Le 22/03/2012 12:06, Jacopo Cappellato a écrit :

Hi all,


../..

Hi,

+1 on everything for me.
using Jira is also the right idea, we'll be more efficient this way.

There are 2 things I'd like to add:
* change the Debug class name to Logger (or anything) as you proposed,
* migrate from json-lib to anything else ().

json-lib is dependent on commons-lang 2, which is preventing us for 
migrating to the lang3. Moreover this project seems dead, last update in 
december 2010.


for the version name, slim down ?

Regards,

--
Erwan de FERRIERES
www.nereide.biz

Re: Some ideas to prepare our first community roadmap


Prince Sewani wrote:

+1 to the Refractor, Have a few questions and a few suggestions :
Questions :


Are we looking to improve upon the ORM as well ?


You need to read more about that. OFBiz is not ORM and the Entity Engine was actually there before ORM took its flight. This one of 
the reason Jira picked the Entity Engine at this time (we speak of 10 years ago).

I'm not against ORM, but I still believe David had a great idea.


And what about the OSGI stuff, are we planning something on that to enhance the 
plug-in approach?


I think it will not be done in this iteration (aka release time frame). But 
it's not out of the radar scope.


What's all about the extra stuff? are we just gonna keep 'em separately and 
maintain 'em separately or are we
really commercializing?


commercializing??? This is open source with and ASF license. You can 
commercialize it when you want.


Also, What all is that we're thinking to add on to the existing application or 
are we just looking to reduce/resize and enhance
what all
is there?


For now we want to slim down .-



Suggestions :

Google Base Component : Google has upgraded to Google Content API long back so 
the one in 10.04 no more works to upload products
to Google merchant
haven't checked 11.04 yet.

eBay and eBay Store could be merged together and there's also no functionality 
to post variants to eBay, I wrote some custom code
as

part of a POC for that, also customer grievances from eBay is something that's 
missing.

Integration with Amazon using Amazon MWS will be cool.

Upgrade for Fedex API as they're retiring the SOAP API that is currently used, 
on 31st may 2012.

Also I'm ready to volunteer any component at any level, be it a committer or 
not.


Welcome to do all that in Extra


I'm very much excited about the massive change that we're about to bring as a 
community to

the application.


Great, looking forward for your efforts :o)

Jacques


Regards
Prince





 From: Nicolas Malin malin.nico...@librenberry.net
To: dev@ofbiz.apache.org
Sent: Friday, March 23, 2012 4:21 PM
Subject: Re: Some ideas to prepare our first community roadmap

+1 a greate roadmap with lot of works

On refactoring idea :
* review/improve best pratice screen (to manage icons, strong table
line, ...), I had started on this subject but not finalize.

Nicolas

Le 23/03/2012 11:07, Scott Gray a écrit :

I'm in favor of all of those things so +1 from me.

For a JIRA version, how about 13.04? :-)

One other topic that's been on my mind, payment gateway implementations:
- Move the test implementation into it's own class so that it isn't 
overcrowding PaymentGatewayServices and is consistent with
the others
- Refactor the test implementation so that you can use the CVV code to test 
different behaviors instead of having a bunch of
different methods like alwaysDecline, randomlyDecline, alwaysApprove etc. etc.
- Ensure consistency between the implementations and better document the 
gateway interfaces. Also remove virtually all database
calls from the implementations (they run in their own transaction which can be 
painful when querying new data).
- After cleaning them up, consider moving some of the implementations to 
Extras, I would prefer all of them except test but we
could start with some of the more obscure ones at least

Oh and another one on my wish list:
- Finish the query builder implementation that I started a year or two ago and 
deprecate the bulk of the delegator find methods.

Regards
Scott

On 23/03/2012, at 12:06 AM, Jacopo Cappellato wrote:


Hi all,

now that the great community discussion about the Lose Weight Program for 
OFBiz is settling down (thanks to all of you for
the great ideas, enthusiasm and participation) we can start to wrap up a 
roadmap (it would be nice to set it up in Jira, using
a specific Jira version so that we can keep track of progress together... any 
ideas for a good name for it?) by listing the
actionable items and also by considering other topics that may be of interest 
to the community.
This thread is an attempt to integrate the roadmap with some additional tasks 
if the community will consider them a priority.

But first of all, here is the list with a categorization/summary of the tasks 
being discussed so far:

(MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will 
create tasks in Jira for each):
* setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem 
(external project names will be added there);
the OFBiz PMC will have to work on this (also check if there is additional 
paperwork to do)
* move some of the component/code to Extras: we will create individual Jira 
tasks for each component and then design details
(how to move) will be discussed in the task; we will need volunteers 
(committers and not) to contribute patches/commits and
also at least one maintainer (OFBiz committer or not) for each component
* move some of the component/code to Attic: we

Re: Some ideas to prepare our first community roadmap


There are Jiras pending out there with already questions/answers, just need to 
be continued

Jacques

Erwan de FERRIERES wrote:

eBay and eBay Store could be merged together and there's also no functionality 
to post variants to eBay, I wrote some custom
code as 


Hi Prince,

this should have been merged a long time ago. Thanks for volunteering
on this task !

Cheers,

Re: Some ideas to prepare our first community roadmap


Mansour Al Akeel wrote:

Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
While I didn't do a practical comparison with OfBiz entity engine, I
think ofbiz entity engine is the most optimized, and fastest,
because it's closer to JDBC than any other ORM framework. I am not
sure if any optimization can be with the EE beside cleaning the code
a bit, and refactoring.


Exactly

Jacques




On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani princesew...@ymail.com wrote:

Yeah making it more OO is what I'm actually referring to, OFBiz entity-engine is
a different architecture altogether if we compare it to other existing 
counter-parts like hibernate and

Ibatis, I haven't really looked at the query generation code, but does anyone 
thinks that it needs a

bit more optimization? I know I'm talking at a very high level despite of 
checking out the
implementation, Also for cases where we need to plug-in our queries (And I 
really mean SQL Queries) there should be additional
methods in

GenericDelegator to achieve it, in the current scenario we've to make an 
instace of SQLProcessor to get that done,
I'm not sure, but it must be a singleton as per my understanding, Is there any 
way to get that existing Singleton

in our code using some method, If not we should think of that too, it would 
make OFBiz Entity Engine

superior to its counterparts and that idea of permissions at the entity level 
is awesome!!

P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be 
done.

Regards
Prince




From: Mansour Al Akeel mansour.alak...@gmail.com
To: dev@ofbiz.apache.org; Prince Sewani princesew...@ymail.com
Sent: Friday, March 23, 2012 6:37 PM
Subject: Re: Some ideas to prepare our first community roadmap

For me +1 to refactor.

I am not sure the ORM needs any work. May be I am missing something.
Please let me know what part ?

Just cleaning the entity engine code a bit, and make it more OO, will
make it easier to work with.
For example, I like to add a custom Delegator that will append some
fields to each query and will enforce Row Level Security.
For example, adding something like acl.xml next to the entity
definitions, which contains the rules about the access.
I know Oracle database has what is called virtual Private Database,
and will be nice to have something similar instead of checking for
access control in each service call.
Just looking at the code currently there, makes the idea goes away.
Refactoring the code will make things a bit easier.

Ofbiz currently uses its own container to load all it's component. I
was not able to find a lot of docs. May be missed them.
I don't know if using alternative container is a reasonable suggestion.

I see a lot of documentations and examples about using IoC containers
with tomcat/jetty/geronimo and OSGI.


On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani princesew...@ymail.com wrote:



+1 to the Refractor, Have a few questions and a few suggestions :
Questions :


Are we looking to improve upon the ORM as well ?

And what about the OSGI stuff, are we planning something on that to enhance the 
plug-in approach?

What's all about the extra stuff? are we just gonna keep 'em separately and 
maintain 'em separately or are we
really commercializing?

Also, What all is that we're thinking to add on to the existing application or 
are we just looking to reduce/resize and enhance
what all
is there?


Suggestions :

Google Base Component : Google has upgraded to Google Content API long back so 
the one in 10.04 no more works to upload
products to Google merchant haven't checked 11.04 yet.

eBay and eBay Store could be merged together and there's also no functionality 
to post variants to eBay, I wrote some custom
code as

part of a POC for that, also customer grievances from eBay is something that's 
missing.

Integration with Amazon using Amazon MWS will be cool.

Upgrade for Fedex API as they're retiring the SOAP API that is currently used, 
on 31st may 2012.

Also I'm ready to volunteer any component at any level, be it a committer or 
not.
I'm very much excited about the massive change that we're about to bring as a 
community to

the application.

Regards
Prince





From: Nicolas Malin malin.nico...@librenberry.net
To: dev@ofbiz.apache.org
Sent: Friday, March 23, 2012 4:21 PM
Subject: Re: Some ideas to prepare our first community roadmap

+1 a greate roadmap with lot of works

On refactoring idea :
* review/improve best pratice screen (to manage icons, strong table
line, ...), I had started on this subject but not finalize.

Nicolas

Le 23/03/2012 11:07, Scott Gray a écrit :

I'm in favor of all of those things so +1 from me.

For a JIRA version, how about 13.04? :-)

One other topic that's been on my mind, payment gateway implementations:
- Move the test implementation into it's own class so that it isn't

Re: Some ideas to prepare our first community roadmap


Mansour,

You are welcome to provide patches with test cases and explanations for all 
your ideas.
But to no get frustrated by rejects, it's better before to discuss each point 
in details in this ML.

The more brains, the better

Jacques

Mansour Al Akeel wrote:

Ok,
let's be clear about what I mean here, and explain a bit about what I think.
I think it's better to keep the entity engine as is, with regard to
handling data, where it return records and not objects.

However, OO can be done in the framework level. Cleaning the code a
bit, removing deprecated methods, rely less on static methods,
and use dependency injection. For example:

public static DelegatorInfo getDelegatorInfo(String name) {
return configRef.get().delegatorInfos.get(name);
}

can be replace by a little more verbose, but more readable:

public static DelegatorInfo getDelegatorInfo(String name) {
EntityConfigUtil configUtil = configRef.get();
MapString, DelegatorInfo map = configUtil.delegatorInfos;
DelegatorInfo tmp = map.get(name);
return tmp;
}

And really, instead of using static methods to lookup objects by name,
a container can used to track all this and
lookup those instances when needed. For example,
org.ofbiz.entity.model.ModelReader doesn't have to provide a static
method to be used a factory, so it can keep on tracking instances
created of itself. It's the job of the container.
Same thing applies to caching. We see caching code all over the place.
Code that does the lookup, but checking a
hashtable used as a cache before deciding to create an object.

Cleaning the code, a bit and make it OO, will allow using Aspects for
things like this.

This is what I meant by making the code more OO.

Back again to the subject of ORMs. MyBatis, may be the fastest ORM I
have worked with, compared to JPA (hibernate, EclipseLink, ..etc).
While I didn't do a practical comparison with OfBiz entity engine, I
think ofbiz entity engine is the most optimized, and fastest,
because it's closer to JDBC than any other ORM framework. I am not
sure if any optimization can be with the EE beside cleaning the code
a bit, and refactoring.



On Fri, Mar 23, 2012 at 9:27 AM, Prince Sewani princesew...@ymail.com wrote:

Yeah making it more OO is what I'm actually referring to, OFBiz entity-engine is
a different architecture altogether if we compare it to other existing 
counter-parts like hibernate and

Ibatis, I haven't really looked at the query generation code, but does anyone 
thinks that it needs a

bit more optimization? I know I'm talking at a very high level despite of 
checking out the
implementation, Also for cases where we need to plug-in our queries (And I 
really mean SQL Queries) there should be additional
methods in

GenericDelegator to achieve it, in the current scenario we've to make an 
instace of SQLProcessor to get that done,
I'm not sure, but it must be a singleton as per my understanding, Is there any 
way to get that existing Singleton

in our code using some method, If not we should think of that too, it would 
make OFBiz Entity Engine

superior to its counterparts and that idea of permissions at the entity level 
is awesome!!

P.S. : Anything IOC and Anything JAVA, I'm on it, just let me know what to be 
done.

Regards
Prince




From: Mansour Al Akeel mansour.alak...@gmail.com
To: dev@ofbiz.apache.org; Prince Sewani princesew...@ymail.com
Sent: Friday, March 23, 2012 6:37 PM
Subject: Re: Some ideas to prepare our first community roadmap

For me +1 to refactor.

I am not sure the ORM needs any work. May be I am missing something.
Please let me know what part ?

Just cleaning the entity engine code a bit, and make it more OO, will
make it easier to work with.
For example, I like to add a custom Delegator that will append some
fields to each query and will enforce Row Level Security.
For example, adding something like acl.xml next to the entity
definitions, which contains the rules about the access.
I know Oracle database has what is called virtual Private Database,
and will be nice to have something similar instead of checking for
access control in each service call.
Just looking at the code currently there, makes the idea goes away.
Refactoring the code will make things a bit easier.

Ofbiz currently uses its own container to load all it's component. I
was not able to find a lot of docs. May be missed them.
I don't know if using alternative container is a reasonable suggestion.

I see a lot of documentations and examples about using IoC containers
with tomcat/jetty/geronimo and OSGI.


On Fri, Mar 23, 2012 at 8:18 AM, Prince Sewani princesew...@ymail.com wrote:



+1 to the Refractor, Have a few questions and a few suggestions :
Questions :


Are we looking to improve upon the ORM as well ?

And what about the OSGI stuff, are we planning something on that to enhance the 
plug-in approach?

What's all about the extra stuff? are we just gonna keep 'em separately and 
maintain 'em separately or are we

Re: Some ideas to prepare our first community roadmap


From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com

Hi all,

now that the great community discussion about the Lose Weight Program for OFBiz is settling down (thanks to all of you for the 
great ideas, enthusiasm and participation) we can start to wrap up a roadmap (it would be nice to set it up in Jira, using a 
specific Jira version so that we can keep track of progress together... any ideas for a good name for it?) by listing the 
actionable items and also by considering other topics that may be of interest to the community.


I like Erwan's idea: Slim down easy to remember, I have nothing againt 13 
though, I'm not superstitious at all.

When you believe in things that you don't understand,
Then you suffer,
Superstition ain't the way

Stevie Wonder



This thread is an attempt to integrate the roadmap with some additional tasks 
if the community will consider them a priority.

But first of all, here is the list with a categorization/summary of the tasks 
being discussed so far:

(MOSTLY) ACTIONABLE ITEMS (currently under discussion - once finalized we will 
create tasks in Jira for each):


Sub-tasks of Slim down, right?

* setup a nice page in the OFBiz website to describe the OFBiz Extras ecosystem (external project names will be added there); the 
OFBiz PMC will have to work on this (also check if there is additional paperwork to do)
* move some of the component/code to Extras: we will create individual Jira tasks for each component and then design details (how 
to move) will be discussed in the task; we will need volunteers (committers and not) to contribute patches/commits and also at 
least one maintainer (OFBiz committer or not) for each component


Sub-tasks of Slim down, right? Mmm... Unfortunately Jira has only one level of sub-tasks, we could create another Main task for 
them an relate it to Slim down task


* move some of the component/code to Attic: we will create individual Jira tasks for each removal and then design details (how to 
remove) will be discussed in the tasks; we will need volunteers (committers and not) to contribute patches/commits


Sub-tasks of Slim down, right? Mmm... Unfortunately Jira has only one level of sub-tasks, we could create another Main task for 
them an relate it to Slim down task



The above will form the first part of the roadmap.



The following list is simply my personal attempt to propose some priorities for the community; some of them are based on comments 
from people on the dev list, some of them are personal ideas based on some reviews I did to the OFBiz codebase.
Feel free to add/remove items to the list but please while doing this consider that we are discussing candidate tasks for an OFBiz 
roadmap shared by the community: when the list will be discussed, approved and finalized the community will have a clear roadmap 
to focus on (with all contributions/commits going in this direction); but this also means that the tasks/goals need to be enough 
generic to gather consensus on a larger group of people (otherwise each individual committer will end up proposing her own 
specific item to the list, of less interest to the community, and then she will start working on it... instead of better spending 
the time that she decided to contribute to tasks that the community really considers important) and they shouldn't be too big 
(gathering consensus and implementing as a community will take a lot of time). If we will not find an agreement on some items or a 
large consensus then it will be fine: the roadmap will be lighter and will be completed earlier; at that point we will discuss 
again what we want to do next.
Even if no big tasks will be added to the roadmap, I think it will still be an interesting one focused on maintenance and 
quality.


+1 on QA, and BUG FIXES desesperately waiting to be fixed with patches in Jira 
anxious to not be unusable (contributions lost)

BIG TASKS (these are potentially big tasks that may be difficult to plan in this first roadmap... but it may make sense to try to 
see if we can find an agreement for some actionable tasks)
* resolving framework dependencies on applications (this is *not* about refactoring the framework, simply to resolve its 
dependencies on applications)
* gather requirements (from existing applications), design and implement JCR/Jackrabbit and replace parts of the existing Content 
Framework with it

* discuss, design and implement (if needed) or define best practices for a plug 
in architecture
* discuss, design and implement (if needed) or define best practices for an 
integrated reporting tool for OFBiz


+1

MAINTENANCE, REFACTORING AND CLEANUP (these are task categories that should be easy to include in the roadmap because they don't 
require big design and discussions and are mostly all actionable)

* bug fixes
* automated tests
* migration from Beanshell to Groovy (i.e. continue in the trunk the work 
started in the branch)
* check proper handling of EntityListIterators
* check

[jira] [Closed] (OFBIZ-4458) OnePageCheckout doesn't create purchase order for dropShip product


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-4458.
--

   Resolution: Fixed
Fix Version/s: SVN trunk
   Release Branch 11.04
   Release Branch 10.04
 Assignee: Jacques Le Roux

Thanks Kiran,

Your patch is in 
trunk r1304567  
R11.04 r1304568
R10.04 r1304571

I choose your way, adding CheckoutOptions.groovy would have been an overkill, 
and refactoring risky  



 OnePageCheckout doesn't create purchase order for dropShip product
 --

 Key: OFBIZ-4458
 URL: https://issues.apache.org/jira/browse/OFBIZ-4458
 Project: OFBiz
  Issue Type: Bug
  Components: order, specialpurpose/ecommerce
Affects Versions: Release 10.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

 Attachments: OFBIZ-4458-OnePageCheckoutOptionsGroovy.patch, 
 OFBIZ-4458-OrderScreensXml.patch


 Select a item from drop ship supplier. 
 Perform one page checkout.
 Issue: Purchase order for drop ship supplier is not created

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Closed] (OFBIZ-4525) Category Detail, Out of Stock check doesn't take into account Marketing Package and multiple facilities

2012-03-23 Thread Kiran Gawde (Issue Comment Edited) (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-4525.
--

   Resolution: Fixed
Fix Version/s: SVN trunk
   Release Branch 11.04
   Release Branch 10.04
 Assignee: Jacques Le Roux

Thanks Kiran,

Your patch is in
trunk r1304589  
R11.04 r1304591
R10.04 r1304592



 Category Detail, Out of Stock check doesn't take into account Marketing 
 Package and multiple facilities
 ---

 Key: OFBIZ-4525
 URL: https://issues.apache.org/jira/browse/OFBIZ-4525
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Release Branch 11.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

 Attachments: OFBIZ-4525-CategoryDetailGroovy.patch


 Category Detail, Out of Stock check doesn't take into account Marketing 
 Package and multiple facilities.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (OFBIZ-4458) OnePageCheckout doesn't create purchase order for dropShip product

[
https://issues.apache.org/jira/browse/OFBIZ-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13184623#comment-13184623
]

Kiran Gawde edited comment on OFBIZ-4458 at 3/23/12 9:21 PM:
-

Hello Erwan,

In this case, just pick any item eligible for dropshipment. Add it to
cart. Use 'OnePageCheckout' option.

If you would have used other checkout options, you would see a sales order
and related purchase order. But when you choose the OnePageCheckout it
doesn't creates only sales order and not the purchase order. Let me know
if you need more info.

Let me know which other defect you are looking at and I can try to provide
more details.

Cheers
Kiran

was (Author: kiran_gawde):
Hello Erwan,

In this case, just pick any item eligible for dropshipment (I assume, you
are aware of the drop shipment functionality of ecommerce). Add it to
cart. Use 'OnePageCheckout' option.

Let me know which other defect you are looking at and I can try to provide
more details.

Cheers
Kiran

OnePageCheckout doesn't create purchase order for dropShip product
--

Key: OFBIZ-4458
URL: https://issues.apache.org/jira/browse/OFBIZ-4458
Project: OFBiz
Issue Type: Bug
Components: order, specialpurpose/ecommerce
Affects Versions: Release 10.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

Attachments: OFBIZ-4458-OnePageCheckoutOptionsGroovy.patch,
OFBIZ-4458-OrderScreensXml.patch

Select a item from drop ship supplier.
Perform one page checkout.
Issue: Purchase order for drop ship supplier is not created

[jira] [Commented] (OFBIZ-4458) OnePageCheckout doesn't create purchase order for dropShip product

2012-03-23 Thread Kiran Gawde (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237147#comment-13237147
 ] 

Kiran Gawde commented on OFBIZ-4458:


Thanks!!

 OnePageCheckout doesn't create purchase order for dropShip product
 --

 Key: OFBIZ-4458
 URL: https://issues.apache.org/jira/browse/OFBIZ-4458
 Project: OFBiz
  Issue Type: Bug
  Components: order, specialpurpose/ecommerce
Affects Versions: Release 10.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

 Attachments: OFBIZ-4458-OnePageCheckoutOptionsGroovy.patch, 
 OFBIZ-4458-OrderScreensXml.patch


 Select a item from drop ship supplier. 
 Perform one page checkout.
 Issue: Purchase order for drop ship supplier is not created

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (OFBIZ-4458) OnePageCheckout doesn't create purchase order for dropShip product

2012-03-23 Thread Jacques Le Roux (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-4458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237194#comment-13237194
 ] 

Jacques Le Roux commented on OFBIZ-4458:


Hi Kiran,

More to come, I'm working on your Jiras...

 OnePageCheckout doesn't create purchase order for dropShip product
 --

 Key: OFBIZ-4458
 URL: https://issues.apache.org/jira/browse/OFBIZ-4458
 Project: OFBiz
  Issue Type: Bug
  Components: order, specialpurpose/ecommerce
Affects Versions: Release 10.04, SVN trunk
Reporter: Kiran Gawde
Assignee: Jacques Le Roux
 Fix For: Release Branch 10.04, Release Branch 11.04, SVN trunk

 Attachments: OFBIZ-4458-OnePageCheckoutOptionsGroovy.patch, 
 OFBIZ-4458-OrderScreensXml.patch


 Select a item from drop ship supplier. 
 Perform one page checkout.
 Issue: Purchase order for drop ship supplier is not created

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Junit tests are failing: org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle


Since today the following test is failing:

 org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle

Regards,
Hans

Re: svn commit: r1304369 - in /ofbiz/trunk: ./ framework/ tools/ tools/api-java16/ tools/src/


I am sorry Jacopo,

We have setup automated test systems which apply patches automatically.
i moved the start and stop script back into the root, these are not 
tools but operational scripts


Regards,
Hans




On 03/23/2012 09:26 PM, jaco...@apache.org wrote:

Author: jacopoc
Date: Fri Mar 23 14:26:32 2012
New Revision: 1304369

URL: http://svn.apache.org/viewvc?rev=1304369view=rev
Log:
Moved all platform dependent scripts to the tool folder, with the only exception of the 
ant scripts for unix and windows that are still in the home folder.
Removed a series of unused files (ant extensions).
Removed special handling for hsql db from ant tasks (hsql is no more bundled 
with OFBiz).
Please help testing the scripts as I was only able to run some limited tests on 
my Mac.

Added:
 ofbiz/trunk/tools/applyOfbizPatchesAndHotDeploy.sh   (contents, props 
changed)
   - copied, changed from r1302529, 
ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/tools/ij.ofbiz   (contents, props changed)
   - copied, changed from r1304209, ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/tools/rc.ofbiz   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/tools/rc.ofbiz.for.debian
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/tools/rc.ofbiz.for.ubuntu
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/tools/revert.bat
   - copied unchanged from r1303676, ofbiz/trunk/revert.bat
 ofbiz/trunk/tools/startofbiz.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/tools/startofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/tools/startofbizBoth.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/tools/startofbizPos.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/tools/stopofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/tools/svnUpHotdeploy.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/tools/svnUpHotdeploy.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.sh
Removed:
 ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/revert.bat
 ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/svnUpHotdeploy.sh
 ofbiz/trunk/tools/If-ant.py
 ofbiz/trunk/tools/api-java16/
 ofbiz/trunk/tools/src/
Modified:
 ofbiz/trunk/README
 ofbiz/trunk/build.xml
 ofbiz/trunk/framework/build.xml
 ofbiz/trunk/macros.xml

Modified: ofbiz/trunk/README
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/README?rev=1304369r1=1304368r2=1304369view=diff
==
--- ofbiz/trunk/README (original)
+++ ofbiz/trunk/README Fri Mar 23 14:26:32 2012
@@ -1,16 +1,18 @@

  Welcome to Apache OFBiz!

-If you have a release build all you need to run OFBiz is a
+All you need to run OFBiz is a
  1.6 (version 6) JDK (not just the JRE, the full JDK).
  http://java.sun.com/javase/downloads/index.jsp

-However if you have downloaded ofbiz from SVN then you should
-load the demo data (strongly advised) with the following command
-on the command line: (being in the OFbiz directory)
+You can load the demo data (strongly advised) with the following command
+on the command line: (being in the OFBiz directory)

-linux: ./ant run-install
-windows: ant run-install
+linux/unix/osx:
+./ant run-install
+
+windows:
+ant run-install

  Once that is properly setup just run the executable jar file
  that comes with OFBiz, which is ofbiz.jar. To do this on the
@@ -18,8 +20,17 @@ command line you would run:

  java -Xms128M -Xmx512M -XX:MaxPermSize=128m -jar ofbiz.jar

-Even better use the startup scripts for Windows and Unix-based
-operating systems, namely startofbiz.bat and startofbiz.sh.
+or
+
+linux/unix/osx:
+./ant run
+
+windows:
+ant run
+
+You will also find several platform dependent startup scripts in the tools 
folder
+(for Windows and Unix-based operating systems, the startup scripts are 
startofbiz.bat
+and startofbiz.sh).

  Once OFBiz starts, you can look at the demo storefront at:
  http://localhost:8080/ecommerce

Modified: ofbiz/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/build.xml?rev=1304369r1=1304368r2=1304369view=diff
==
---

Re: svn commit: r1304369 - in /ofbiz/trunk: ./ framework/ tools/ tools/api-java16/ tools/src/


Again sorry Jacopo,

these scripts are important and cannot be changed easily, simply move 
these to the tools folder AND make a number of changes not documented in 
the log message is not the way to go.


Regards,
Hans


On 03/23/2012 09:26 PM, jaco...@apache.org wrote:

Author: jacopoc
Date: Fri Mar 23 14:26:32 2012
New Revision: 1304369

URL: http://svn.apache.org/viewvc?rev=1304369view=rev
Log:
Moved all platform dependent scripts to the tool folder, with the only exception of the 
ant scripts for unix and windows that are still in the home folder.
Removed a series of unused files (ant extensions).
Removed special handling for hsql db from ant tasks (hsql is no more bundled 
with OFBiz).
Please help testing the scripts as I was only able to run some limited tests on 
my Mac.

Added:
 ofbiz/trunk/tools/applyOfbizPatchesAndHotDeploy.sh   (contents, props 
changed)
   - copied, changed from r1302529, 
ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/tools/ij.ofbiz   (contents, props changed)
   - copied, changed from r1304209, ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/tools/rc.ofbiz   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/tools/rc.ofbiz.for.debian
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/tools/rc.ofbiz.for.ubuntu
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/tools/revert.bat
   - copied unchanged from r1303676, ofbiz/trunk/revert.bat
 ofbiz/trunk/tools/startofbiz.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/tools/startofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/tools/startofbizBoth.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/tools/startofbizPos.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/tools/stopofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/tools/svnUpHotdeploy.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/tools/svnUpHotdeploy.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.sh
Removed:
 ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/revert.bat
 ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/svnUpHotdeploy.sh
 ofbiz/trunk/tools/If-ant.py
 ofbiz/trunk/tools/api-java16/
 ofbiz/trunk/tools/src/
Modified:
 ofbiz/trunk/README
 ofbiz/trunk/build.xml
 ofbiz/trunk/framework/build.xml
 ofbiz/trunk/macros.xml

Modified: ofbiz/trunk/README
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/README?rev=1304369r1=1304368r2=1304369view=diff
==
--- ofbiz/trunk/README (original)
+++ ofbiz/trunk/README Fri Mar 23 14:26:32 2012
@@ -1,16 +1,18 @@

  Welcome to Apache OFBiz!

-If you have a release build all you need to run OFBiz is a
+All you need to run OFBiz is a
  1.6 (version 6) JDK (not just the JRE, the full JDK).
  http://java.sun.com/javase/downloads/index.jsp

-However if you have downloaded ofbiz from SVN then you should
-load the demo data (strongly advised) with the following command
-on the command line: (being in the OFbiz directory)
+You can load the demo data (strongly advised) with the following command
+on the command line: (being in the OFBiz directory)

-linux: ./ant run-install
-windows: ant run-install
+linux/unix/osx:
+./ant run-install
+
+windows:
+ant run-install

  Once that is properly setup just run the executable jar file
  that comes with OFBiz, which is ofbiz.jar. To do this on the
@@ -18,8 +20,17 @@ command line you would run:

  java -Xms128M -Xmx512M -XX:MaxPermSize=128m -jar ofbiz.jar

-Even better use the startup scripts for Windows and Unix-based
-operating systems, namely startofbiz.bat and startofbiz.sh.
+or
+
+linux/unix/osx:
+./ant run
+
+windows:
+ant run
+
+You will also find several platform dependent startup scripts in the tools 
folder
+(for Windows and Unix-based operating systems, the startup scripts are 
startofbiz.bat
+and startofbiz.sh).

  Once OFBiz starts, you can look at the demo storefront at:
  http://localhost:8080/ecommerce

Modified: ofbiz/trunk/build.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/build.xml?rev=1304369r1=1304368r2=1304369view=diff
==
---

Re: svn commit: r1304369 - in /ofbiz/trunk: ./ framework/ tools/ tools/api-java16/ tools/src/

Hi Hans,

I'm pretty sure that our committer privileges don't extend to blocking changes 
because they inconvenience us.  The correct thing to do here is to adjust your 
scripts, no one else in the community gets to revert changes simply because it 
causes migration issues for them to deal with.

You also might want to get used to having to make changes to your 
infrastructure if we're finally going to start cleaning up this project.  
Welcome to one of the downsides of running all your deployments against the 
latest trunk.

Regards
Scott

On 24/03/2012, at 1:44 PM, Hans Bakker wrote:

 Again sorry Jacopo,
 
 these scripts are important and cannot be changed easily, simply move these 
 to the tools folder AND make a number of changes not documented in the log 
 message is not the way to go.
 
 Regards,
 Hans
 
 
 On 03/23/2012 09:26 PM, jaco...@apache.org wrote:
 Author: jacopoc
 Date: Fri Mar 23 14:26:32 2012
 New Revision: 1304369
 
 URL: http://svn.apache.org/viewvc?rev=1304369view=rev
 Log:
 Moved all platform dependent scripts to the tool folder, with the only 
 exception of the ant scripts for unix and windows that are still in the 
 home folder.
 Removed a series of unused files (ant extensions).
 Removed special handling for hsql db from ant tasks (hsql is no more bundled 
 with OFBiz).
 Please help testing the scripts as I was only able to run some limited tests 
 on my Mac.
 
 Added:
 ofbiz/trunk/tools/applyOfbizPatchesAndHotDeploy.sh   (contents, props 
 changed)
   - copied, changed from r1302529, 
 ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/tools/ij.ofbiz   (contents, props changed)
   - copied, changed from r1304209, ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/tools/rc.ofbiz   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/tools/rc.ofbiz.for.debian
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/tools/rc.ofbiz.for.ubuntu
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/tools/revert.bat
   - copied unchanged from r1303676, ofbiz/trunk/revert.bat
 ofbiz/trunk/tools/startofbiz.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/tools/startofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/tools/startofbizBoth.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/tools/startofbizPos.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/tools/stopofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/tools/svnUpHotdeploy.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/tools/svnUpHotdeploy.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.sh
 Removed:
 ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/revert.bat
 ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/svnUpHotdeploy.sh
 ofbiz/trunk/tools/If-ant.py
 ofbiz/trunk/tools/api-java16/
 ofbiz/trunk/tools/src/
 Modified:
 ofbiz/trunk/README
 ofbiz/trunk/build.xml
 ofbiz/trunk/framework/build.xml
 ofbiz/trunk/macros.xml
 
 Modified: ofbiz/trunk/README
 URL: 
 http://svn.apache.org/viewvc/ofbiz/trunk/README?rev=1304369r1=1304368r2=1304369view=diff
 ==
 --- ofbiz/trunk/README (original)
 +++ ofbiz/trunk/README Fri Mar 23 14:26:32 2012
 @@ -1,16 +1,18 @@
 
  Welcome to Apache OFBiz!
 
 -If you have a release build all you need to run OFBiz is a
 +All you need to run OFBiz is a
  1.6 (version 6) JDK (not just the JRE, the full JDK).
  http://java.sun.com/javase/downloads/index.jsp
 
 -However if you have downloaded ofbiz from SVN then you should
 -load the demo data (strongly advised) with the following command
 -on the command line: (being in the OFbiz directory)
 +You can load the demo data (strongly advised) with the following command
 +on the command line: (being in the OFBiz directory)
 
 -linux: ./ant run-install
 -windows: ant run-install
 +linux/unix/osx:
 +./ant run-install
 +
 +windows:
 +ant run-install
 
  Once that is properly setup just run the executable jar file
  that comes with OFBiz, which is ofbiz.jar. To do this on the
 @@ -18,8 +20,17 @@ command line you would run:
 
  java -Xms128M -Xmx512M -XX:MaxPermSize=128m -jar ofbiz.jar
 
 -Even better use the startup scripts for

Re: svn commit: r1304369 - in /ofbiz/trunk: ./ framework/ tools/ tools/api-java16/ tools/src/


Scott,

we are using ofbiz trunk in a continuous testing environment to discover 
problems as quick as possible. Against blocking problems discovered 
there, I am going to take actions when somebody commit changes which are:


1. not properly documented in the log message.
2. if there is a structural change which people should know when they 
upgrade which should be documented in:

https://cwiki.apache.org/confluence/display/OFBTECH/Revisions+Requiring+Data+Migration+%28upgrade+ofbiz%29
3. Any structural change which is not properly announced. We need a week 
in advance to update our continuous testing environment.


I hope you understand my position.

Regards,
Hans


On 03/24/2012 10:46 AM, Scott Gray wrote:

Hi Hans,

I'm pretty sure that our committer privileges don't extend to blocking changes 
because they inconvenience us.  The correct thing to do here is to adjust your 
scripts, no one else in the community gets to revert changes simply because it 
causes migration issues for them to deal with.

You also might want to get used to having to make changes to your 
infrastructure if we're finally going to start cleaning up this project.  
Welcome to one of the downsides of running all your deployments against the 
latest trunk.

Regards
Scott

On 24/03/2012, at 1:44 PM, Hans Bakker wrote:


Again sorry Jacopo,

these scripts are important and cannot be changed easily, simply move these to 
the tools folder AND make a number of changes not documented in the log message 
is not the way to go.

Regards,
Hans


On 03/23/2012 09:26 PM, jaco...@apache.org wrote:

Author: jacopoc
Date: Fri Mar 23 14:26:32 2012
New Revision: 1304369

URL: http://svn.apache.org/viewvc?rev=1304369view=rev
Log:
Moved all platform dependent scripts to the tool folder, with the only exception of the 
ant scripts for unix and windows that are still in the home folder.
Removed a series of unused files (ant extensions).
Removed special handling for hsql db from ant tasks (hsql is no more bundled 
with OFBiz).
Please help testing the scripts as I was only able to run some limited tests on 
my Mac.

Added:
 ofbiz/trunk/tools/applyOfbizPatchesAndHotDeploy.sh   (contents, props 
changed)
   - copied, changed from r1302529, 
ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/tools/ij.ofbiz   (contents, props changed)
   - copied, changed from r1304209, ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/tools/rc.ofbiz   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/tools/rc.ofbiz.for.debian
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/tools/rc.ofbiz.for.ubuntu
   - copied unchanged from r1303676, ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/tools/revert.bat
   - copied unchanged from r1303676, ofbiz/trunk/revert.bat
 ofbiz/trunk/tools/startofbiz.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/tools/startofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/tools/startofbizBoth.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/tools/startofbizPos.bat
   - copied, changed from r1303676, ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/tools/stopofbiz.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/tools/svnUpHotdeploy.bat   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/tools/svnUpHotdeploy.sh   (contents, props changed)
   - copied, changed from r1303676, ofbiz/trunk/svnUpHotdeploy.sh
Removed:
 ofbiz/trunk/applyOfbizPatchesAndHotDeploy.sh
 ofbiz/trunk/ij.ofbiz
 ofbiz/trunk/rc.ofbiz
 ofbiz/trunk/rc.ofbiz.for.debian
 ofbiz/trunk/rc.ofbiz.for.ubuntu
 ofbiz/trunk/revert.bat
 ofbiz/trunk/startofbiz.bat
 ofbiz/trunk/startofbiz.sh
 ofbiz/trunk/startofbizBoth.bat
 ofbiz/trunk/startofbizPos.bat
 ofbiz/trunk/stopofbiz.sh
 ofbiz/trunk/svnUpHotdeploy.bat
 ofbiz/trunk/svnUpHotdeploy.sh
 ofbiz/trunk/tools/If-ant.py
 ofbiz/trunk/tools/api-java16/
 ofbiz/trunk/tools/src/
Modified:
 ofbiz/trunk/README
 ofbiz/trunk/build.xml
 ofbiz/trunk/framework/build.xml
 ofbiz/trunk/macros.xml

Modified: ofbiz/trunk/README
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/README?rev=1304369r1=1304368r2=1304369view=diff
==
--- ofbiz/trunk/README (original)
+++ ofbiz/trunk/README Fri Mar 23 14:26:32 2012
@@ -1,16 +1,18 @@

  Welcome to Apache OFBiz!

-If you have a release build all you need to run OFBiz is a
+All you need to run OFBiz is a
  1.6 (version 6) JDK (not just the JRE, the full JDK).
  http://java.sun.com/javase/downloads/index.jsp

-However if you have downloaded ofbiz from

Re: svn commit: r1304369 - in /ofbiz/trunk: ./ framework/ tools/ tools/api-java16/ tools/src/

On Mar 24, 2012, at 1:44 AM, Hans Bakker wrote:

 AND make a number of changes not documented in the log message is not the way 
 to go

The undocumented changes are actually documented by the sentence in my log: 
Moved all platform dependent scripts to the tool folder [...]
In fact the purpose of the changes I did was to make them work in the new 
location: I didn't add or change behavior and so I have actually simply 
documented the commit with that sentence.
I agree I should have better specified what I did with something like:
Moved all platform dependent scripts to the tool folder (and made required 
changes to the scripts) [...]

Jacopo

[jira] [Closed] (OFBIZ-4747) Change misspelled parameter mainSubmited to mainSubmitted

2012-03-23 Thread Erwan de FERRIERES (Closed) (JIRA)


 [ 
https://issues.apache.org/jira/browse/OFBIZ-4747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erwan de FERRIERES closed OFBIZ-4747.
-

Resolution: Fixed

Thanks Markus,

done at rev 1304713

 Change misspelled parameter mainSubmited to mainSubmitted
 -

 Key: OFBIZ-4747
 URL: https://issues.apache.org/jira/browse/OFBIZ-4747
 Project: OFBiz
  Issue Type: Improvement
  Components: order, specialpurpose/ecommerce
Affects Versions: SVN trunk
Reporter: Markus M. May
Assignee: Erwan de FERRIERES
Priority: Trivial
 Fix For: SVN trunk

 Attachments: OFBIZ-4747-fix-typo-for-mainSubmitted-parameter.patch


 In two screen-files (CatalogScreens as well as ShoppingListScreens) and in 
 the corresponding ftl (productsummary.ftl) the parameter mainSubmited is 
 spelled incorrectly. The attached patch spells the parameter correctly 
 (mainSubmitted).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Junit tests are failing: org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle

I have noticed the same... it seems to be related to 1304193

Jacopo

On Mar 24, 2012, at 12:58 AM, Hans Bakker wrote:

 Since today the following test is failing:
 
  org.ofbiz.base.util.test.UtilPropertiesTests.testReadXmlLangNewStyle
 
 Regards,
 Hans

Re: svn commit: r1304369 - in /ofbiz/trunk: ./ framework/ tools/ tools/api-java16/ tools/src/