[
https://issues.apache.org/jira/browse/OFBIZ-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Atul Vani updated OFBIZ-4722:
-
Attachment: OFBIZ-4722.patch
Patch Attached.
> completePack service times out for large
completePack service times out for large orders
---
Key: OFBIZ-4722
URL: https://issues.apache.org/jira/browse/OFBIZ-4722
Project: OFBiz
Issue Type: Bug
Components: product
Re
[
https://issues.apache.org/jira/browse/OFBIZ-4483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221037#comment-13221037
]
Erwan de FERRIERES commented on OFBIZ-4483:
---
Hi Nicolas,
I tested your patch, i
[
https://issues.apache.org/jira/browse/OFBIZ-4686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erwan de FERRIERES closed OFBIZ-4686.
-
Resolution: Fixed
Fix Version/s: SVN trunk
Done at rev 1296209
Thanks Olivier
From: "Erwan de FERRIERES"
Le 02/03/2012 10:21, Jacopo Cappellato a écrit :
In preparation for bigger changes :-) I would like to propose the addition of
two new folders to the OFBiz svn repository:
branches/
tags/
archive/ (NEW)
trunk/
trunk/extras (NEW)
if extras is just for putting code
On Mar 2, 2012, at 1:17 PM, Erwan de FERRIERES wrote:
> Le 02/03/2012 10:21, Jacopo Cappellato a écrit :
>> In preparation for bigger changes :-) I would like to propose the addition
>> of two new folders to the OFBiz svn repository:
>>
>> branches/
>> tags/
>> archive/ (NEW)
>> trunk/
>> trunk
[
https://issues.apache.org/jira/browse/OFBIZ-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220875#comment-13220875
]
Uwe Allner commented on OFBIZ-4535:
---
Yes, it occurs on trunk and demos as well. And not
Le 02/03/2012 10:21, Jacopo Cappellato a écrit :
In preparation for bigger changes :-) I would like to propose the addition of
two new folders to the OFBiz svn repository:
branches/
tags/
archive/ (NEW)
trunk/
trunk/extras (NEW)
if extras is just for putting code not intended to be part of a
Using folders to categorize data is a good idea. I use that pattern now
on large projects that have many files.
-Adrian
On 3/2/2012 12:09 PM, Paul Foxworthy wrote:
Hi all,
I definitely like the basic idea of configuration by exception, but I also
like having separate files for major categorie
Hi all,
I definitely like the basic idea of configuration by exception, but I also
like having separate files for major categories of seed and demo data. If
you wanted to customize OFBiz for a particular purpose, having separate
files makes it easier to include or exclude data.
How about using fi
On Mar 2, 2012, at 11:31 AM, Adrian Crum wrote:
> Btw, on a different but related subject...
>
> Previous discussions about removing dormant components have resulted in a
> decision to just leave the dormant components in the project. If that
> discussion happens again, we need to be clear that
Btw, on a different but related subject...
Previous discussions about removing dormant components have resulted in
a decision to just leave the dormant components in the project. If that
discussion happens again, we need to be clear that the component removal
is motivated by a planned framewor
Yes... you are both convincing me that deleting would be better: in fact this
would be easier if we want to remove a part of a component (it would be
difficult to move the code to "archive").
And the initial cleanup and version of the Confluence page could be based on
the content of this file:
Then also nstruction in main README file
Both are ok with me, but maybe less work by getting rid of hashes indeed...
Jacques
From: "Adrian Crum"
We could have an "archived components" page on the wiki to describe all of that.
-Adrian
On 3/2/2012 9:33 AM, Jacopo Cappellato wrote:
On Mar 2,
+1
We need to clarify what to put in archive, for instance specialpurpose/workflow
to add, etc.
Also what is the future of webslinger? (hého BrainFood :o)
Jacques
From: "Jacopo Cappellato"
In preparation for bigger changes :-) I would like to propose the addition of
two new folders to the
We could have an "archived components" page on the wiki to describe all
of that.
-Adrian
On 3/2/2012 9:33 AM, Jacopo Cappellato wrote:
On Mar 2, 2012, at 10:26 AM, Adrian Crum wrote:
I don't understand the need for the archive folder. If we just remove unused
code, then anyone wanting to re
I tend to agree...
Jacques
From: "Jacopo Cappellato"
Moving to the dev list:
On Mar 1, 2012, at 11:51 AM, Erwan de FERRIERES wrote:
what I'm planning to include is just the basics : jars and tasks. Maybe some tests as an example, like a basic login, and some
actions with the example compone
I always review site commits, it's so easier: no excuses.
So do I with the wiki, but I feel it's easier beause reading Confluence changes is often more legible than svn commits (or because I
like colors and such?)
This said I had to learn Confluence, was not so bovious at start, when ... svn is
On Mar 2, 2012, at 10:26 AM, Adrian Crum wrote:
> I don't understand the need for the archive folder. If we just remove unused
> code, then anyone wanting to resurrect it can just check out a previous
> revision that included it.
This is definitely true but I was thinking that it may be easier
I don't understand the need for the archive folder. If we just remove
unused code, then anyone wanting to resurrect it can just check out a
previous revision that included it.
I like the idea of moving some of the specialpurpose components outside
the main project.
-Adrian
On 3/2/2012 9:21
In preparation for bigger changes :-) I would like to propose the addition of
two new folders to the OFBiz svn repository:
branches/
tags/
archive/ (NEW)
trunk/
trunk/extras (NEW)
The "archive" folder will be used for keeping an archive of no more used
components or pieces of code: for example
On 3/2/2012 8:28 AM, Jacopo Cappellato wrote:
In order of preference (descending), here are the options I see for the future
of the OFBiz framework:
1) develop a great Apache OFBiz framework 2.0 within the OFBiz community; then
release it separately from the Apache OFBiz ERP
This is the appr
On Mar 2, 2012, at 7:50 AM, Hans Bakker wrote:
> Jacopo,
>
> You would even consider forking?
From Wikipedia [*]:
"[...] More recently, distributed revision control (DVCS) tools have
popularised a less emotive use of the term "fork", blurring the distinction
with "branch". With a DVCS such a
You are right Adrian... actually this would be the last thing to touch but we
could use a different convention like:
data/_seed.xml
data/_demo.xml
or more simply:
data/seed.xml
data/demo.xml
(where the filename is the reader name) and then consider to merge all seed
records in _seed.xml and a
I don't think we can eliminate the seed/demo data readers. In most
cases, data loading must be done in a certain order.
-Adrian
On 3/1/2012 2:53 PM, Jacopo Cappellato wrote:
A decent description of the "Configuration By Exception" concept is the
following [*]:
"Java EE 5 introduced the idea
25 matches
Mail list logo
