date:20160719


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

Suraj Khurana updated OFBIZ-7905:
-
Attachment: OFBIZ-7905.patch

Attached patch with required changes.

> Remove system generated fields - Scrum
> --
>
> Key: OFBIZ-7905
> URL: https://issues.apache.org/jira/browse/OFBIZ-7905
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7905.patch
>
>
> Remove all system generated fields from scrum component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7903) Remove system generated fields - Marketing


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

Suraj Khurana updated OFBIZ-7903:
-
Attachment: OFBIZ-7903.patch

Attached patch with required changes.

> Remove system generated fields - Marketing
> --
>
> Key: OFBIZ-7903
> URL: https://issues.apache.org/jira/browse/OFBIZ-7903
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: marketing
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7903.patch
>
>
> Remove all system generated fields from marketing component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7904) Remove system generated fields - Product


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

Suraj Khurana updated OFBIZ-7904:
-
Attachment: OFBIZ-7904.patch

Attached patch with required changes.

> Remove system generated fields - Product
> 
>
> Key: OFBIZ-7904
> URL: https://issues.apache.org/jira/browse/OFBIZ-7904
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: product
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7904.patch
>
>
> Remove all system generated fields from product component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7902) Remove system generated fields - Ecommerce


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

Suraj Khurana updated OFBIZ-7902:
-
Attachment: OFBIZ-7902.patch

Attached patch with required changes.

> Remove system generated fields - Ecommerce
> --
>
> Key: OFBIZ-7902
> URL: https://issues.apache.org/jira/browse/OFBIZ-7902
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/ecommerce
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7902.patch
>
>
> Remove all system generated fields from ecommerce component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7902) Remove system generated fields - Ecommerce


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

Suraj Khurana updated OFBIZ-7902:
-
Affects Version/s: Trunk

> Remove system generated fields - Ecommerce
> --
>
> Key: OFBIZ-7902
> URL: https://issues.apache.org/jira/browse/OFBIZ-7902
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/ecommerce
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7902.patch
>
>
> Remove all system generated fields from ecommerce component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7902) Remove system generated fields - Ecommerce


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

Suraj Khurana updated OFBIZ-7902:
-
Component/s: specialpurpose/ecommerce

> Remove system generated fields - Ecommerce
> --
>
> Key: OFBIZ-7902
> URL: https://issues.apache.org/jira/browse/OFBIZ-7902
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/ecommerce
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7902.patch
>
>
> Remove all system generated fields from ecommerce component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7901) Remove system generated fields - Content


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

Suraj Khurana updated OFBIZ-7901:
-
Attachment: OFBIZ-7901.patch

Attached patch with required changes.

> Remove system generated fields - Content
> 
>
> Key: OFBIZ-7901
> URL: https://issues.apache.org/jira/browse/OFBIZ-7901
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: content
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Suraj Khurana
>Priority: Minor
> Attachments: OFBIZ-7901.patch
>
>
> Remove all system generated fields from content component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Entity and Service definition

2016-07-19 Thread Divesh Dutta

Very good initiative.

Thanks
--
Divesh Dutta .

On Sun, Jul 17, 2016 at 6:00 PM, Rishi Solanki 
wrote:

> Starter effort on this under - OFBIZ-7828. Community review / feedback /
> suggestion / concerns are welcome.
>
> Thanks!
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Thu, Jul 14, 2016 at 9:58 AM, Rishi Solanki 
> wrote:
>
> > Thank you everyone for your approval and suggestion. We would try to
> > follow most, and log Jira accordingly. Soon will start on this.
> >
> > Nicolas, thanks for pointing expire action on entity-auto.
> >
> > Jacques, Pierre, thanks for suggestion on managing Jira tickets, and you
> > guys anyways helped us in our last effort in managing Jira tickets and
> > review. Thanks for that.
> >
> > Plan is something like this, we would pick the easy entities first where
> > we found minimum changes. After delivering few we will be able to
> establish
> > practice internally, on what items we should take care before fixing an
> > entity/service. We would like to go slow initially, and as soon as we
> start
> > on it delivery process will more clear.
> >
> >
> > Thanks again for your help, and looking forward for same in the big
> effort
> > planned.
> >
> >
> >
> > Rishi Solanki
> > Manager, Enterprise Software Development
> > HotWax Systems Pvt. Ltd.
> > Direct: +91-9893287847
> > http://www.hotwaxsystems.com
> >
> > On Wed, Jul 13, 2016 at 2:36 PM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >
> >> Le 13/07/2016 à 09:39, Pierre Smits a écrit :
> >>
> >>> At this moment in time, I can't fathom how much effort is involved in
> >>> this
> >>> factoring, but I suggest to break it down as much as possible into
> >>> separate
> >>> JIRA issues. For instance, the rework on the removal of the
> >>> OrderHeaderNoteView
> >>> and OrderItemAndShipGroupAssoc from the OrderHeader entity can be a
> >>> separate issue. Please be aware, that this might have a big impact in
> >>> various functions/services/etc.
> >>>
> >>> Best regards,
> >>>
> >>> Pierre Smits
> >>>
> >> That's a good advice Pierre, from what I have seen these last months
> from
> >> the HW effort, I'm confident they are totally aware of what to do :)
> >>
> >> Jacques
> >>
> >>
> >
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

Hi Pierre, all,

I think perhaps my proposal was short and therefore your understanding of
it is a bit different than what I had in mind. So I list below more
specifically what I mean about each point from the ones you mentioned above
to further fine-tune the discussion.

- The difference between createComponent and createPlugin is that the
plugin resides in /plugins instead of hot-deploy and added to
component-load.xml and also contains a build.gradle file designed
specifically for plugins. This script contains standard tasks like install,
uninstall, perhaps even upgrade. The magic work for plugins will be in
their build scripts to integrate tightly with OFBiz.

- The activate/deactivate tasks are just a little convenience tasks that
add/remove components to the component-load.xml instead of editing it by
hand so it is just using what exists. Gradle completely ignores a component
if it does not exist in component-load.xml and would not even compile it.
So you can think of this as just providing more ease to the end-user,
similar to your suggestion with the createComponent.

- The install/uninstall tasks are not just a copy-paste of folders. It
actually executes business logic (optionally) for any plugin author who
wishes to execute it (by calling specific tasks in build.gradle for that
plugin). For example, it might apply patches on some core applications (and
reverse patches in case of uninstall). Now our standard plugins do not
touch applications or framework, but since we are introducing this feature
I'm trying to also combine a unified solution for all plugins (Apache
supported and 3rd party). So in one shot we have both ease of use for the
existing components and at the same time a general purpose plugin system.
We might even have a task like say "updatePlugin" in the future and it is
also possible to introduce rudimentary dependency management (Gradle is
really good at this).

Finally, what to do about specialpurpose is something we should definitely
tackle, however what I am suggesting right now is some foundational work
that gives you easy choices when you need to make them, and it has the
added bonus of introducing a plugin system for OFBiz which is badly needed
to protect the core framework and applications and to provide an eco-system
around it. I'm trying to reach a win-win solution if you will.

Regards,

Taher Alkhateeb

On Wed, Jul 20, 2016 at 1:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :
>
>> the graph needs to be checked/amended to possibly remove components
>> dependencies only introduced by the data model
>>
> Sorry, I have noticed I have the bad tendency of using the word
> "introduced" instead of "put" or "add" (due to "introduire" false friend in
> French) please replace for me when you see it, thanks! :)
> Here the right word would have been "due to" instead of "introduced by"
>
> Jacques
>
> PS: http://www.etymonline.com/index.php?term=introduction
>
>

[jira] [Updated] (OFBIZ-7869) Improvements in AgreementTermAttribute entity definition and services

2016-07-19 Thread Chinmay Patidar (JIRA)


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

Chinmay Patidar updated OFBIZ-7869:
---
Attachment: OFBIZ-7869.patch

> Improvements in AgreementTermAttribute entity definition and services
> -
>
> Key: OFBIZ-7869
> URL: https://issues.apache.org/jira/browse/OFBIZ-7869
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Reporter: Arun Patidar
>Assignee: Chinmay Patidar
>Priority: Minor
> Attachments: OFBIZ-7869.patch
>
>
> Required improvements;
>  - All is good with entity definition .
>  - Add CRUD services using entity-auto. Make sure PK is not optional while 
> create service as there is composite primary key.
>  - Do related changes if any occurrence found for direct create/update/delete 
> of this entity, and replace them with crud services implemented.
>  - As no status/from date/thru date exists in entity, so nothing needs to be 
> taken care while deleting the records from service.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7869) Improvements in AgreementTermAttribute entity definition and services

2016-07-19 Thread Chinmay Patidar (JIRA)


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

Chinmay Patidar updated OFBIZ-7869:
---
Attachment: (was: OFBIZ-7869.patch)

> Improvements in AgreementTermAttribute entity definition and services
> -
>
> Key: OFBIZ-7869
> URL: https://issues.apache.org/jira/browse/OFBIZ-7869
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Reporter: Arun Patidar
>Assignee: Chinmay Patidar
>Priority: Minor
>
> Required improvements;
>  - All is good with entity definition .
>  - Add CRUD services using entity-auto. Make sure PK is not optional while 
> create service as there is composite primary key.
>  - Do related changes if any occurrence found for direct create/update/delete 
> of this entity, and replace them with crud services implemented.
>  - As no status/from date/thru date exists in entity, so nothing needs to be 
> taken care while deleting the records from service.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7758) jquery.jgrowl.min.css is linked twice in html page

2016-07-19 Thread Rohit Koushal (JIRA)


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

Rohit Koushal reassigned OFBIZ-7758:


Assignee: Rohit Koushal

> jquery.jgrowl.min.css is linked twice in html page
> --
>
> Key: OFBIZ-7758
> URL: https://issues.apache.org/jira/browse/OFBIZ-7758
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL APPLICATIONS
>Affects Versions: Trunk
>Reporter: james yong
>Assignee: Rohit Koushal
>Priority: Minor
> Attachments: OFBIZ-7758.patch
>
>
> I am running on trunk rev 1751489 on tomahawk theme.
> In the browser, right-click and view the page source. There is duplicate 
> linking of jquery.jgrowl.min.css i.e.
> {code}
>  href="/images/jquery/plugins/jquery-jgrowl/1.4.1/jquery.jgrowl.min.css" 
> type="text/css"/>
>  href="/images/jquery/plugins/jquery-jgrowl/1.4.1/jquery.jgrowl.min.css" 
> type="text/css"/>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-7869) Improvements in AgreementTermAttribute entity definition and services

2016-07-19 Thread Chinmay Patidar (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15380750#comment-15380750
 ] 

Chinmay Patidar edited comment on OFBIZ-7869 at 7/20/16 5:02 AM:
-

Providing the patch for the improvement needed for AgreementTermAttribute 
entity. Also verified the changes from webtools. Thanks [~arunpati] for the 
detailed explanation.


was (Author: chinmay.patidar):
Providing the patch for the improvement needed for AgreementTermAttribute 
entity. Also verified the changes from webtools. Thanks [~rishisolankii] for 
the detailed explanation.

> Improvements in AgreementTermAttribute entity definition and services
> -
>
> Key: OFBIZ-7869
> URL: https://issues.apache.org/jira/browse/OFBIZ-7869
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Reporter: Arun Patidar
>Assignee: Chinmay Patidar
>Priority: Minor
> Attachments: OFBIZ-7869.patch
>
>
> Required improvements;
>  - All is good with entity definition .
>  - Add CRUD services using entity-auto. Make sure PK is not optional while 
> create service as there is composite primary key.
>  - Do related changes if any occurrence found for direct create/update/delete 
> of this entity, and replace them with crud services implemented.
>  - As no status/from date/thru date exists in entity, so nothing needs to be 
> taken care while deleting the records from service.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-7538) Add Wiki page for WebSocket usage


[ 
https://issues.apache.org/jira/browse/OFBIZ-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385248#comment-15385248
 ] 

Amardeep Singh Jhajj edited comment on OFBIZ-7538 at 7/20/16 3:19 AM:
--

Yes Jacques, it has full chance :). Yesterday I thought to start on it, so i 
checked that WebSocket example working or not now after lot of trunk changes. 
And I found that it is stop working now. I didn't get much time to investigate 
the cause, I will log child jira task in OFBIZ-7073 or may be independent task. 
Once this issue fixed, i will move further on wiki page.


was (Author: amardeepsj):
Yes Jacques, it has full chance :). Yesterday I thought to start on it, so i 
checked that WebSocket example working or not now after lot of trunk changes. 
And I found that it is stop working now. I didn't get much time to investigate 
the cause, I will log child jira task in OFBIZ-7073. Once this issue fixed, i 
will move further on wiki page.

> Add Wiki page for WebSocket usage
> -
>
> Key: OFBIZ-7538
> URL: https://issues.apache.org/jira/browse/OFBIZ-7538
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7538) Add Wiki page for WebSocket usage


[ 
https://issues.apache.org/jira/browse/OFBIZ-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15385248#comment-15385248
 ] 

Amardeep Singh Jhajj commented on OFBIZ-7538:
-

Yes Jacques, it has full chance :). Yesterday I thought to start on it, so i 
checked that WebSocket example working or not now after lot of trunk changes. 
And I found that it is stop working now. I didn't get much time to investigate 
the cause, I will log child jira task in OFBIZ-7073. Once this issue fixed, i 
will move further on wiki page.

> Add Wiki page for WebSocket usage
> -
>
> Key: OFBIZ-7538
> URL: https://issues.apache.org/jira/browse/OFBIZ-7538
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proposal to modify the testing framework for OFBiz

2016-07-19 Thread Ron Wheeler


I think that your point was well received.
I am just happy that testing is getting attention.

Ron

On 19/07/2016 7:53 PM, Scott Gray wrote:

I'm not looking for any sort of response really.  I was just speaking in
favor of integration tests because I think they provide better coverage at
the cost of a little bit of speed (the framework has to be running to run
them).  Most of the responses coming in were of the form "unit tests are
great because [insert a reason that applies to any type of test]".  So I
was merely pointing out that the arguments weren't specific to unit tests
and hence weren't really adding value to the discussion.

Regards
Scott

On 20 July 2016 at 02:05, Ron Wheeler 
wrote:


It is not clear what you are expecting as a specific response.

As you move up the food chain, the definition of "units" changes and the
tests get more complicated and the design of the tests gets more complex
(mock objects, testing race conditions).

It is hard to make specific comments about what kind of testing will give
the highest level of confidence at each level but we are going in the right
direction.

The fact that we are considering tests as a major development activity is
a big step forward.

We can argue about specific cases (scope, tools, value, etc) as we get to
them.

I think that we are at the "good idea" stage rather than at the "policy"
stage at this point.

Ron



On 19/07/2016 4:23 AM, Scott Gray wrote:


I think people are missing my point because they keep replying with
generic
statements that aren't specific to unit tests.

On 19 July 2016 at 20:08, Montalbano Florian <
florian.montalb...@nereide.fr>
wrote:

Hi everyone,

unit tests and integration tests are complementary and with test, the
more
the better.
Implementing unit tests will be a great load of work but it is the same
with every kind of test. As Taher said, we will gain a lot from those
unit
tests for avoiding regression while refactoring the framework. From the
start component scope, it has already be proved useful.
And what Ron said about encouraging the creation of "smaller class that
can be tested easily" is very important too. It can be a first step to
reach TDD in the OFBiz development. TDD can help to give confidence to
newcomer and veteran when updating some part of the code and as Hans
said,
this lead to "continuous improvement and finally continuous deployment".

I'm aware that this does not solve the technical implementation stuff,
but
I think this is an improvement that need to be supported.

Have a nice day,

Florian Montalbano


Le 19/07/2016 09:04, Pierre Smits a écrit :

As with anything, the law of diminishing returns also applies to OFBiz

and
tests. This is not true for unit tests and system integration tests, but
also for user acceptance and performance tests.

Nevertheless, the work done up to now is a good start and - I feel
confident - appreciated. And unit tests are certainly valuable in the
framework stack. How it will be for functions (regarding components in
application and special purpose stack) needs to be addressed when we
reach
that bridge.


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:

Hi Scott,

Well spoken thank you. Okay may I suggest that for any such work we
will
discuss it here see its Merit and if it makes sense then we take it in.
It
is a little early to discuss it right now because we did not yet go to
the
higher-level components. Once we do I'll be sure to have a conversation
about this in here and would appreciate your input to it.

Regards,

Taher Alkhateeb

On Jul 19, 2016 9:00 AM, "Scott Gray" 
wrote:

Yeah I'm sure unit tests probably worked well for the start component
given

it is the lowest level component in the system and closest to a basic

java

app.  I just think the value proposition might decrease the further up

the

stack we move with them.  I'm not against unit tests when they prove

useful, but further up the stack I think we should prove the case for

them

before doing much work to support the mocking that will be required to

keep

them inline with 'best practices'.

In OFBiz "bad or unwanted" tends to come mostly in the way of
increasing
complexity from features that require more effort to maintain than the
value they provide to the community.  I think there's a chance
attempting
to mock service tests could fall into that bucket.  I could be wrong,

but I

think it's worth looking into before we declare that unit tests are the

best form of testing for OFBiz.

Regards
Scott

On 19 July 2016 at 17:37, Taher Alkhateeb

Re: Proposal to modify the testing framework for OFBiz

2016-07-19 Thread Scott Gray

I'm not looking for any sort of response really.  I was just speaking in
favor of integration tests because I think they provide better coverage at
the cost of a little bit of speed (the framework has to be running to run
them).  Most of the responses coming in were of the form "unit tests are
great because [insert a reason that applies to any type of test]".  So I
was merely pointing out that the arguments weren't specific to unit tests
and hence weren't really adding value to the discussion.

Regards
Scott

On 20 July 2016 at 02:05, Ron Wheeler 
wrote:

> It is not clear what you are expecting as a specific response.
>
> As you move up the food chain, the definition of "units" changes and the
> tests get more complicated and the design of the tests gets more complex
> (mock objects, testing race conditions).
>
> It is hard to make specific comments about what kind of testing will give
> the highest level of confidence at each level but we are going in the right
> direction.
>
> The fact that we are considering tests as a major development activity is
> a big step forward.
>
> We can argue about specific cases (scope, tools, value, etc) as we get to
> them.
>
> I think that we are at the "good idea" stage rather than at the "policy"
> stage at this point.
>
> Ron
>
>
>
> On 19/07/2016 4:23 AM, Scott Gray wrote:
>
>> I think people are missing my point because they keep replying with
>> generic
>> statements that aren't specific to unit tests.
>>
>> On 19 July 2016 at 20:08, Montalbano Florian <
>> florian.montalb...@nereide.fr>
>> wrote:
>>
>> Hi everyone,
>>>
>>> unit tests and integration tests are complementary and with test, the
>>> more
>>> the better.
>>> Implementing unit tests will be a great load of work but it is the same
>>> with every kind of test. As Taher said, we will gain a lot from those
>>> unit
>>> tests for avoiding regression while refactoring the framework. From the
>>> start component scope, it has already be proved useful.
>>> And what Ron said about encouraging the creation of "smaller class that
>>> can be tested easily" is very important too. It can be a first step to
>>> reach TDD in the OFBiz development. TDD can help to give confidence to
>>> newcomer and veteran when updating some part of the code and as Hans
>>> said,
>>> this lead to "continuous improvement and finally continuous deployment".
>>>
>>> I'm aware that this does not solve the technical implementation stuff,
>>> but
>>> I think this is an improvement that need to be supported.
>>>
>>> Have a nice day,
>>>
>>> Florian Montalbano
>>>
>>>
>>> Le 19/07/2016 09:04, Pierre Smits a écrit :
>>>
>>> As with anything, the law of diminishing returns also applies to OFBiz
 and
 tests. This is not true for unit tests and system integration tests, but
 also for user acceptance and performance tests.

 Nevertheless, the work done up to now is a good start and - I feel
 confident - appreciated. And unit tests are certainly valuable in the
 framework stack. How it will be for functions (regarding components in
 application and special purpose stack) needs to be addressed when we
 reach
 that bridge.


 Best regards,

 Pierre Smits

 ORRTIZ.COM 
 OFBiz based solutions & services

 OFBiz Extensions Marketplace
 http://oem.ofbizci.net/oci-2/

 On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb <
 slidingfilame...@gmail.com

 wrote:
> Hi Scott,
>
> Well spoken thank you. Okay may I suggest that for any such work we
> will
> discuss it here see its Merit and if it makes sense then we take it in.
> It
> is a little early to discuss it right now because we did not yet go to
> the
> higher-level components. Once we do I'll be sure to have a conversation
> about this in here and would appreciate your input to it.
>
> Regards,
>
> Taher Alkhateeb
>
> On Jul 19, 2016 9:00 AM, "Scott Gray" 
> wrote:
>
> Yeah I'm sure unit tests probably worked well for the start component
> given
>
> it is the lowest level component in the system and closest to a basic
>>
>> java
>
> app.  I just think the value proposition might decrease the further up
>>
>> the
>
> stack we move with them.  I'm not against unit tests when they prove
>> useful, but further up the stack I think we should prove the case for
>>
>> them
>
> before doing much work to support the mocking that will be required to
>>
>> keep
>
> them inline with 'best practices'.
>>
>> In OFBiz "bad or unwanted" tends to come mostly in the way of
>> increasing
>> complexity from features that require more effort to maintain than the
>> value they provide to the community.  I think there's a chance
>> attempting
>> to mock service

[jira] [Commented] (OFBIZ-7538) Add Wiki page for WebSocket usage


[ 
https://issues.apache.org/jira/browse/OFBIZ-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384981#comment-15384981
 ] 

Jacques Le Roux commented on OFBIZ-7538:


Any chances ;) ?

> Add Wiki page for WebSocket usage
> -
>
> Key: OFBIZ-7538
> URL: https://issues.apache.org/jira/browse/OFBIZ-7538
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Groovy book and more


Hi Devs,

I'd like to add a book (or books) about the Groovy language in our wiki books 
page. What would you recommend?

Also I think we should refresh this page, for instance a book about Gradle, etc.

Ideas?

Jacques

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk


Le 19/07/2016 à 22:57, Jacques Le Roux a écrit :
the graph needs to be checked/amended to possibly remove components  dependencies only introduced by the data model 
Sorry, I have noticed I have the bad tendency of using the word "introduced" instead of "put" or "add" (due to "introduire" false friend in French) 
please replace for me when you see it, thanks! :)

Here the right word would have been "due to" instead of "introduced by"

Jacques

PS: http://www.etymonline.com/index.php?term=introduction

[jira] [Commented] (OFBIZ-7677) Update documentation with respect to implementation of gradle as a replacement of ant


[ 
https://issues.apache.org/jira/browse/OFBIZ-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384944#comment-15384944
 ] 

Jacques Le Roux commented on OFBIZ-7677:


Let's face it, who is really sufficiently interested to get her/his hands dirty?

> Update documentation with respect to implementation of gradle as a 
> replacement of ant
> -
>
> Key: OFBIZ-7677
> URL: https://issues.apache.org/jira/browse/OFBIZ-7677
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: site
>Reporter: Pierre Smits
>
> Documentation must be updated before any release, that will have the 
> replacement of ant in place, can be cut.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (OFBIZ-7677) Update documentation with respect to implementation of gradle as a replacement of ant


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

Jacques Le Roux updated OFBIZ-7677:
---
Comment: was deleted

(was: Let's face it, who is really sufficiently interested to get her/his hands 
dirty?)

> Update documentation with respect to implementation of gradle as a 
> replacement of ant
> -
>
> Key: OFBIZ-7677
> URL: https://issues.apache.org/jira/browse/OFBIZ-7677
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: site
>Reporter: Pierre Smits
>
> Documentation must be updated before any release, that will have the 
> replacement of ant in place, can be cut.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7906) Have a gradle build file for the cmssite component


[ 
https://issues.apache.org/jira/browse/OFBIZ-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384946#comment-15384946
 ] 

Jacques Le Roux commented on OFBIZ-7906:


Let's face it, who is really sufficiently interested to get her/his hands dirty?

> Have a gradle build file for the cmssite component
> --
>
> Key: OFBIZ-7906
> URL: https://issues.apache.org/jira/browse/OFBIZ-7906
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/cmssite
>Reporter: Pierre Smits
>Assignee: Pierre Smits
> Attachments: OFBIZ-7906-cmssite.patch
>
>
> The cmssite component uses a specific set of external libraries. These were 
> removed as a result of the migration from Ant to Gradle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7906) Have a gradle build file for the cmssite component


[ 
https://issues.apache.org/jira/browse/OFBIZ-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384939#comment-15384939
 ] 

Jacques Le Roux commented on OFBIZ-7906:


Pierre, we can re-add that, but I think we should 1st question the dev ML if we 
really want to keep the webhelp work. It's a heartbreak for me to remove this 
work because I remember the hard work we did with Tom (Burns) but we have a 
stale branch for years in repo which got any chances to be enhanced. I know 
Sharan and the Nereides team have their own version, so it might be interesting 
to have their opinions

For those interested 
https://issues.apache.org/jira/browse/OFBIZ-6644?jql=project%20%3D%20OFBIZ%20AND%20text%20~%20%22webhelp%22%20ORDER%20BY%20updated%20DESC



> Have a gradle build file for the cmssite component
> --
>
> Key: OFBIZ-7906
> URL: https://issues.apache.org/jira/browse/OFBIZ-7906
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/cmssite
>Reporter: Pierre Smits
>Assignee: Pierre Smits
> Attachments: OFBIZ-7906-cmssite.patch
>
>
> The cmssite component uses a specific set of external libraries. These were 
> removed as a result of the migration from Ant to Gradle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7907) Move jsgantt files from images to projectmgr component


[ 
https://issues.apache.org/jira/browse/OFBIZ-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384921#comment-15384921
 ] 

Jacques Le Roux commented on OFBIZ-7907:


This makes sense Pierre, but remember we can't move file in patch with respect 
of svn. I'll do the task by hand, thanks!

> Move jsgantt files from images to projectmgr component
> --
>
> Key: OFBIZ-7907
> URL: https://issues.apache.org/jira/browse/OFBIZ-7907
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework, specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
> Attachments: OFBIZ-7907-jsgantt.patch
>
>
> Currently the jsgantt files (css and js) are only used by the projectmgr 
> component, but the files are included in the image component in the framework 
> stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7907) Move jsgantt files from images to projectmgr component


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

Jacques Le Roux reassigned OFBIZ-7907:
--

Assignee: Jacques Le Roux  (was: Pierre Smits)

> Move jsgantt files from images to projectmgr component
> --
>
> Key: OFBIZ-7907
> URL: https://issues.apache.org/jira/browse/OFBIZ-7907
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework, specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
> Attachments: OFBIZ-7907-jsgantt.patch
>
>
> Currently the jsgantt files (css and js) are only used by the projectmgr 
> component, but the files are included in the image component in the framework 
> stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1753400 - /ofbiz/trunk/build.gradle


Actually, among other editors, the Eclipse plugin "Gradle Minimal Editor" does 
that on my machine (change EOLs from LF to CRLF)

But that's no longer a problem since I committed the change at r1753367 *AND 
changed the file on my machine*

For those interested this is well explained at the bottom of 
http://svnbook.red-bean.com/en/1.7/svn.advanced.props.file-portability.html

I invite committers and contributors to update their own file

Thanks

Jacques

Le 19/07/2016 à 18:04, jler...@apache.org a écrit :

Author: jleroux
Date: Tue Jul 19 16:04:30 2016
New Revision: 1753400

URL: http://svn.apache.org/viewvc?rev=1753400=rev
Log:
No functional change, only EOLs from CRLF to LF
Again CRLF from my machine, this is done directly in the repo!

Modified:
 ofbiz/trunk/build.gradle

Modified: ofbiz/trunk/build.gradle
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=1753400=1753399=1753400=diff
==
--- ofbiz/trunk/build.gradle (original)
+++ ofbiz/trunk/build.gradle Tue Jul 19 16:04:30 2016
@@ -1,859 +1,859 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-import org.apache.tools.ant.filters.ReplaceTokens
-
-/* 
- * Project setup
- *  */
-
-apply plugin: 'java'
-apply plugin: 'eclipse'
-
-apply from: 'common.gradle'
-
-// java settings
-def jvmArguments = ['-Xms128M', '-Xmx512M']
-ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start'
-javadoc.failOnError = false
-sourceCompatibility = '1.8'
-targetCompatibility = '1.8'
-
-// root and subproject settings
-defaultTasks 'build'
-
-allprojects {
-repositories{
-jcenter()
-}
-}
-
-subprojects {
-configurations {
-// compile-time plugin libraries
-pluginLibsCompile
-// runtime plugin libraries
-pluginLibsRuntime
-}
-}
-
-configurations {
-junitLibs
-}
-
-dependencies {
-// general framework libs
-compile 'apache-xerces:resolver:2.9.1'
-compile 'apache-xerces:xercesImpl:2.9.1'
-compile 'avalon-framework:avalon-framework-impl:4.2.0'
-compile 'bouncycastle:bouncycastle-jce-jdk13:112'
-compile 'com.fasterxml.jackson.core:jackson-annotations:2.4.0'
-compile 'com.fasterxml.jackson.core:jackson-core:2.4.2'
-compile 'com.google.guava:guava:19.0'
-compile 'com.google.zxing:core:3.2.1'
-compile 
'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.0'
-compile 
'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:20160628.1'
-compile 'com.ibm.icu:icu4j:57.1'
-compile 'com.lowagie:itext:2.1.7'
-compile 'com.sun.mail:javax.mail:1.5.1'
-compile 'com.sun.syndication:com.springsource.com.sun.syndication:0.9.0'
-compile 'com.thoughtworks.xstream:xstream:1.4.9'
-compile 'commons-beanutils:commons-beanutils-core:1.8.3'
-compile 'commons-cli:commons-cli:1.3.1'
-compile 'commons-codec:commons-codec:1.10'
-compile 'commons-el:commons-el:1.0'
-compile 'commons-fileupload:commons-fileupload:1.3.1'
-compile 'commons-io:commons-io:2.4'
-compile 'commons-logging:commons-logging:1.2'
-compile 'commons-net:commons-net:3.3'
-compile 'commons-validator:commons-validator:1.5.1'
-compile 'de.odysseus.juel:juel-impl:2.2.7'
-compile 'de.odysseus.juel:juel-spi:2.2.7'
-compile 'httpunit:httpunit:1.7'
-compile 'javax.el:javax.el-api:3.0.1-b04'
-compile 'javax.servlet:javax.servlet-api:3.1.0'
-compile 'javax.servlet.jsp:javax.servlet.jsp-api:2.3.0'
-compile 'javolution:javolution:5.4.3'
-compile 'junit:junit-dep:4.10'
-compile 'jython:jython:2.1'
-compile 'net.fortuna.ical4j:ical4j:1.0-rc3-atlassian-11'
-compile 'net.sf.barcode4j:barcode4j-fop-ext-complete:2.0'
-compile 'net.sf.dozer:dozer:4.2.1'
-compile 'net.sf.ezmorph:ezmorph:0.9.1'
-compile 'net.sourceforge.nekohtml:nekohtml:1.9.16'
-compile 'org.apache.ant:ant-apache-bsf:1.9.0'
-compile 'org.apache.ant:ant-junit:1.9.0'
-compile 'org.apache.ant:ant-launcher:1.9.0'
-compile 'org.apache.axis2:axis2-adb:1.7.1'
-compile

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384896#comment-15384896
 ] 

Jacques Le Roux commented on OFBIZ-7898:


I added a comment at 
https://issues.apache.org/jira/browse/OFBIZ-7677?focusedCommentId=15384878

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Trunk
>
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


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

Jacques Le Roux closed OFBIZ-7898.
--
   Resolution: Done
Fix Version/s: Trunk

I completed the task of removing all svn:ignore for concerned components build 
dirs at revision: 1753424.

This was a trival and tedious task. But I really like things to be well 
organised to prevent them to dive into chaos (it's even almost pathologic in my 
case :))


> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Trunk
>
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7677) Update documentation with respect to implementation of gradle as a replacement of ant


[ 
https://issues.apache.org/jira/browse/OFBIZ-7677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384878#comment-15384878
 ] 

Jacques Le Roux commented on OFBIZ-7677:


Pierre, I definitely agree that OFBIZ-7723 ("Use grunt-md2html to integrate our 
README.MD from repo to Confluence"), though an important 1st step, especially 
for developers and sysadims (or DevOps if you prefer) is not sufficient for all 
end users. So I suggest that we create a special wiki page named "How to 
upgrade after the move from Gradle to Ant'" (or something with a better title 
if someone wants) where we will import the work done by  OFBIZ-7723 and will 
add and organiser all we think is necessary. THis page will be referenced from 
the FAQ.

> Update documentation with respect to implementation of gradle as a 
> replacement of ant
> -
>
> Key: OFBIZ-7677
> URL: https://issues.apache.org/jira/browse/OFBIZ-7677
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: site
>Reporter: Pierre Smits
>
> Documentation must be updated before any release, that will have the 
> replacement of ant in place, can be cut.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

Thanks Ron,

To All, note that, as mentioned in my last comment
https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies#comment-thread-61331450,

the graph needs to be checked/amended to possibly remove components
dependencies only introduced by the data model

Jacques

Le 19/07/2016 à 22:20, Ron Wheeler a écrit :

https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
This might need updating to clarify some of the dependencies within OFBiz and
add in the important components that are missing.

Ron

On 19/07/2016 3:19 PM, Pierre Smits wrote:

This whole approach seems to leading into a direction that resembles
'killing the fly with a bazooka' or 'I am a carpenter and I solve all
problems with my hammer.

What are the challenges:

- We have a few components for which we don't see external libraries in
the download repo's (MavenCentral, et al). These components are:
- birt
- ebaystore
- ldap
- pos (and as a dependent: webpos

I suggest we either work on resolving the issues with the external
libraries (getting them in or work with alternatives) before next release
in, or we invoke the attic procedure for these components.

- Activating/deactivating components (any variant):
We have a mechanism that activates the components in a particular order
as defined in component-load.xml in the specialpurpose folder. And why is
that? Because there are dependencies in components in the other stacks on
components in the special purpose stack.

Specialpurpose components like:
- lucene
- bi

If components in the lower stacks are dependent on other components in this
folder, then we should solve that (before next release. Either by
duplication of code (creating containment) or by integration of the
functionalities of the particular specialpurpose components into the
component(s) at the lower level.

When we have containment, the adopter can - as a suggestion - move the
component from special purpose to hot-deploy and after a rebuild it works.
If he doesn't want the component, he can delete from the hot-deploy
component. We don't need a hammer for that.

Since we have the components in the specialpurpose folder, we must provide
them in our releases.

This is where it went wrong with the r13.7 fiasco. They were not in the
releases. Now if we want to revisit that discussion again, then we should
start a new thread. And not just present opposing viewpoints regarding
workload on the contributor with privileges, but start working towards an
acceptable compromise.

So looking at the suggestions made by Taher:

1. new task createPlugin:
A createPlugin task needs to provide the same skeleton as the
createComponent task, but delivers the component into the specialpurpose
folder (this is what I understand).
More information needs to be provided before the added value to the
OFBiz community can be established, especially regarding who will use this
and what would the difference be compared to createComponent.
2. New task installPlugin (plus variants)
Since we not have a true hot-deployment solution, installing components
is as simple as copying from one location to another. The build process
needs to be run and data (seed at least needs to be loaded, followed by a
start command before the component can be used by an OFBiz user.

I would see (some minor) added value when this task would accept a uri
(file location, or download page of a website, or ) and then would
download from that location and deploy it in the hot-deploy component (as a
convenience for DEV and OPS - for OPS in CD processes). Does the adopter
need this hammer for something as simple as copy/paste?
3. New task activatePlugin
We don't have a hot-deployment solution that would benefit from such.
Each activation requires a restart. I see little added value in this
solution - what at first sight appears to be complex - to just adjust the
component-load.xml file in the specialpurpose folder. Again: does the
adopter need this hammer?
4. New task uninstallPlugin (plus variants)
Delete from folder works just as fine.

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 7:08 PM, Taher Alkhateeb

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

2016-07-19 Thread Ron Wheeler

https://cwiki.apache.org/confluence/display/OFBIZ/Component+and+Component+Set+Dependencies
This might need updating to clarify some of the dependencies within
OFBiz and add in the important components that are missing.

Ron

On 19/07/2016 3:19 PM, Pierre Smits wrote:

This whole approach seems to leading into a direction that resembles
'killing the fly with a bazooka' or 'I am a carpenter and I solve all
problems with my hammer.

What are the challenges:

- We have a few components for which we don't see external libraries in
the download repo's (MavenCentral, et al). These components are:
- birt
- ebaystore
- ldap
- pos (and as a dependent: webpos

I suggest we either work on resolving the issues with the external
libraries (getting them in or work with alternatives) before next release
in, or we invoke the attic procedure for these components.

Specialpurpose components like:
- lucene
- bi

Since we have the components in the specialpurpose folder, we must provide
them in our releases.

So looking at the suggestions made by Taher:

Best regards,

Pierre Smits

ORRTIZ.COM
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 7:08 PM, Taher Alkhateeb

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

This whole approach seems to leading into a direction that resembles
'killing the fly with a bazooka' or 'I am a carpenter and I solve all
problems with my hammer.

What are the challenges:

   - We have a few components for which we don't see external libraries in
   the download repo's (MavenCentral, et al). These components are:
   - birt
  - ebaystore
  - ldap
  - pos (and as a dependent: webpos

  I suggest we either work on resolving the issues with the external
  libraries (getting them in or work with alternatives) before next release
  in, or we invoke the attic procedure for these components.

  - Activating/deactivating components (any variant):
   We have a mechanism that activates the components in a particular order
   as defined in component-load.xml in the specialpurpose folder. And why is
   that? Because there are dependencies in components in the other stacks on
   components in the special purpose stack.

   Specialpurpose components like:
  - lucene
  - bi

If components in the lower stacks are dependent on other components in this
folder, then we should solve that (before next release. Either by
duplication of code (creating containment) or by integration of the
functionalities of the particular specialpurpose components into the
component(s) at the lower level.

When we have containment, the adopter can - as a suggestion - move the
component from special purpose to hot-deploy and after a rebuild it works.
If he doesn't want the component, he can delete from the hot-deploy
component. We don't need a hammer for that.

Since we have the components in the specialpurpose folder, we must provide
them in our releases.

This is where it went wrong with the r13.7 fiasco. They were not in the
releases. Now if we want to revisit that discussion again, then we should
start a new thread. And not just present opposing viewpoints regarding
workload on the contributor with privileges, but start working towards an
acceptable compromise.

So looking at the suggestions made by Taher:

   1. new task createPlugin:
   A createPlugin task needs to provide the same skeleton as the
   createComponent task, but delivers the component into the specialpurpose
   folder (this is what I understand).
   More information needs to be provided before the added value to the
   OFBiz community can be established, especially regarding who will use this
   and what would the difference be compared to createComponent.
   2. New task installPlugin (plus variants)
   Since we not have a true hot-deployment solution, installing components
   is as simple as copying from one location to another. The build process
   needs to be run and data (seed at least needs to be loaded, followed by a
   start command before the component can be used by an OFBiz user.

   I would see (some minor) added value when this task would accept a uri
   (file location, or download page of a website, or ) and then would
   download from that location and deploy it in the hot-deploy component (as a
   convenience for DEV and OPS - for OPS in CD processes). Does the adopter
   need this hammer for something as simple as copy/paste?
   3. New task activatePlugin
   We don't have a hot-deployment solution that would benefit from such.
   Each activation requires a restart. I see little added value in this
   solution - what at first sight appears to be complex - to just adjust the
   component-load.xml file in the specialpurpose folder. Again: does the
   adopter need this hammer?
   4. New task uninstallPlugin (plus variants)
   Delete from folder works just as fine.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 7:08 PM, Taher Alkhateeb  wrote:

> Hello Everyone,
>
> As you all know, we are still faced with the issue of releasing OFBiz
> without binary packages. Furthermore, we are still stuck with taking a
> decision on the specialpurpose components and how to move forward with
> them.
>
> Therefore, I propose the following action points.
>
> - rename specialpurpose to plugins
> - Introduce the following tasks to the build system:
>   1 - createPlugin: creates a new plugin based on a template very similar
> to createComponent
>   2 - installPlugin: if a plugin comes with a build script that has an
> "install" task, then that task would execute. The task could contain any
> business logic that the author of the plugin wants to run.
>   3 - uninstallPlugin: if a plugin comes with a build script that has an
> "uninstall" task, then the that task would execute. The task could contain
> any business logic that the author of the plugin wants to run
>   4 - activatePlugin: if a plugin is not already added to
> component-load.xml in /plugins, then add it to it.
>   5 - deactivatePlugin: remove a plugin from component-load.xml if it
> exists in it.
>

Re: [DISCUSSION] Proposed Task List for Moving Forward with Gradle and the Trunk

Hello Everyone,

As you all know, we are still faced with the issue of releasing OFBiz
without binary packages. Furthermore, we are still stuck with taking a
decision on the specialpurpose components and how to move forward with them.

Therefore, I propose the following action points.

- rename specialpurpose to plugins
- Introduce the following tasks to the build system:
  1 - createPlugin: creates a new plugin based on a template very similar
to createComponent
  2 - installPlugin: if a plugin comes with a build script that has an
"install" task, then that task would execute. The task could contain any
business logic that the author of the plugin wants to run.
  3 - uninstallPlugin: if a plugin comes with a build script that has an
"uninstall" task, then the that task would execute. The task could contain
any business logic that the author of the plugin wants to run
  4 - activatePlugin: if a plugin is not already added to
component-load.xml in /plugins, then add it to it.
  5 - deactivatePlugin: remove a plugin from component-load.xml if it
exists in it.
  6 - activateAllPlugins: A convenience task to activate all plugins that
exist in /plugins
  7 - installAllPlugins: A convenience task to install all plugins that
exist in /plugins
- By default, installPlugin activates it.
- By default, uninstallPlugin deactivates it.

The above solution would give us a choice in taking whatever direction we
want. If we want to activate the plugins then we can, if we want to
deactivate them then we can, if we want to deactivate them but maintain
them, then individual developers would issue the below command:

./gradlew cleanAll activateAllPlugins loadDefault testIntegration

I'm not suggesting we will deactivate anything, I'm just stating that we
will have choices which is a good thing and we can move forward with this
lingering issue.

What is your opinion?

Taher Alkhateeb

On Thu, Jul 14, 2016 at 7:00 PM, Pierre Smits 
wrote:

> Ahh. I found where they were hidden in the component, with the help of [1].
>
> [1]
>
> https://issues.apache.org/jira/browse/OFBIZ-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356955#comment-15356955
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, Jul 14, 2016 at 4:49 PM, Pierre Smits 
> wrote:
>
> > As I am a user of the cmssite I did have a look at what external
> libraries
> > are included in that component. I have found none. Not in trunk, not in
> any
> > of the older release branches.
> >
> > Are we sure that this then needs to be disabled?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Thu, Jul 14, 2016 at 4:43 PM, Pierre Smits 
> > wrote:
> >
> >> I can live with that.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM 
> >> OFBiz based solutions & services
> >>
> >> OFBiz Extensions Marketplace
> >> http://oem.ofbizci.net/oci-2/
> >>
> >> On Thu, Jul 14, 2016 at 4:30 PM, Jacopo Cappellato <
> >> jacopo.cappell...@hotwaxsystems.com> wrote:
> >>
> >>> On Thu, Jul 14, 2016 at 1:35 PM, Pierre Smits 
> >>> wrote:
> >>>
> >>> > Hi Sharan,
> >>> >
> >>> > I guess all accepted proposals can now be transformed into JIRA
> >>> issues, for
> >>> > follow-up and tracking purposes.
> >>> >
> >>> > Also, with respect to the failing components) I suggest that we
> >>> postpone
> >>> > the ultimate decision of activation/deactivation until the moment of
> >>> > cutting a release. Until then, contributors can work on those issues,
> >>> and
> >>> > if they can't resolve the issues by the time the decision needs to be
> >>> taken
> >>> > we know what to deactivate precisely.
> >>> >
> >>>
> >>> I suggest the opposite :-) if we disable them sooner than later
> >>> contributors will be more aware of the work required and there be less
> >>> surprises when they will be excluded from releases; disabling them
> sooner
> >>> would probably increase the chances of fixing them because it will
> catch
> >>> attention; if otherwise no one will care about them being disabled it
> >>> could
> >>> be an indicator that there is not enough interest.
> >>>
> >>> Jacopo
> >>>
> >>>
> >>>
> >>> > Best regards,
> >>> >
> >>> >
> >>> > Pierre Smits
> >>> >
> >>> > ORRTIZ.COM 
> >>> > OFBiz based solutions & services
> >>> >
> >>> > OFBiz Extensions Marketplace
> >>> > http://oem.ofbizci.net/oci-2/
> >>> >
> >>> > On Thu, Jul 14, 2016 at 1:14 PM, Sharan Foga 
> >>> > wrote:
> >>> >
> >>> > > Hi Everyone
> >>> > >
> >>> > > Thanks responding to these 3 proposals. Based on your feedback and
> >>> > > comments we can move ahead with 2 of

[jira] [Commented] (OFBIZ-7783) External library files are not in the OFBiz folder structure.


[ 
https://issues.apache.org/jira/browse/OFBIZ-7783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384413#comment-15384413
 ] 

Pierre Smits commented on OFBIZ-7783:
-

The following piece of code added to the build.gradle file will add the 3rd 
party libraries to the lib folder in the project.
{code}
task copyToLib(type: Copy) {
into "$rootDir/lib"
from configurations.runtime
}
{code}

> External library files are not in the OFBiz folder structure.
> -
>
> Key: OFBIZ-7783
> URL: https://issues.apache.org/jira/browse/OFBIZ-7783
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Blocker
>
> With the implementation of the external library download feature of 
> gradle/gradlew, the external libraries (jar files) are not in the folder 
> structure any more. 
> They should reside there, like before.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384269#comment-15384269
 ] 

Taher Alkhateeb commented on OFBIZ-7898:


Yeah very good idea, we can have an "upgrade guide" that among other things 
describes what to do with hot-deploy components. That's the safest route I 
think.

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384237#comment-15384237
 ] 

Taher Alkhateeb commented on OFBIZ-7898:


You know on a second round of thought, maybe it is best to avoid this 
altogether. We don't know what people do with their custom components, so let 
them figure out how to fix and upgrade their stuff. I'd rather not touch their 
own tailored components which how knows how it builds or what it does.

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384267#comment-15384267
 ] 

Jacques Le Roux commented on OFBIZ-7898:


OK, we can suggest to add it where we will advertise about...

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384237#comment-15384237
 ] 

Taher Alkhateeb edited comment on OFBIZ-7898 at 7/19/16 2:37 PM:
-

You know on a second round of thought, maybe it is best to avoid this 
altogether. We don't know what people do with their custom components, so let 
them figure out how to fix and upgrade their stuff. I'd rather not touch their 
own tailored components which who knows how it builds or what it does.


was (Author: taher):
You know on a second round of thought, maybe it is best to avoid this 
altogether. We don't know what people do with their custom components, so let 
them figure out how to fix and upgrade their stuff. I'd rather not touch their 
own tailored components which how knows how it builds or what it does.

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384226#comment-15384226
 ] 

Jacques Le Roux commented on OFBIZ-7898:


Optional ?

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384236#comment-15384236
 ] 

Jacques Le Roux commented on OFBIZ-7898:


Done at revision: 1753396  


> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384228#comment-15384228
 ] 

Jacques Le Roux commented on OFBIZ-7898:


And actually it only removes the classes an jars wich are anyway rebuild by 
Gradle, no?

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384213#comment-15384213
 ] 

Taher Alkhateeb commented on OFBIZ-7898:


We can do that for sure. But do users want that? Meaning their custom build 
code automatically removed? I imagine they need to tailor their custom 
components to the new build system.

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384204#comment-15384204
 ] 

Jacques Le Roux commented on OFBIZ-7898:


Thanks Taher, committed at r1753382

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384209#comment-15384209
 ] 

Taher Alkhateeb commented on OFBIZ-7898:


Maybe remove the see OFBIZ-7898 and anything else not related to describing 
what the task does in a comment inside the task instead

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384208#comment-15384208
 ] 

Jacques Le Roux commented on OFBIZ-7898:


In clean group I guess, we can shorten the description but we should advertise 
about this task, trivial but convenient.

Should we not add hot-deploy in the components list as you suggested offline?

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384203#comment-15384203
 ] 

Taher Alkhateeb commented on OFBIZ-7898:


Does the description have to be this long? It looks kinda bad when I do 
,/gradlew tasks

Also, the task does not belong to any category of tasks so in ./gradlew it 
shows up under "other tasks". Not a big deal but might be something to consider.

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384163#comment-15384163
 ] 

Jacques Le Roux edited comment on OFBIZ-7898 at 7/19/16 2:16 PM:
-

Tragically done at r1753360+1753362+1753367+1753381+1753382+1753385+1753395 . 
My excuse? It's too hot here, I forgot to put the AC on :p


Working on the rest now:
bq. We will then also remove the related svn:ignore (build dirs)


was (Author: jacques.le.roux):
Tragically done at r1753360+1753362+1753367+1753381+1753382+1753385. My excuse? 
It's too hot here, I forgot to put the AC on :p

Working on the rest now:
bq. We will then also remove the related svn:ignore (build dirs)

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384186#comment-15384186
 ] 

Taher Alkhateeb edited comment on OFBIZ-7898 at 7/19/16 2:09 PM:
-

For reference, this can be useful in any groovy iteration over all components.
{code:java}
['framework', 'specialpurpose', 'applications'].each { componentGroup ->
file(componentGroup).eachDir { component ->
//do whatever you want to the component directory here.
}
{code}


was (Author: taher):
For reference, this can be useful in any groovy iteration over all components.

['framework', 'specialpurpose', 'applications'].each { componentGroup ->
file(componentGroup).eachDir { component ->
//do whatever you want to the component directory here.
}

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384186#comment-15384186
 ] 

Taher Alkhateeb commented on OFBIZ-7898:


For reference, this can be useful in any groovy iteration over all components.

['framework', 'specialpurpose', 'applications'].each { componentGroup ->
file(componentGroup).eachDir { component ->
//do whatever you want to the component directory here.
}

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proposal to modify the testing framework for OFBiz

2016-07-19 Thread Ron Wheeler


It is not clear what you are expecting as a specific response.

As you move up the food chain, the definition of "units" changes and the 
tests get more complicated and the design of the tests gets more complex 
(mock objects, testing race conditions).


It is hard to make specific comments about what kind of testing will 
give the highest level of confidence at each level but we are going in 
the right direction.


The fact that we are considering tests as a major development activity 
is a big step forward.


We can argue about specific cases (scope, tools, value, etc) as we get 
to them.


I think that we are at the "good idea" stage rather than at the "policy" 
stage at this point.


Ron


On 19/07/2016 4:23 AM, Scott Gray wrote:

I think people are missing my point because they keep replying with generic
statements that aren't specific to unit tests.

On 19 July 2016 at 20:08, Montalbano Florian 
wrote:


Hi everyone,

unit tests and integration tests are complementary and with test, the more
the better.
Implementing unit tests will be a great load of work but it is the same
with every kind of test. As Taher said, we will gain a lot from those unit
tests for avoiding regression while refactoring the framework. From the
start component scope, it has already be proved useful.
And what Ron said about encouraging the creation of "smaller class that
can be tested easily" is very important too. It can be a first step to
reach TDD in the OFBiz development. TDD can help to give confidence to
newcomer and veteran when updating some part of the code and as Hans said,
this lead to "continuous improvement and finally continuous deployment".

I'm aware that this does not solve the technical implementation stuff, but
I think this is an improvement that need to be supported.

Have a nice day,

Florian Montalbano


Le 19/07/2016 09:04, Pierre Smits a écrit :


As with anything, the law of diminishing returns also applies to OFBiz and
tests. This is not true for unit tests and system integration tests, but
also for user acceptance and performance tests.

Nevertheless, the work done up to now is a good start and - I feel
confident - appreciated. And unit tests are certainly valuable in the
framework stack. How it will be for functions (regarding components in
application and special purpose stack) needs to be addressed when we reach
that bridge.


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb <
slidingfilame...@gmail.com


wrote:
Hi Scott,

Well spoken thank you. Okay may I suggest that for any such work we will
discuss it here see its Merit and if it makes sense then we take it in.
It
is a little early to discuss it right now because we did not yet go to
the
higher-level components. Once we do I'll be sure to have a conversation
about this in here and would appreciate your input to it.

Regards,

Taher Alkhateeb

On Jul 19, 2016 9:00 AM, "Scott Gray" 
wrote:

Yeah I'm sure unit tests probably worked well for the start component
given


it is the lowest level component in the system and closest to a basic


java


app.  I just think the value proposition might decrease the further up


the


stack we move with them.  I'm not against unit tests when they prove
useful, but further up the stack I think we should prove the case for


them


before doing much work to support the mocking that will be required to


keep


them inline with 'best practices'.

In OFBiz "bad or unwanted" tends to come mostly in the way of increasing
complexity from features that require more effort to maintain than the
value they provide to the community.  I think there's a chance
attempting
to mock service tests could fall into that bucket.  I could be wrong,


but I


think it's worth looking into before we declare that unit tests are the
best form of testing for OFBiz.

Regards
Scott

On 19 July 2016 at 17:37, Taher Alkhateeb 
wrote:

Hi Scott,

Thank you for the feedback. To be focused exactly on integration vs


unit, I


already mentioned above that at least for me the main objective is to
confidently and quickly run the tests in short bursts of red-green
refactor. This allows me to refactor code without waiting in front of


the
screen in between test cycles thus giving me immediate feedback on any

errors I made. Perhaps my intro was too long so this is the squeezed


out
version of it.

I already had one round of testing in the start component which was


much
faster that way and had an immediate impact. Oh and by the way, you
cannot


test the start component with integration tests for example unless you


do
it from an external component which cannot access package protected
items.


This style of coding is applicable I think to any software project
inclusive of OFBiz. Maybe in certain

[jira] [Commented] (OFBIZ-7898) Create a (short term) Gradle "cleanAnt" task to remove old build dirs


[ 
https://issues.apache.org/jira/browse/OFBIZ-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384163#comment-15384163
 ] 

Jacques Le Roux commented on OFBIZ-7898:


Tragically done at r1753360+1753362+1753367+1753381+1753382+1753385. My excuse? 
It's too hot here, I forgot to put the AC on :p

Working on the rest now:
bq. We will then also remove the related svn:ignore (build dirs)

> Create a (short term) Gradle "cleanAnt" task to remove old build dirs
> -
>
> Key: OFBIZ-7898
> URL: https://issues.apache.org/jira/browse/OFBIZ-7898
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> The idea is to adapt the "old" Ant "clean*" targets in order to allow to 
> remove old build dirs. It's not a problem if you have done an Ant clean just 
> before removing Ant whith a "svn up" but I guess most of us did not.
> We will then also remove the related svn:ignore (build dirs)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1753360 - /ofbiz/trunk/build.gradle


We forgot that http://svn.apache.org/viewvc?view=revision=1753367
I also fixed the "OFBIZ Subversion client configuration file" link at 
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=7766052=82=81


Also I was long to answer because I got a 3 hours POP outage this morning :/

Jacques

Le 19/07/2016 à 13:11, Pierre Smits a écrit :

Hi Jacques,

What happened? It seems to have touched everything in the gradle.build,
making it hard to review.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 12:41 PM,  wrote:


Author: jleroux
Date: Tue Jul 19 10:41:28 2016
New Revision: 1753360

URL: http://svn.apache.org/viewvc?rev=1753360=rev
Log:
Creates a (short term) Gradle "cleanAnt" task to remove old build dirs -
https://issues.apache.org/jira/browse/OFBIZ-7898

This adapts the "old" Ant "clean*" targets in order to allow to remove old
build dirs. It's not a problem if you have done an Ant clean just before
removing Ant whith a "svn up" but I guess most of us did not.

I will then also remove the related svn:ignore (build dirs)... WIP...

Modified:
 ofbiz/trunk/build.gradle

Modified: ofbiz/trunk/build.gradle
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=1753360=1753359=1753360=diff

==
--- ofbiz/trunk/build.gradle (original)
+++ ofbiz/trunk/build.gradle Tue Jul 19 10:41:28 2016
@@ -1,850 +1,872 @@
-/*
- * Licensed to the Apache Software Foundation (ASF) under one
- * or more contributor license agreements.  See the NOTICE file
- * distributed with this work for additional information
- * regarding copyright ownership.  The ASF licenses this file
- * to you under the Apache License, Version 2.0 (the
- * "License"); you may not use this file except in compliance
- * with the License.  You may obtain a copy of the License at
- *
- * http://www.apache.org/licenses/LICENSE-2.0
- *
- * Unless required by applicable law or agreed to in writing,
- * software distributed under the License is distributed on an
- * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- * KIND, either express or implied.  See the License for the
- * specific language governing permissions and limitations
- * under the License.
- */
-import org.apache.tools.ant.filters.ReplaceTokens
-
-/* 
- * Project setup
- *  */
-
-apply plugin: 'java'
-apply plugin: 'eclipse'
-
-apply from: 'common.gradle'
-
-// java settings
-def jvmArguments = ['-Xms128M', '-Xmx512M']
-ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start'
-javadoc.failOnError = false
-sourceCompatibility = '1.8'
-targetCompatibility = '1.8'
-
-// root and subproject settings
-defaultTasks 'build'
-
-allprojects {
-repositories{
-jcenter()
-}
-}
-
-subprojects {
-configurations {
-// compile-time plugin libraries
-pluginLibsCompile
-// runtime plugin libraries
-pluginLibsRuntime
-}
-}
-
-configurations {
-junitLibs
-}
-
-dependencies {
-// general framework libs
-compile 'apache-xerces:resolver:2.9.1'
-compile 'apache-xerces:xercesImpl:2.9.1'
-compile 'avalon-framework:avalon-framework-impl:4.2.0'
-compile 'bouncycastle:bouncycastle-jce-jdk13:112'
-compile 'com.fasterxml.jackson.core:jackson-annotations:2.4.0'
-compile 'com.fasterxml.jackson.core:jackson-core:2.4.2'
-compile 'com.google.guava:guava:19.0'
-compile 'com.google.zxing:core:3.2.1'
-compile
'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.0'
-compile
'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:20160628.1'
-compile 'com.ibm.icu:icu4j:57.1'
-compile 'com.lowagie:itext:2.1.7'
-compile 'com.sun.mail:javax.mail:1.5.1'
-compile
'com.sun.syndication:com.springsource.com.sun.syndication:0.9.0'
-compile 'com.thoughtworks.xstream:xstream:1.4.9'
-compile 'commons-beanutils:commons-beanutils-core:1.8.3'
-compile 'commons-cli:commons-cli:1.3.1'
-compile 'commons-codec:commons-codec:1.10'
-compile 'commons-el:commons-el:1.0'
-compile 'commons-fileupload:commons-fileupload:1.3.1'
-compile 'commons-io:commons-io:2.4'
-compile 'commons-logging:commons-logging:1.2'
-compile 'commons-net:commons-net:3.3'
-compile 'commons-validator:commons-validator:1.5.1'
-compile 'de.odysseus.juel:juel-impl:2.2.7'
-compile 'de.odysseus.juel:juel-spi:2.2.7'
-compile 'httpunit:httpunit:1.7'
-compile 'javax.el:javax.el-api:3.0.1-b04'
-compile 'javax.servlet:javax.servlet-api:3.1.0'
-compile 'javax.servlet.jsp:javax.servlet.jsp-api:2.3.0'
-compile 'javolution:javolution:5.4.3'
-compile 'junit:junit-dep:4.10'
-compile 'jython:jython:2.1'
-

[jira] [Updated] (OFBIZ-7907) Move jsgantt files from images to projectmgr component


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

Pierre Smits updated OFBIZ-7907:

Attachment: OFBIZ-7907-jsgantt.patch

This patch addresses the issue. This patch also moves the projectmgr.css file 
from the static subfolder to the - generally accepted - image subfolder and 
deletes the - now empty - static subfolder.

> Move jsgantt files from images to projectmgr component
> --
>
> Key: OFBIZ-7907
> URL: https://issues.apache.org/jira/browse/OFBIZ-7907
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework, specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
> Attachments: OFBIZ-7907-jsgantt.patch
>
>
> Currently the jsgantt files (css and js) are only used by the projectmgr 
> component, but the files are included in the image component in the framework 
> stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7821) Remove unused system generated fields from all data files

2016-07-19 Thread Nicolas Malin (JIRA)


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

Nicolas Malin reassigned OFBIZ-7821:


Assignee: Nicolas Malin

> Remove unused system generated fields from all data files
> -
>
> Key: OFBIZ-7821
> URL: https://issues.apache.org/jira/browse/OFBIZ-7821
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Suraj Khurana
>Assignee: Nicolas Malin
>Priority: Minor
>
> There are four system generated fields for every entity as lastUpdatedStamp, 
> lastUpdatedTxStamp, createdStamp and createdTxStamp
> To increase readability of data files, these fields are not necessary to be 
> there in data files, as it gets generated every time when data load occurs. 
> This ticket will be served as a parent ticket and I will be creating child 
> tickets component wise for all affected components.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7907) Move jsgantt files from images to projectmgr component

Pierre Smits created OFBIZ-7907:
---

 Summary: Move jsgantt files from images to projectmgr component
 Key: OFBIZ-7907
 URL: https://issues.apache.org/jira/browse/OFBIZ-7907
 Project: OFBiz
  Issue Type: Improvement
  Components: framework, specialpurpose/projectmgr
Affects Versions: Trunk
Reporter: Pierre Smits
Assignee: Pierre Smits


Currently the jsgantt files (css and js) are only used by the projectmgr 
component, but the files are included in the image component in the framework 
stack.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1753348 - /ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

2016-07-19 Thread Suraj Khurana

Yes, working fine for on latest rev.
Here are the logs, I think I was on rev #*1753362* that time.

*{quote}*
suraj@suraj-desktop:~/sandbox/ofbiz_trunk$ ./gradlew cleanAll
:clean
:cleanCatalina
:cleanData
:cleanDownloads
:cleanEclipseClasspath
:cleanEclipseJdt UP-TO-DATE
:cleanEclipseProject
:cleanEclipse
:cleanGradle
:cleanIndexes
:cleanLogs
:cleanOutput
:cleanTempfiles
:cleanUploads
:cleanXtra
:cleanAll

BUILD SUCCESSFUL

Total time: 10.687 secs

This build could be faster, please consider using the Gradle Daemon:
https://docs.gradle.org/2.13/userguide/gradle_daemon.html
suraj@suraj-desktop:~/sandbox/ofbiz_trunk$ ./gradlew loadDefault
:compileJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:createBaseTestServiceProviderJar
:processResources
:classes
:jar
:assemble
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test

org.apache.ofbiz.base.start.OfbizStartupUnitTests >
adminClientReturnsTheCorrectMessageIfServerIsDownOnStatus FAILED
java.lang.AssertionError at OfbizStartupUnitTests.java:76

org.apache.ofbiz.base.start.OfbizStartupUnitTests >
adminClientReturnsTheCorrectMessageIfServerIsDownOnShutdown FAILED
java.lang.AssertionError at OfbizStartupUnitTests.java:83

9 tests completed, 2 failed
:test FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at:
file:///home/suraj/sandbox/ofbiz_trunk/build/reports/tests/index.html

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 43.321 secs

*{quote}*


Suraj Khurana
Enterprise Software Engineer
HotWax Systems  - *The global leader in
innovative enterprise commerce solutions **powered by Apache OFBiz.*



On Tue, Jul 19, 2016 at 5:33 PM, Nicolas Malin 
wrote:

> $ svn up && ./gradlew cleanAll build
>
> works also fine for me
>
>
> Le 19/07/2016 13:58, Taher Alkhateeb a écrit :
>
>> Hi Suraj,
>>
>> The system is building fine on my computer. And you don't need an import
>> because you are on the same package. Maybe something is wrong in your
>> environment?
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Tue, Jul 19, 2016 at 2:52 PM, Suraj Khurana <
>> suraj.khur...@hotwaxsystems.com> wrote:
>>
>> Hello Taher,
>>>
>>> This is causing build fail. I think this  is due to a missing import.
>>>
>>> "*import org.apache.ofbiz.base.start.AdminClient;*"
>>>
>>> --
>>> Thanks and Regards,
>>> Suraj Khurana
>>> Enterprise Software Engineer
>>> HotWax Systems  - *The global leader in
>>> innovative enterprise commerce solutions **powered by Apache OFBiz.*
>>> 
>>>
>>>
>>> On Tue, Jul 19, 2016 at 1:50 PM,  wrote:
>>>
>>> Author: taher
 Date: Tue Jul 19 08:20:45 2016
 New Revision: 1753348

 URL: http://svn.apache.org/viewvc?rev=1753348=rev
 Log:
 Break down the tests of requestStatus and requestShutdown - OFBIZ-7897

 The two tests were lumped together and if one throws an exception the

>>> other
>>>
 will never throw it. So test coverage was not done properly. This commit
 fixes this issue by separating the calls into two different tests.

 Modified:



>>> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
>>>
 Modified:


>>> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
>>>
 URL:


>>> http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java?rev=1753348=1753347=1753348=diff
>>>


>>> ==
>>>
 ---


>>> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
>>>
 (original)
 +++


>>> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
>>>
 Tue Jul 19 08:20:45 2016
 @@ -70,14 +70,21 @@ public class OfbizStartupUnitTests {
   }

   @Test
 -public void adminClientReturnsTheCorrectMessageIfServerIsDown()
 throws StartupException {
 -assertThat(sendRequestToAdminClient("--status"), equalTo("OFBiz
 is Down"));
 -assertThat(sendRequestToAdminClient("--shutdown"),

>>> equalTo("OFBiz
>>>
 is Down"));
 +public void
 adminClientReturnsTheCorrectMessageIfServerIsDownOnStatus() throws
 StartupException {
 +Config config = sendRequestToAdminClient("--status");
 +
 +assertThat(AdminClient.requestStatus(config), equalTo("OFBiz is
 Down"));
 +

[jira] [Updated] (OFBIZ-7906) Have a gradle build file for the cmssite component


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

Pierre Smits updated OFBIZ-7906:

Attachment: OFBIZ-7906-cmssite.patch

This patch addresses the issue.

> Have a gradle build file for the cmssite component
> --
>
> Key: OFBIZ-7906
> URL: https://issues.apache.org/jira/browse/OFBIZ-7906
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/cmssite
>Reporter: Pierre Smits
>Assignee: Pierre Smits
> Attachments: OFBIZ-7906-cmssite.patch
>
>
> The cmssite component uses a specific set of external libraries. These were 
> removed as a result of the migration from Ant to Gradle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7906) Have a gradle build file for the cmssite component

Pierre Smits created OFBIZ-7906:
---

 Summary: Have a gradle build file for the cmssite component
 Key: OFBIZ-7906
 URL: https://issues.apache.org/jira/browse/OFBIZ-7906
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/cmssite
Reporter: Pierre Smits
Assignee: Pierre Smits


The cmssite component uses a specific set of external libraries. These were 
removed as a result of the migration from Ant to Gradle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7785) ./gradle create component duplicates OFBTOOLS permission


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

Pierre Smits reassigned OFBIZ-7785:
---

Assignee: Pierre Smits

> ./gradle create component duplicates OFBTOOLS permission
> 
>
> Key: OFBIZ-7785
> URL: https://issues.apache.org/jira/browse/OFBIZ-7785
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Pierre Smits
> Attachments: OFBIZ-7785-README.md.patch
>
>
> When using ./gradlew createComponent the OFBTOOLS permissions appears twice 
> in the ofbiz-component.xml file of the newly created hot-deploy component.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7785) ./gradle create component duplicates OFBTOOLS permission


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

Pierre Smits updated OFBIZ-7785:

Attachment: OFBIZ-7785-README.md.patch

This patch addresses the confusion in the README.md file.

> ./gradle create component duplicates OFBTOOLS permission
> 
>
> Key: OFBIZ-7785
> URL: https://issues.apache.org/jira/browse/OFBIZ-7785
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
> Attachments: OFBIZ-7785-README.md.patch
>
>
> When using ./gradlew createComponent the OFBTOOLS permissions appears twice 
> in the ofbiz-component.xml file of the newly created hot-deploy component.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1753348 - /ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

2016-07-19 Thread Nicolas Malin


$ svn up && ./gradlew cleanAll build

works also fine for me

Le 19/07/2016 13:58, Taher Alkhateeb a écrit :

Hi Suraj,

The system is building fine on my computer. And you don't need an import
because you are on the same package. Maybe something is wrong in your
environment?

Regards,

Taher Alkhateeb

On Tue, Jul 19, 2016 at 2:52 PM, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:


Hello Taher,

This is causing build fail. I think this  is due to a missing import.

"*import org.apache.ofbiz.base.start.AdminClient;*"

--
Thanks and Regards,
Suraj Khurana
Enterprise Software Engineer
HotWax Systems  - *The global leader in
innovative enterprise commerce solutions **powered by Apache OFBiz.*



On Tue, Jul 19, 2016 at 1:50 PM,  wrote:


Author: taher
Date: Tue Jul 19 08:20:45 2016
New Revision: 1753348

URL: http://svn.apache.org/viewvc?rev=1753348=rev
Log:
Break down the tests of requestStatus and requestShutdown - OFBIZ-7897

The two tests were lumped together and if one throws an exception the

other

will never throw it. So test coverage was not done properly. This commit
fixes this issue by separating the calls into two different tests.

Modified:



ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

Modified:


ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

URL:


http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java?rev=1753348=1753347=1753348=diff



==

---


ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

(original)
+++


ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

Tue Jul 19 08:20:45 2016
@@ -70,14 +70,21 @@ public class OfbizStartupUnitTests {
  }

  @Test
-public void adminClientReturnsTheCorrectMessageIfServerIsDown()
throws StartupException {
-assertThat(sendRequestToAdminClient("--status"), equalTo("OFBiz
is Down"));
-assertThat(sendRequestToAdminClient("--shutdown"),

equalTo("OFBiz

is Down"));
+public void
adminClientReturnsTheCorrectMessageIfServerIsDownOnStatus() throws
StartupException {
+Config config = sendRequestToAdminClient("--status");
+
+assertThat(AdminClient.requestStatus(config), equalTo("OFBiz is
Down"));
+}
+
+@Test
+public void
adminClientReturnsTheCorrectMessageIfServerIsDownOnShutdown() throws
StartupException {
+Config config = sendRequestToAdminClient("--shutdown");
+
+assertThat(AdminClient.requestShutdown(config), equalTo("OFBiz

is

Down"));
  }

-private String sendRequestToAdminClient(String request) throws
StartupException {
+private Config sendRequestToAdminClient(String request) throws
StartupException {
  List startupCommands =
StartupCommandUtil.parseOfbizCommands(new String[]{request});
-Config config = new Config(startupCommands);
-return AdminClient.requestStatus(config);
+return new Config(startupCommands);
  }
  }

Re: svn commit: r1753348 - /ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

Hi Suraj,

The system is building fine on my computer. And you don't need an import
because you are on the same package. Maybe something is wrong in your
environment?

Regards,

Taher Alkhateeb

On Tue, Jul 19, 2016 at 2:52 PM, Suraj Khurana <
suraj.khur...@hotwaxsystems.com> wrote:

> Hello Taher,
>
> This is causing build fail. I think this  is due to a missing import.
>
> "*import org.apache.ofbiz.base.start.AdminClient;*"
>
> --
> Thanks and Regards,
> Suraj Khurana
> Enterprise Software Engineer
> HotWax Systems  - *The global leader in
> innovative enterprise commerce solutions **powered by Apache OFBiz.*
> 
>
>
> On Tue, Jul 19, 2016 at 1:50 PM,  wrote:
>
> > Author: taher
> > Date: Tue Jul 19 08:20:45 2016
> > New Revision: 1753348
> >
> > URL: http://svn.apache.org/viewvc?rev=1753348=rev
> > Log:
> > Break down the tests of requestStatus and requestShutdown - OFBIZ-7897
> >
> > The two tests were lumped together and if one throws an exception the
> other
> > will never throw it. So test coverage was not done properly. This commit
> > fixes this issue by separating the calls into two different tests.
> >
> > Modified:
> >
> >
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> >
> > Modified:
> >
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> > URL:
> >
> http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java?rev=1753348=1753347=1753348=diff
> >
> >
> ==
> > ---
> >
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> > (original)
> > +++
> >
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> > Tue Jul 19 08:20:45 2016
> > @@ -70,14 +70,21 @@ public class OfbizStartupUnitTests {
> >  }
> >
> >  @Test
> > -public void adminClientReturnsTheCorrectMessageIfServerIsDown()
> > throws StartupException {
> > -assertThat(sendRequestToAdminClient("--status"), equalTo("OFBiz
> > is Down"));
> > -assertThat(sendRequestToAdminClient("--shutdown"),
> equalTo("OFBiz
> > is Down"));
> > +public void
> > adminClientReturnsTheCorrectMessageIfServerIsDownOnStatus() throws
> > StartupException {
> > +Config config = sendRequestToAdminClient("--status");
> > +
> > +assertThat(AdminClient.requestStatus(config), equalTo("OFBiz is
> > Down"));
> > +}
> > +
> > +@Test
> > +public void
> > adminClientReturnsTheCorrectMessageIfServerIsDownOnShutdown() throws
> > StartupException {
> > +Config config = sendRequestToAdminClient("--shutdown");
> > +
> > +assertThat(AdminClient.requestShutdown(config), equalTo("OFBiz
> is
> > Down"));
> >  }
> >
> > -private String sendRequestToAdminClient(String request) throws
> > StartupException {
> > +private Config sendRequestToAdminClient(String request) throws
> > StartupException {
> >  List startupCommands =
> > StartupCommandUtil.parseOfbizCommands(new String[]{request});
> > -Config config = new Config(startupCommands);
> > -return AdminClient.requestStatus(config);
> > +return new Config(startupCommands);
> >  }
> >  }
> >
> >
> >
>

Re: svn commit: r1753348 - /ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java

2016-07-19 Thread Suraj Khurana

Hello Taher,

This is causing build fail. I think this  is due to a missing import.

"*import org.apache.ofbiz.base.start.AdminClient;*"

--
Thanks and Regards,
Suraj Khurana
Enterprise Software Engineer
HotWax Systems  - *The global leader in
innovative enterprise commerce solutions **powered by Apache OFBiz.*



On Tue, Jul 19, 2016 at 1:50 PM,  wrote:

> Author: taher
> Date: Tue Jul 19 08:20:45 2016
> New Revision: 1753348
>
> URL: http://svn.apache.org/viewvc?rev=1753348=rev
> Log:
> Break down the tests of requestStatus and requestShutdown - OFBIZ-7897
>
> The two tests were lumped together and if one throws an exception the other
> will never throw it. So test coverage was not done properly. This commit
> fixes this issue by separating the calls into two different tests.
>
> Modified:
>
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
>
> Modified:
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java?rev=1753348=1753347=1753348=diff
>
> ==
> ---
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> (original)
> +++
> ofbiz/trunk/framework/start/src/test/java/org/apache/ofbiz/base/start/OfbizStartupUnitTests.java
> Tue Jul 19 08:20:45 2016
> @@ -70,14 +70,21 @@ public class OfbizStartupUnitTests {
>  }
>
>  @Test
> -public void adminClientReturnsTheCorrectMessageIfServerIsDown()
> throws StartupException {
> -assertThat(sendRequestToAdminClient("--status"), equalTo("OFBiz
> is Down"));
> -assertThat(sendRequestToAdminClient("--shutdown"), equalTo("OFBiz
> is Down"));
> +public void
> adminClientReturnsTheCorrectMessageIfServerIsDownOnStatus() throws
> StartupException {
> +Config config = sendRequestToAdminClient("--status");
> +
> +assertThat(AdminClient.requestStatus(config), equalTo("OFBiz is
> Down"));
> +}
> +
> +@Test
> +public void
> adminClientReturnsTheCorrectMessageIfServerIsDownOnShutdown() throws
> StartupException {
> +Config config = sendRequestToAdminClient("--shutdown");
> +
> +assertThat(AdminClient.requestShutdown(config), equalTo("OFBiz is
> Down"));
>  }
>
> -private String sendRequestToAdminClient(String request) throws
> StartupException {
> +private Config sendRequestToAdminClient(String request) throws
> StartupException {
>  List startupCommands =
> StartupCommandUtil.parseOfbizCommands(new String[]{request});
> -Config config = new Config(startupCommands);
> -return AdminClient.requestStatus(config);
> +return new Config(startupCommands);
>  }
>  }
>
>
>

[jira] [Created] (OFBIZ-7905) Remove system generated fields - Scrum

Suraj Khurana created OFBIZ-7905:


 Summary: Remove system generated fields - Scrum
 Key: OFBIZ-7905
 URL: https://issues.apache.org/jira/browse/OFBIZ-7905
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/scrum
Affects Versions: Trunk
Reporter: Suraj Khurana
Assignee: Suraj Khurana
Priority: Minor


Remove all system generated fields from scrum component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7904) Remove system generated fields - Product

Suraj Khurana created OFBIZ-7904:


 Summary: Remove system generated fields - Product
 Key: OFBIZ-7904
 URL: https://issues.apache.org/jira/browse/OFBIZ-7904
 Project: OFBiz
  Issue Type: Sub-task
  Components: product
Affects Versions: Trunk
Reporter: Suraj Khurana
Assignee: Suraj Khurana
Priority: Minor


Remove all system generated fields from product component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7903) Remove system generated fields - Marketing

Suraj Khurana created OFBIZ-7903:


 Summary: Remove system generated fields - Marketing
 Key: OFBIZ-7903
 URL: https://issues.apache.org/jira/browse/OFBIZ-7903
 Project: OFBiz
  Issue Type: Sub-task
  Components: marketing
Affects Versions: Trunk
Reporter: Suraj Khurana
Assignee: Suraj Khurana
Priority: Minor


Remove all system generated fields from marketing component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OFBIZ-7902) Remove system generated fields - Ecommerce

Suraj Khurana created OFBIZ-7902:


 Summary: Remove system generated fields - Ecommerce
 Key: OFBIZ-7902
 URL: https://issues.apache.org/jira/browse/OFBIZ-7902
 Project: OFBiz
  Issue Type: Sub-task
Reporter: Suraj Khurana
Assignee: Suraj Khurana
Priority: Minor


Remove all system generated fields from ecommerce component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1753360 - /ofbiz/trunk/build.gradle

Hi Jacques,

What happened? It seems to have touched everything in the gradle.build,
making it hard to review.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 12:41 PM,  wrote:

> Author: jleroux
> Date: Tue Jul 19 10:41:28 2016
> New Revision: 1753360
>
> URL: http://svn.apache.org/viewvc?rev=1753360=rev
> Log:
> Creates a (short term) Gradle "cleanAnt" task to remove old build dirs -
> https://issues.apache.org/jira/browse/OFBIZ-7898
>
> This adapts the "old" Ant "clean*" targets in order to allow to remove old
> build dirs. It's not a problem if you have done an Ant clean just before
> removing Ant whith a "svn up" but I guess most of us did not.
>
> I will then also remove the related svn:ignore (build dirs)... WIP...
>
> Modified:
> ofbiz/trunk/build.gradle
>
> Modified: ofbiz/trunk/build.gradle
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/build.gradle?rev=1753360=1753359=1753360=diff
>
> ==
> --- ofbiz/trunk/build.gradle (original)
> +++ ofbiz/trunk/build.gradle Tue Jul 19 10:41:28 2016
> @@ -1,850 +1,872 @@
> -/*
> - * Licensed to the Apache Software Foundation (ASF) under one
> - * or more contributor license agreements.  See the NOTICE file
> - * distributed with this work for additional information
> - * regarding copyright ownership.  The ASF licenses this file
> - * to you under the Apache License, Version 2.0 (the
> - * "License"); you may not use this file except in compliance
> - * with the License.  You may obtain a copy of the License at
> - *
> - * http://www.apache.org/licenses/LICENSE-2.0
> - *
> - * Unless required by applicable law or agreed to in writing,
> - * software distributed under the License is distributed on an
> - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> - * KIND, either express or implied.  See the License for the
> - * specific language governing permissions and limitations
> - * under the License.
> - */
> -import org.apache.tools.ant.filters.ReplaceTokens
> -
> -/* 
> - * Project setup
> - *  */
> -
> -apply plugin: 'java'
> -apply plugin: 'eclipse'
> -
> -apply from: 'common.gradle'
> -
> -// java settings
> -def jvmArguments = ['-Xms128M', '-Xmx512M']
> -ext.ofbizMainClass = 'org.apache.ofbiz.base.start.Start'
> -javadoc.failOnError = false
> -sourceCompatibility = '1.8'
> -targetCompatibility = '1.8'
> -
> -// root and subproject settings
> -defaultTasks 'build'
> -
> -allprojects {
> -repositories{
> -jcenter()
> -}
> -}
> -
> -subprojects {
> -configurations {
> -// compile-time plugin libraries
> -pluginLibsCompile
> -// runtime plugin libraries
> -pluginLibsRuntime
> -}
> -}
> -
> -configurations {
> -junitLibs
> -}
> -
> -dependencies {
> -// general framework libs
> -compile 'apache-xerces:resolver:2.9.1'
> -compile 'apache-xerces:xercesImpl:2.9.1'
> -compile 'avalon-framework:avalon-framework-impl:4.2.0'
> -compile 'bouncycastle:bouncycastle-jce-jdk13:112'
> -compile 'com.fasterxml.jackson.core:jackson-annotations:2.4.0'
> -compile 'com.fasterxml.jackson.core:jackson-core:2.4.2'
> -compile 'com.google.guava:guava:19.0'
> -compile 'com.google.zxing:core:3.2.1'
> -compile
> 'com.googlecode.concurrentlinkedhashmap:concurrentlinkedhashmap-lru:1.0'
> -compile
> 'com.googlecode.owasp-java-html-sanitizer:owasp-java-html-sanitizer:20160628.1'
> -compile 'com.ibm.icu:icu4j:57.1'
> -compile 'com.lowagie:itext:2.1.7'
> -compile 'com.sun.mail:javax.mail:1.5.1'
> -compile
> 'com.sun.syndication:com.springsource.com.sun.syndication:0.9.0'
> -compile 'com.thoughtworks.xstream:xstream:1.4.9'
> -compile 'commons-beanutils:commons-beanutils-core:1.8.3'
> -compile 'commons-cli:commons-cli:1.3.1'
> -compile 'commons-codec:commons-codec:1.10'
> -compile 'commons-el:commons-el:1.0'
> -compile 'commons-fileupload:commons-fileupload:1.3.1'
> -compile 'commons-io:commons-io:2.4'
> -compile 'commons-logging:commons-logging:1.2'
> -compile 'commons-net:commons-net:3.3'
> -compile 'commons-validator:commons-validator:1.5.1'
> -compile 'de.odysseus.juel:juel-impl:2.2.7'
> -compile 'de.odysseus.juel:juel-spi:2.2.7'
> -compile 'httpunit:httpunit:1.7'
> -compile 'javax.el:javax.el-api:3.0.1-b04'
> -compile 'javax.servlet:javax.servlet-api:3.1.0'
> -compile 'javax.servlet.jsp:javax.servlet.jsp-api:2.3.0'
> -compile 'javolution:javolution:5.4.3'
> -compile 'junit:junit-dep:4.10'
> -compile 'jython:jython:2.1'
> -compile 'net.fortuna.ical4j:ical4j:1.0-rc3-atlassian-11'
> -compile 'net.sf.barcode4j:barcode4j-fop-ext-complete:2.0'
>

[jira] [Created] (OFBIZ-7901) Remove system generated fields - Content

Suraj Khurana created OFBIZ-7901:


 Summary: Remove system generated fields - Content
 Key: OFBIZ-7901
 URL: https://issues.apache.org/jira/browse/OFBIZ-7901
 Project: OFBiz
  Issue Type: Sub-task
  Components: content
Affects Versions: Trunk
Reporter: Suraj Khurana
Assignee: Suraj Khurana
Priority: Minor


Remove all system generated fields from content component



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7900) Exception in Multi-Tenant Env - When Using an non existence Tenant ID


[ 
https://issues.apache.org/jira/browse/OFBIZ-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383905#comment-15383905
 ] 

Jacques Le Roux commented on OFBIZ-7900:


HI Derek,
If you are interested in tenants, you might be interested by these threads
http://ofbiz.markmail.org/message/xsvyscpoup7nqsqk#query:+page:1+mid:i4rubhbo7wlm4wts+state:results
http://ofbiz.markmail.org/message/3ay5o5wbhqmwvwjx

Also this issue OFBIZ-6065

And we maybe need to review the documentation 
https://cwiki.apache.org/confluence/display/OFBIZ/Extension+in+Multitenancy+support
https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support



> Exception in Multi-Tenant Env - When Using an non existence Tenant ID
> -
>
> Key: OFBIZ-7900
> URL: https://issues.apache.org/jira/browse/OFBIZ-7900
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 14.12
> Environment: Win 10, Derby
>Reporter: Derek Lew
>Priority: Minor
>
> Steps to recreate:
> 1) Enable Multi-tenant, and using only the default derby DB
> 2) ant clean-all
> 3) ant load-demo-multitenant
> 4) ./tools/startofbiz.bat
> 5) go to https://localhost:8443/partymgr/control/login
> 6) login using admin/ofbiz/DEMO3, DEMO3 being the non existence tenant ID.  
> And you got the following error:
> {code}
> 2016-07-19 15:13:59,397 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-enumeration-valid: Value 'Themes' is not facet-valid 
> with respect to enumeration '[main, secondary]'. It must be a value from the 
> enumeration.
> 2016-07-19 15:13:59,397 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-attribute.3: The value 'Themes' of attribute 
> 'menu-name' on element 'webapp' is not valid with respect to its type, 
> '#AnonType_menu-nameattlist.webapp'.
> 2016-07-19 15:13:59,407 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-enumeration-valid: Value 'Themes' is not facet-valid 
> with respect to enumeration '[main, secondary]'. It must be a value from the 
> enumeration.
> 2016-07-19 15:13:59,407 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-attribute.3: The value 'Themes' of attribute 
> 'menu-name' on element 'webapp' is not valid with respect to its type, 
> '#AnonType_menu-nameattlist.webapp'.
> 2016-07-19 15:14:17,357 |delegator-startup-9  |DelegatorFactoryImpl  
> |E| Error creating delegator
> org.ofbiz.entity.GenericEntityException: No Tenant record found for delegator 
> [default#DEMO3] with tenantId [DEMO3]
>   at org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:202) 
> ~[ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:200) 
> [ofbiz-base.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
>  [ofbiz-entity.jar:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_92]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [?:1.8.0_92]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [?:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_92]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
> 2016-07-19 15:14:17,363 |delegator-startup-9  |DelegatorFactoryImpl  
> |E| null
> java.lang.ClassNotFoundException: java.lang.Class
>   at 
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:205) 
>

Re: [DISCUSSION] Simplification of the create component process

I know a little fast, but I have a patch that does the following:

componentName: mandatory
componentResourceName: optional, defaults to componentName
webappName: optional, defaults to componentName
basePermission: optional, defaults to ${componentName}_ADMIN

so the security permissions are OFBTOOLS followed by ${componentName}_ADMIN

Total size of new code? 9 lines :)

Whenever you folks want to I can push this to whatever JIRA requires it.

On Tue, Jul 19, 2016 at 12:33 PM, Pierre Smits 
wrote:

> Taher,
>
> What you are saying is not off topic. Thus it is good to bring these to the
> table. And they need to be addressed before a solution can gather consensus
> and gets implemented.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 19, 2016 at 11:27 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > By the way, this is a good example of the problems of interactive tasks.
> If
> > we create an interactive task for createComponent then we have to update
> > its implementation because it will break based on these new requirements.
> >
> > So everytime we change something on which an interactive task depends, we
> > have to update that task as well. Usually interactive tasks have more
> > business logic for validation and hence are more brittle to such
> changes. I
> > know this is off topic but couldn't help notice it.
> >
> > On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
> > jacopo.cappell...@hotwaxsystems.com> wrote:
> >
> > > +1 to the idea, with defaults for optional resources (1 mandatory, 3
> > > optional).
> > >
> > > Wish: it would be nice to have more control on the component structure;
> > for
> > > example create a component without a webapp, add a webapp to an
> existing
> > > component etc...
> > >
> > > Jacopo
> > >
> > > On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> > > slidingfilame...@gmail.com> wrote:
> > >
> > > > Noted, thank you.
> > > >
> > > > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <
> pierre.sm...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Taher,
> > > > >
> > > > > OFBTOOLS is not required as it is already defined in the template
> to
> > be
> > > > > included. When added in basePermission it leads to duplication in
> the
> > > > > generated ofbiz-component.xml file.
> > > > >
> > > > > I already created an issue for that, see
> > > > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > ORRTIZ.COM 
> > > > > OFBiz based solutions & services
> > > > >
> > > > > OFBiz Extensions Marketplace
> > > > > http://oem.ofbizci.net/oci-2/
> > > > >
> > > > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > > > slidingfilame...@gmail.com> wrote:
> > > > >
> > > > > > Hi Pierre,
> > > > > >
> > > > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > > > componentId
> > > > > > and just apply the following to the variables:
> > > > > >
> > > > > > componentName: mandatory
> > > > > > componentResourceName: optional, defaults to componentName
> > > > > > webappName: optional, defaults to componentName
> > > > > > basePermission: optional, defaults to OFBTOOLS (or whatever
> > defaults
> > > > > were)
> > > > > >
> > > > > > This way, You get a real nice and simple command for end-users to
> > > > create
> > > > > > new components while at the same time allowing more
> expressiveness.
> > > > This
> > > > > > becomes similar to the createTenant task which also has
> everything
> > > > > optional
> > > > > > except the tenantId and tenantName
> > > > > >
> > > > > > Taher Alkhateeb
> > > > > >
> > > > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> > > pierre.sm...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Currently our create component process (./gradlew
> > createComponent)
> > > is
> > > > > > error
> > > > > > > prone.
> > > > > > >
> > > > > > > It requires 4 variables to successfully create a new component
> in
> > > the
> > > > > > > hot-deploy folder to jumpstart development with a component
> > > skeleton.
> > > > > > These
> > > > > > > variables are:
> > > > > > >
> > > > > > >- componentName
> > > > > > >- componentResourceName
> > > > > > >- webappName
> > > > > > >- basePermission
> > > > > > >
> > > > > > > I believe we should reduce the number of variables to just 1
> > > variable
> > > > > > (e.g.
> > > > > > > componentId) to create consistency throughout the skeleton and
> > its
> > > > > > > associated datasets. The developer can, after a skeleton has
> been
> > > > > built,
> > > > > > > then apply any kind of changes according to his/her
> requirements
> > an
> > > > > > needs.
> > > > > > >
> > > > > > > What is your opinion on this?
> > > > > > >
> > > >

Re: [DISCUSSION] Simplification of the create component process

Taher,

What you are saying is not off topic. Thus it is good to bring these to the
table. And they need to be addressed before a solution can gather consensus
and gets implemented.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 11:27 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> By the way, this is a good example of the problems of interactive tasks. If
> we create an interactive task for createComponent then we have to update
> its implementation because it will break based on these new requirements.
>
> So everytime we change something on which an interactive task depends, we
> have to update that task as well. Usually interactive tasks have more
> business logic for validation and hence are more brittle to such changes. I
> know this is off topic but couldn't help notice it.
>
> On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
> jacopo.cappell...@hotwaxsystems.com> wrote:
>
> > +1 to the idea, with defaults for optional resources (1 mandatory, 3
> > optional).
> >
> > Wish: it would be nice to have more control on the component structure;
> for
> > example create a component without a webapp, add a webapp to an existing
> > component etc...
> >
> > Jacopo
> >
> > On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> > slidingfilame...@gmail.com> wrote:
> >
> > > Noted, thank you.
> > >
> > > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits  >
> > > wrote:
> > >
> > > > Hi Taher,
> > > >
> > > > OFBTOOLS is not required as it is already defined in the template to
> be
> > > > included. When added in basePermission it leads to duplication in the
> > > > generated ofbiz-component.xml file.
> > > >
> > > > I already created an issue for that, see
> > > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > > slidingfilame...@gmail.com> wrote:
> > > >
> > > > > Hi Pierre,
> > > > >
> > > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > > componentId
> > > > > and just apply the following to the variables:
> > > > >
> > > > > componentName: mandatory
> > > > > componentResourceName: optional, defaults to componentName
> > > > > webappName: optional, defaults to componentName
> > > > > basePermission: optional, defaults to OFBTOOLS (or whatever
> defaults
> > > > were)
> > > > >
> > > > > This way, You get a real nice and simple command for end-users to
> > > create
> > > > > new components while at the same time allowing more expressiveness.
> > > This
> > > > > becomes similar to the createTenant task which also has everything
> > > > optional
> > > > > except the tenantId and tenantName
> > > > >
> > > > > Taher Alkhateeb
> > > > >
> > > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> > pierre.sm...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Currently our create component process (./gradlew
> createComponent)
> > is
> > > > > error
> > > > > > prone.
> > > > > >
> > > > > > It requires 4 variables to successfully create a new component in
> > the
> > > > > > hot-deploy folder to jumpstart development with a component
> > skeleton.
> > > > > These
> > > > > > variables are:
> > > > > >
> > > > > >- componentName
> > > > > >- componentResourceName
> > > > > >- webappName
> > > > > >- basePermission
> > > > > >
> > > > > > I believe we should reduce the number of variables to just 1
> > variable
> > > > > (e.g.
> > > > > > componentId) to create consistency throughout the skeleton and
> its
> > > > > > associated datasets. The developer can, after a skeleton has been
> > > > built,
> > > > > > then apply any kind of changes according to his/her requirements
> an
> > > > > needs.
> > > > > >
> > > > > > What is your opinion on this?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Pierre Smits
> > > > > >
> > > > > > ORRTIZ.COM 
> > > > > > OFBiz based solutions & services
> > > > > >
> > > > > > OFBiz Extensions Marketplace
> > > > > > http://oem.ofbizci.net/oci-2/
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] Simplification of the create component process

By the way, this is a good example of the problems of interactive tasks. If
we create an interactive task for createComponent then we have to update
its implementation because it will break based on these new requirements.

So everytime we change something on which an interactive task depends, we
have to update that task as well. Usually interactive tasks have more
business logic for validation and hence are more brittle to such changes. I
know this is off topic but couldn't help notice it.

On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> +1 to the idea, with defaults for optional resources (1 mandatory, 3
> optional).
>
> Wish: it would be nice to have more control on the component structure; for
> example create a component without a webapp, add a webapp to an existing
> component etc...
>
> Jacopo
>
> On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > Noted, thank you.
> >
> > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits 
> > wrote:
> >
> > > Hi Taher,
> > >
> > > OFBTOOLS is not required as it is already defined in the template to be
> > > included. When added in basePermission it leads to duplication in the
> > > generated ofbiz-component.xml file.
> > >
> > > I already created an issue for that, see
> > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > slidingfilame...@gmail.com> wrote:
> > >
> > > > Hi Pierre,
> > > >
> > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > componentId
> > > > and just apply the following to the variables:
> > > >
> > > > componentName: mandatory
> > > > componentResourceName: optional, defaults to componentName
> > > > webappName: optional, defaults to componentName
> > > > basePermission: optional, defaults to OFBTOOLS (or whatever defaults
> > > were)
> > > >
> > > > This way, You get a real nice and simple command for end-users to
> > create
> > > > new components while at the same time allowing more expressiveness.
> > This
> > > > becomes similar to the createTenant task which also has everything
> > > optional
> > > > except the tenantId and tenantName
> > > >
> > > > Taher Alkhateeb
> > > >
> > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> pierre.sm...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Currently our create component process (./gradlew createComponent)
> is
> > > > error
> > > > > prone.
> > > > >
> > > > > It requires 4 variables to successfully create a new component in
> the
> > > > > hot-deploy folder to jumpstart development with a component
> skeleton.
> > > > These
> > > > > variables are:
> > > > >
> > > > >- componentName
> > > > >- componentResourceName
> > > > >- webappName
> > > > >- basePermission
> > > > >
> > > > > I believe we should reduce the number of variables to just 1
> variable
> > > > (e.g.
> > > > > componentId) to create consistency throughout the skeleton and its
> > > > > associated datasets. The developer can, after a skeleton has been
> > > built,
> > > > > then apply any kind of changes according to his/her requirements an
> > > > needs.
> > > > >
> > > > > What is your opinion on this?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > ORRTIZ.COM 
> > > > > OFBiz based solutions & services
> > > > >
> > > > > OFBiz Extensions Marketplace
> > > > > http://oem.ofbizci.net/oci-2/
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] Simplification of the create component process

2016-07-19 Thread Jacopo Cappellato

+1 to the idea, with defaults for optional resources (1 mandatory, 3
optional).

Wish: it would be nice to have more control on the component structure; for
example create a component without a webapp, add a webapp to an existing
component etc...

Jacopo

On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> Noted, thank you.
>
> On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits 
> wrote:
>
> > Hi Taher,
> >
> > OFBTOOLS is not required as it is already defined in the template to be
> > included. When added in basePermission it leads to duplication in the
> > generated ofbiz-component.xml file.
> >
> > I already created an issue for that, see
> > https://issues.apache.org/jira/browse/OFBIZ-7785
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > slidingfilame...@gmail.com> wrote:
> >
> > > Hi Pierre,
> > >
> > > Hmmm, that's actually a nice idea. I suggest however we avoid
> componentId
> > > and just apply the following to the variables:
> > >
> > > componentName: mandatory
> > > componentResourceName: optional, defaults to componentName
> > > webappName: optional, defaults to componentName
> > > basePermission: optional, defaults to OFBTOOLS (or whatever defaults
> > were)
> > >
> > > This way, You get a real nice and simple command for end-users to
> create
> > > new components while at the same time allowing more expressiveness.
> This
> > > becomes similar to the createTenant task which also has everything
> > optional
> > > except the tenantId and tenantName
> > >
> > > Taher Alkhateeb
> > >
> > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits  >
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Currently our create component process (./gradlew createComponent) is
> > > error
> > > > prone.
> > > >
> > > > It requires 4 variables to successfully create a new component in the
> > > > hot-deploy folder to jumpstart development with a component skeleton.
> > > These
> > > > variables are:
> > > >
> > > >- componentName
> > > >- componentResourceName
> > > >- webappName
> > > >- basePermission
> > > >
> > > > I believe we should reduce the number of variables to just 1 variable
> > > (e.g.
> > > > componentId) to create consistency throughout the skeleton and its
> > > > associated datasets. The developer can, after a skeleton has been
> > built,
> > > > then apply any kind of changes according to his/her requirements an
> > > needs.
> > > >
> > > > What is your opinion on this?
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM 
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > >
> >
>

Re: [DISCUSSION] Simplification of the create component process

Noted, thank you.

On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits 
wrote:

> Hi Taher,
>
> OFBTOOLS is not required as it is already defined in the template to be
> included. When added in basePermission it leads to duplication in the
> generated ofbiz-component.xml file.
>
> I already created an issue for that, see
> https://issues.apache.org/jira/browse/OFBIZ-7785
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> slidingfilame...@gmail.com> wrote:
>
> > Hi Pierre,
> >
> > Hmmm, that's actually a nice idea. I suggest however we avoid componentId
> > and just apply the following to the variables:
> >
> > componentName: mandatory
> > componentResourceName: optional, defaults to componentName
> > webappName: optional, defaults to componentName
> > basePermission: optional, defaults to OFBTOOLS (or whatever defaults
> were)
> >
> > This way, You get a real nice and simple command for end-users to create
> > new components while at the same time allowing more expressiveness. This
> > becomes similar to the createTenant task which also has everything
> optional
> > except the tenantId and tenantName
> >
> > Taher Alkhateeb
> >
> > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits 
> > wrote:
> >
> > > Hi all,
> > >
> > > Currently our create component process (./gradlew createComponent) is
> > error
> > > prone.
> > >
> > > It requires 4 variables to successfully create a new component in the
> > > hot-deploy folder to jumpstart development with a component skeleton.
> > These
> > > variables are:
> > >
> > >- componentName
> > >- componentResourceName
> > >- webappName
> > >- basePermission
> > >
> > > I believe we should reduce the number of variables to just 1 variable
> > (e.g.
> > > componentId) to create consistency throughout the skeleton and its
> > > associated datasets. The developer can, after a skeleton has been
> built,
> > > then apply any kind of changes according to his/her requirements an
> > needs.
> > >
> > > What is your opinion on this?
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM 
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> >
>

Re: [DISCUSSION] Simplification of the create component process

Hi Taher,

OFBTOOLS is not required as it is already defined in the template to be
included. When added in basePermission it leads to duplication in the
generated ofbiz-component.xml file.

I already created an issue for that, see
https://issues.apache.org/jira/browse/OFBIZ-7785

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:

> Hi Pierre,
>
> Hmmm, that's actually a nice idea. I suggest however we avoid componentId
> and just apply the following to the variables:
>
> componentName: mandatory
> componentResourceName: optional, defaults to componentName
> webappName: optional, defaults to componentName
> basePermission: optional, defaults to OFBTOOLS (or whatever defaults were)
>
> This way, You get a real nice and simple command for end-users to create
> new components while at the same time allowing more expressiveness. This
> becomes similar to the createTenant task which also has everything optional
> except the tenantId and tenantName
>
> Taher Alkhateeb
>
> On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits 
> wrote:
>
> > Hi all,
> >
> > Currently our create component process (./gradlew createComponent) is
> error
> > prone.
> >
> > It requires 4 variables to successfully create a new component in the
> > hot-deploy folder to jumpstart development with a component skeleton.
> These
> > variables are:
> >
> >- componentName
> >- componentResourceName
> >- webappName
> >- basePermission
> >
> > I believe we should reduce the number of variables to just 1 variable
> (e.g.
> > componentId) to create consistency throughout the skeleton and its
> > associated datasets. The developer can, after a skeleton has been built,
> > then apply any kind of changes according to his/her requirements an
> needs.
> >
> > What is your opinion on this?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM 
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
>

Re: [DISCUSSION] Simplification of the create component process

Hi Pierre,

Hmmm, that's actually a nice idea. I suggest however we avoid componentId
and just apply the following to the variables:

componentName: mandatory
componentResourceName: optional, defaults to componentName
webappName: optional, defaults to componentName
basePermission: optional, defaults to OFBTOOLS (or whatever defaults were)

This way, You get a real nice and simple command for end-users to create
new components while at the same time allowing more expressiveness. This
becomes similar to the createTenant task which also has everything optional
except the tenantId and tenantName

Taher Alkhateeb

On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits 
wrote:

> Hi all,
>
> Currently our create component process (./gradlew createComponent) is error
> prone.
>
> It requires 4 variables to successfully create a new component in the
> hot-deploy folder to jumpstart development with a component skeleton. These
> variables are:
>
>- componentName
>- componentResourceName
>- webappName
>- basePermission
>
> I believe we should reduce the number of variables to just 1 variable (e.g.
> componentId) to create consistency throughout the skeleton and its
> associated datasets. The developer can, after a skeleton has been built,
> then apply any kind of changes according to his/her requirements an needs.
>
> What is your opinion on this?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>

[DISCUSSION] Simplification of the create component process

Hi all,

Currently our create component process (./gradlew createComponent) is error
prone.

It requires 4 variables to successfully create a new component in the
hot-deploy folder to jumpstart development with a component skeleton. These
variables are:

   - componentName
   - componentResourceName
   - webappName
   - basePermission

I believe we should reduce the number of variables to just 1 variable (e.g.
componentId) to create consistency throughout the skeleton and its
associated datasets. The developer can, after a skeleton has been built,
then apply any kind of changes according to his/her requirements an needs.

What is your opinion on this?

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

Re: Temporary change for filling the "Fix Versions/s" field in Jira

2016-07-19 Thread Pranay Pandey

Thanks for the note Jacques.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Mon, Jul 18, 2016 at 9:46 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Committer, Devs, All,
>
> You might have noticed I Temporary changed our policy about filling the
> "Fix Versions/s" field in Jira
>
> Please read
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=7766050=46=45
>
> Thanks
>
> Jacques
>
>

[jira] [Assigned] (OFBIZ-7896) Order: Remove inline js for toggleAll, checkToggle and selectAll calling from ftls.

2016-07-19 Thread Pranay Pandey (JIRA)


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

Pranay Pandey reassigned OFBIZ-7896:


Assignee: Pranay Pandey  (was: Amardeep Singh Jhajj)

> Order: Remove inline js for toggleAll, checkToggle and selectAll calling from 
> ftls.
> ---
>
> Key: OFBIZ-7896
> URL: https://issues.apache.org/jira/browse/OFBIZ-7896
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: order
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Pranay Pandey
> Attachments: OFBIZ-7896.patch
>
>
> Remove inline js for toggleAll, checkToggle and selectAll calling from ftls 
> in Order component. Add class="selectAll" on parent checkbox element for 
> select all functionality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OFBIZ-7720) Write one generic functionality for select all checkbox by removing currently written multiple fuctionality

2016-07-19 Thread Pranay Pandey (JIRA)


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

Pranay Pandey reassigned OFBIZ-7720:


Assignee: Pranay Pandey  (was: Amardeep Singh Jhajj)

> Write one generic functionality for select all checkbox by removing currently 
> written multiple fuctionality
> ---
>
> Key: OFBIZ-7720
> URL: https://issues.apache.org/jira/browse/OFBIZ-7720
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Pranay Pandey
> Attachments: OFBIZ-7720.patch
>
>
> We have many occurrence of selectAll, toggleAll abd checkToggle function 
> calling in ftls. Example: 
> {code}
> // For selecting all the child checkboxes
>  onclick="javascript:toggleAll(this, '${selectAllFormName}');"/>
> // For selecting the child checkboxes and parent (if all child boxes is 
> selected)
>  onclick="javascript:checkToggle(this, '${selectAllFormName}');"/>
> // For selecting all the child checkboxes if parent checbox is selected on 
> page load.
>  type="text/javascript">selectAll('selectAllForm');
> {code}
> Above all functionality should be replaced using one generic utility of 
> selectAll. Example:
> {code}
> // One class "selectAll" on parent checkbox will handle all above cases.
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1752972 - in /ofbiz/trunk/applications: accounting/config/AccountingUiLabels.xml order/template/return/QuickReturn.ftl party/template/party/EditGiftCard.ftl party/template/party/profi

2016-07-19 Thread Pranay Pandey

Thanks for the comment Vikas, I agree , will add needed translations for
the newly introduced labels as well.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Mon, Jul 18, 2016 at 11:54 PM, Vikas Mayur  wrote:

> Just for a cosmetic and trivial (JIRA issue indicates that) change loosing
> the translation to 15 odd languages, is it desirable? It might be years
> effort to have the label defined in those languages.
>
>
> Regards
> Vikas
>
> On Sat, Jul 16, 2016 at 9:22 AM,  wrote:
>
> > Author: pranayp
> > Date: Sat Jul 16 14:22:18 2016
> > New Revision: 1752972
> >
> > URL: http://svn.apache.org/viewvc?rev=1752972=rev
> > Log:
> > [OFBIZ-7707] Improved payment method information UI on party profile
> > screen for creating new payment methods. Thanks Chandan Khandelwal for
> the
> > contribution.
> >
> > Modified:
> > ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml
> > ofbiz/trunk/applications/order/template/return/QuickReturn.ftl
> > ofbiz/trunk/applications/party/template/party/EditGiftCard.ftl
> >
> >
> ofbiz/trunk/applications/party/template/party/profileblocks/PaymentMethods.ftl
> >
> > Modified:
> ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml
> > URL:
> >
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml?rev=1752972=1752971=1752972=diff
> >
> >
> ==
> > --- ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml
> > (original)
> > +++ ofbiz/trunk/applications/accounting/config/AccountingUiLabels.xml Sat
> > Jul 16 14:22:18 2016
> > @@ -3555,6 +3555,18 @@
> >  æ–°å»ºæˆ æœ¬ç»„ä»¶è®¡ç®—
> >  æ–°å»ºæˆ æœ¬å…ƒä»¶è¨ˆç®—
> >  
> > +
> > +Create Credit Card
> > +à¤•à¥ à¤°à¥‡à¤¡à¤¿à¤Ÿ à¤•à¤¾à¤°à¥ à¤¡
> > à¤¬à¤¨à¤¾à¤ à¤ 
> > +
> > +
> > +Create EFT Account
> > +à¤ˆà¤ à¤«à¤¼à¤Ÿà¥€(EFT) à¤–à¤¾à¤¤à¤¾
> > à¤¬à¤¨à¤¾à¤ à¤ 
> > +
> > +
> > +Create Gift Card
> > +à¤‰à¤ªà¤¹à¤¾à¤° à¤•à¤¾à¤°à¥ à¤¡
> > à¤¬à¤¨à¤¾à¤ à¤ 
> > +
> >  
> >  Berechtigungsfehler: Um
> > 'createFixedAssetMaintOrder' auszufÃ¼hren muss man
> ACCOUNTING_CREATEUPDATE
> > or ACCOUNTING_ADMIN Berechtigungen haben
> >  Security Error: to run
> > createFixedAssetMaintOrder you must have the ACCOUNTING_CREATEUPDATE or
> > ACCOUNTING_ADMIN permission, or the limited ACCOUNTING_ROLE_CREATE
> > permission
> > @@ -3570,25 +3582,6 @@
> >  å®‰å…¨é”™è¯¯ï¼šè¦ è¿
> > è¡Œæ–°å»ºå›ºå®šèµ„äº§ç»´ä¿®ä¿ å…»è®¢å
> > •(createFixedAssetMaintOrder)ï¼Œä½
> å¿…é¡»æœ‰ACCOUNTING_CREATEUPDATEæˆ–ACCOUNTING_ADMINæ
> > ƒé™ ï¼Œæˆ–è€…å —é™ åˆ¶çš„ACCOUNTING_ROLE_CREATEæ ƒé™ 
> >  å®‰å…¨éŒ¯èª¤:è¦
> > åŸ·è¡Œæ–°å»ºå›ºå®šè³‡ç”¢ç¶ä¿®ä¿
> > é¤Šè¨‚å–®(createFixedAssetMaintOrder),ä½ å¿…é
> ˆæœ‰ACCOUNTING_CREATEUPDATEæˆ–ACCOUNTING_ADMINæ¬Šé™
> > ,æˆ–è€…å —é™ åˆ¶çš„ACCOUNTING_ROLE_CREATEæ¬Šé™ 
> >  
> > -
> > -Ø®Ù„Ù‚ Ø¨Ø·Ø§Ù‚Ø© Ø§Ø¦ØªÙ…Ø§Ù†
> > Ø¬Ø¯ÙŠØ¯Ø©
> > -Neue Kreditkarte erstellen
> > -Create New Credit Card
> > -Crear nueva tarjeta de crÃ©dito
> > -Enregistrer une nouvelle carte de
> > crÃ©dit
> > -à¤¨à¤¯à¤¾ à¤•à¥ à¤°à¥‡à¤¡à¤¿à¤Ÿ
> > à¤•à¤¾à¤°à¥ à¤¡ à¤¬à¤¨à¤¾à¤ à¤ 
> > -Creare Nuova Carta Credito
> > -æ–°è¦ ã‚¯ãƒ¬ã‚¸ãƒƒãƒˆã‚«ãƒ¼ãƒ‰ã‚’ä½œæˆ
> > 
> > -Nieuwe kredietkaart aanmaken
> > -Criar Novo CartÃ£o de CrÃ©dito
> > -Criar Novo CartÃ£o de
> CrÃ©dito
> > -Creaza Noua Carte de Credit
> > -Ð¡Ð¾Ð·Ð´Ð°Ñ‚ÑŒ Ð½Ð¾Ð²ÑƒÑŽ
> ÐºÑ€ÐµÐ´Ð¸Ñ‚Ð½ÑƒÑŽ
> > ÐºÐ°Ñ€Ñ‚Ñƒ
> > - >
> xml:lang="th">à¸ªà¸£à¹‰à¸²à¸‡à¸šà¸±à¸•à¸£à¹€à¸„à¸£à¸”à¸´à¸•à¹ƒà¸«à¸¡à¹ˆ
> > -ThÃªm má»›i Tháº» tÃn dá»¥ng
> > -åˆ›å»ºæ–°ä¿¡ç”¨å ¡
> > -æ–°å»ºæ–°ä¿¡ç”¨å ¡
> > -
> >  
> >  Ø®Ù„Ù‚ Ø¯Ù Ø¹Ø© Ø§ÙŠØ¯Ø§Ø¹
> Ø¬Ø¯ÙŠØ¯Ø©
> >  Neue Einzahlung
> > @@ -3637,25 +3630,6 @@
> >  ä¸ºè´¢åŠ¡è´¦æˆ·æ–°å»ºå˜æ¬¾å
> > •ï¼š${finAccount.finAccountName} [${finAccountId}]
> >   >
> xml:lang="zh-TW">ç‚ºè²¡å‹™å¸³æˆ¶æ–°å»ºå˜æ¬¾å–®:${finAccount.finAccountName}
> > [${finAccountId}]
> >  
> > -
> > -Ø®Ù„Ù‚ ØØ³Ø§Ø¨ EFT Ø¬Ø¯ÙŠØ¯
> > -Neue Bankverbindung erstellen
> > -Create New EFT Account
> > -Crear una nueva cuenta EFT
> > -Enregistrer un nouveau compte de virement
> > Ã©lectronique
> > -à¤¨à¤¯à¤¾  à¤ˆà¤ à¤«à¤¼à¤Ÿà¥€(EFT)
> > à¤–à¤¾à¤¤à¤¾ à¤¬à¤¨à¤¾à¤ à¤ 
> > -Creare Nuovo Conto EFT
> > -æ–°è¦ é›»å å
> > –å¼•(EFT)ã‚¢ã‚«ã‚¦ãƒ³ãƒˆã‚’ä½œæˆ 
> > -Nieuwe bankrekening aanmaken
> > -Criar Nova Conta EFT
> > -Criar Nova Conta EFT
> > -Creaza un Cont nou EFT
> > -Ð¡Ð¾Ð·Ð´Ð°Ñ‚ÑŒ Ð½Ð¾Ð²Ñ‹Ð¹ Ð±Ð°Ð½ÐºÐ¾Ð²Ñ
> > ÐºÐ¸Ð¹ Ñ Ñ‡ÐµÑ‚
> > -à¸ªà¸£à¹‰à¸²à¸‡à¸šà¸±à¸
> > à¸Šà¸µà¸˜à¸™à¸²à¸„à¸²à¸£à¹ƒà¸«à¸¡à¹ˆ
> > -

Re: Proposal to modify the testing framework for OFBiz

2016-07-19 Thread Scott Gray

I think people are missing my point because they keep replying with generic
statements that aren't specific to unit tests.

On 19 July 2016 at 20:08, Montalbano Florian 
wrote:

> Hi everyone,
>
> unit tests and integration tests are complementary and with test, the more
> the better.
> Implementing unit tests will be a great load of work but it is the same
> with every kind of test. As Taher said, we will gain a lot from those unit
> tests for avoiding regression while refactoring the framework. From the
> start component scope, it has already be proved useful.
> And what Ron said about encouraging the creation of "smaller class that
> can be tested easily" is very important too. It can be a first step to
> reach TDD in the OFBiz development. TDD can help to give confidence to
> newcomer and veteran when updating some part of the code and as Hans said,
> this lead to "continuous improvement and finally continuous deployment".
>
> I'm aware that this does not solve the technical implementation stuff, but
> I think this is an improvement that need to be supported.
>
> Have a nice day,
>
> Florian Montalbano
>
>
> Le 19/07/2016 09:04, Pierre Smits a écrit :
>
>> As with anything, the law of diminishing returns also applies to OFBiz and
>> tests. This is not true for unit tests and system integration tests, but
>> also for user acceptance and performance tests.
>>
>> Nevertheless, the work done up to now is a good start and - I feel
>> confident - appreciated. And unit tests are certainly valuable in the
>> framework stack. How it will be for functions (regarding components in
>> application and special purpose stack) needs to be addressed when we reach
>> that bridge.
>>
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb <
>> slidingfilame...@gmail.com
>>
>>> wrote:
>>> Hi Scott,
>>>
>>> Well spoken thank you. Okay may I suggest that for any such work we will
>>> discuss it here see its Merit and if it makes sense then we take it in.
>>> It
>>> is a little early to discuss it right now because we did not yet go to
>>> the
>>> higher-level components. Once we do I'll be sure to have a conversation
>>> about this in here and would appreciate your input to it.
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Jul 19, 2016 9:00 AM, "Scott Gray" 
>>> wrote:
>>>
>>> Yeah I'm sure unit tests probably worked well for the start component

>>> given
>>>
 it is the lowest level component in the system and closest to a basic

>>> java
>>>
 app.  I just think the value proposition might decrease the further up

>>> the
>>>
 stack we move with them.  I'm not against unit tests when they prove
 useful, but further up the stack I think we should prove the case for

>>> them
>>>
 before doing much work to support the mocking that will be required to

>>> keep
>>>
 them inline with 'best practices'.

 In OFBiz "bad or unwanted" tends to come mostly in the way of increasing
 complexity from features that require more effort to maintain than the
 value they provide to the community.  I think there's a chance
 attempting
 to mock service tests could fall into that bucket.  I could be wrong,

>>> but I
>>>
 think it's worth looking into before we declare that unit tests are the
 best form of testing for OFBiz.

 Regards
 Scott

 On 19 July 2016 at 17:37, Taher Alkhateeb 
 wrote:

 Hi Scott,
>
> Thank you for the feedback. To be focused exactly on integration vs
>
 unit, I

> already mentioned above that at least for me the main objective is to
> confidently and quickly run the tests in short bursts of red-green
> refactor. This allows me to refactor code without waiting in front of
>
 the
>>>
 screen in between test cycles thus giving me immediate feedback on any
> errors I made. Perhaps my intro was too long so this is the squeezed
>
 out
>>>
 version of it.
>
> I already had one round of testing in the start component which was
>
 much
>>>
 faster that way and had an immediate impact. Oh and by the way, you
>
 cannot

> test the start component with integration tests for example unless you
>
 do
>>>
 it from an external component which cannot access package protected
>
 items.

> This style of coding is applicable I think to any software project
> inclusive of OFBiz. Maybe in certain components more than others or
>
 certain

> areas more than others. But I can't see how it could be bad or
>
 unwanted.
>>>
 Taher Alkhateeb
>
> On Jul 19, 2016 8:18 AM, "Scott Gray"

[jira] [Commented] (OFBIZ-7900) Exception in Multi-Tenant Env - When Using an non existence Tenant ID


[ 
https://issues.apache.org/jira/browse/OFBIZ-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383769#comment-15383769
 ] 

Pierre Smits commented on OFBIZ-7900:
-

Hi [~dereklew],

Restating posting in dev ml:
{quote}
FWIW, I regard ant load-demo-multitenant as a deprecated set of functionalities.

The best process to setup tenant is to use the ./ant create-tenant task. 
{quote}

> Exception in Multi-Tenant Env - When Using an non existence Tenant ID
> -
>
> Key: OFBIZ-7900
> URL: https://issues.apache.org/jira/browse/OFBIZ-7900
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 14.12
> Environment: Win 10, Derby
>Reporter: Derek Lew
>Priority: Minor
>
> Steps to recreate:
> 1) Enable Multi-tenant, and using only the default derby DB
> 2) ant clean-all
> 3) ant load-demo-multitenant
> 4) ./tools/startofbiz.bat
> 5) go to https://localhost:8443/partymgr/control/login
> 6) login using admin/ofbiz/DEMO3, DEMO3 being the non existence tenant ID.  
> And you got the following error:
> 2016-07-19 15:13:59,397 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-enumeration-valid: Value 'Themes' is not facet-valid 
> with respect to enumeration '[main, secondary]'. It must be a value from the 
> enumeration.
> 2016-07-19 15:13:59,397 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-attribute.3: The value 'Themes' of attribute 
> 'menu-name' on element 'webapp' is not valid with respect to its type, 
> '#AnonType_menu-nameattlist.webapp'.
> 2016-07-19 15:13:59,407 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-enumeration-valid: Value 'Themes' is not facet-valid 
> with respect to enumeration '[main, secondary]'. It must be a value from the 
> enumeration.
> 2016-07-19 15:13:59,407 |main |UtilXml   
> |E| XmlFileLoader: File 
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
> 63. Error message: cvc-attribute.3: The value 'Themes' of attribute 
> 'menu-name' on element 'webapp' is not valid with respect to its type, 
> '#AnonType_menu-nameattlist.webapp'.
> 2016-07-19 15:14:17,357 |delegator-startup-9  |DelegatorFactoryImpl  
> |E| Error creating delegator
> org.ofbiz.entity.GenericEntityException: No Tenant record found for delegator 
> [default#DEMO3] with tenantId [DEMO3]
>   at org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:202) 
> ~[ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:200) 
> [ofbiz-base.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
>  [ofbiz-entity.jar:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [?:1.8.0_92]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [?:1.8.0_92]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [?:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:1.8.0_92]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:1.8.0_92]
>   at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
> 2016-07-19 15:14:17,363 |delegator-startup-9  |DelegatorFactoryImpl  
> |E| null
> java.lang.ClassNotFoundException: java.lang.Class
>   at 
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:205) 
> ~[ofbiz-base.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
>  [ofbiz-entity.jar:?]
>   at 
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
>

Re: Proposal to modify the testing framework for OFBiz

2016-07-19 Thread Montalbano Florian


Hi everyone,

unit tests and integration tests are complementary and with test, the 
more the better.
Implementing unit tests will be a great load of work but it is the same 
with every kind of test. As Taher said, we will gain a lot from those 
unit tests for avoiding regression while refactoring the framework. From 
the start component scope, it has already be proved useful.
And what Ron said about encouraging the creation of "smaller class that 
can be tested easily" is very important too. It can be a first step to 
reach TDD in the OFBiz development. TDD can help to give confidence to 
newcomer and veteran when updating some part of the code and as Hans 
said, this lead to "continuous improvement and finally continuous 
deployment".


I'm aware that this does not solve the technical implementation stuff, 
but I think this is an improvement that need to be supported.


Have a nice day,

Florian Montalbano

Le 19/07/2016 09:04, Pierre Smits a écrit :

As with anything, the law of diminishing returns also applies to OFBiz and
tests. This is not true for unit tests and system integration tests, but
also for user acceptance and performance tests.

Nevertheless, the work done up to now is a good start and - I feel
confident - appreciated. And unit tests are certainly valuable in the
framework stack. How it will be for functions (regarding components in
application and special purpose stack) needs to be addressed when we reach
that bridge.


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb 
wrote:


Yeah I'm sure unit tests probably worked well for the start component

given

it is the lowest level component in the system and closest to a basic

java

app.  I just think the value proposition might decrease the further up

the

stack we move with them.  I'm not against unit tests when they prove
useful, but further up the stack I think we should prove the case for

them

before doing much work to support the mocking that will be required to

keep

them inline with 'best practices'.

In OFBiz "bad or unwanted" tends to come mostly in the way of increasing
complexity from features that require more effort to maintain than the
value they provide to the community.  I think there's a chance attempting
to mock service tests could fall into that bucket.  I could be wrong,

but I

think it's worth looking into before we declare that unit tests are the
best form of testing for OFBiz.

Regards
Scott

On 19 July 2016 at 17:37, Taher Alkhateeb 
wrote:


Hi Scott,

Thank you for the feedback. To be focused exactly on integration vs

unit, I

already mentioned above that at least for me the main objective is to
confidently and quickly run the tests in short bursts of red-green
refactor. This allows me to refactor code without waiting in front of

the

screen in between test cycles thus giving me immediate feedback on any
errors I made. Perhaps my intro was too long so this is the squeezed

out

version of it.

I already had one round of testing in the start component which was

much

faster that way and had an immediate impact. Oh and by the way, you

cannot

test the start component with integration tests for example unless you

do

it from an external component which cannot access package protected

items.

This style of coding is applicable I think to any software project
inclusive of OFBiz. Maybe in certain components more than others or

certain

areas more than others. But I can't see how it could be bad or

unwanted.

Taher Alkhateeb

On Jul 19, 2016 8:18 AM, "Scott Gray" 
wrote:


Thanks Ron and Taher for your responses, I appreciate them but I

don't

hear

much in the conversation that speaks to the value of unit tests over
integration tests.  Most of the thoughts shared speaks more to the

value

of

tests rather than differences in the type of tests.

Speed: At an application level we have ~685 tests that run in 35

seconds

(excluding build and data load).  Another point is that there isn't

much

reason why tests can't be run in parallel rather than sequentially.
TDD: Integration tests in OFBiz are as simple if not simpler to write

than

unit tests and just as useful for TDD.
I'm not sure if I missed any other points raised regarding

integration

vs.

unit tests?

I'm not looking to start a big long debate

Re: Temporary change for filling the "Fix Versions/s" field in Jira

2016-07-19 Thread gil portenseigne


Thanks Jacques for the update :)

Gil


Le 18/07/2016 à 18:16, Jacques Le Roux a écrit :

Hi Committer, Devs, All,

You might have noticed I Temporary changed our policy about filling 
the "Fix Versions/s" field in Jira


Please read 
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=7766050=46=45


Thanks

Jacques

Re: [jira] [Created] (OFBIZ-7900) Exception in Multi-Tenant Env - When Using an non existence Tenant ID

Hi Derek,

FWIW, I regard ant load-demo-multitenant as a deprecated set of
functionalities.

The best process to setup tenant is to use the ./ant create-tenant task.

Best regards,


Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 9:18 AM, Derek Lew (JIRA)  wrote:

> Derek Lew created OFBIZ-7900:
> 
>
>  Summary: Exception in Multi-Tenant Env - When Using an non
> existence Tenant ID
>  Key: OFBIZ-7900
>  URL: https://issues.apache.org/jira/browse/OFBIZ-7900
>  Project: OFBiz
>   Issue Type: Bug
>   Components: framework
> Affects Versions: Release Branch 14.12
>  Environment: Win 10, Derby
> Reporter: Derek Lew
> Priority: Minor
>
>
> Steps to recreate:
>
> 1) Enable Multi-tenant, and using only the default derby DB
> 2) ant clean-all
> 3) ant load-demo-multitenant
> 4) ./tools/startofbiz.bat
> 5) go to https://localhost:8443/partymgr/control/login
> 6) login using admin/ofbiz/DEMO3, DEMO3 being the non existence tenant
> ID.  And you got the following error:
>
> 2016-07-19 15:13:59,397 |main |UtilXml
>|E| XmlFileLoader: File
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error.
> Line: 63. Error message: cvc-enumeration-valid: Value 'Themes' is not
> facet-valid with respect to enumeration '[main, secondary]'. It must be a
> value from the enumeration.
> 2016-07-19 15:13:59,397 |main |UtilXml
>|E| XmlFileLoader: File
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error.
> Line: 63. Error message: cvc-attribute.3: The value 'Themes' of attribute
> 'menu-name' on element 'webapp' is not valid with respect to its type,
> '#AnonType_menu-nameattlist.webapp'.
> 2016-07-19 15:13:59,407 |main |UtilXml
>|E| XmlFileLoader: File
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error.
> Line: 63. Error message: cvc-enumeration-valid: Value 'Themes' is not
> facet-valid with respect to enumeration '[main, secondary]'. It must be a
> value from the enumeration.
> 2016-07-19 15:13:59,407 |main |UtilXml
>|E| XmlFileLoader: File
> file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error.
> Line: 63. Error message: cvc-attribute.3: The value 'Themes' of attribute
> 'menu-name' on element 'webapp' is not valid with respect to its type,
> '#AnonType_menu-nameattlist.webapp'.
> 2016-07-19 15:14:17,357 |delegator-startup-9  |DelegatorFactoryImpl
>   |E| Error creating delegator
> org.ofbiz.entity.GenericEntityException: No Tenant record found for
> delegator [default#DEMO3] with tenantId [DEMO3]
> at
> org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:202)
> ~[ofbiz-entity.jar:?]
> at
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33)
> [ofbiz-entity.jar:?]
> at
> org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25)
> [ofbiz-entity.jar:?]
> at
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:200)
> [ofbiz-base.jar:?]
> at
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
> [ofbiz-entity.jar:?]
> at
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
> [ofbiz-entity.jar:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_92]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [?:1.8.0_92]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_92]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [?:1.8.0_92]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [?:1.8.0_92]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [?:1.8.0_92]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [?:1.8.0_92]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
> 2016-07-19 15:14:17,363 |delegator-startup-9  |DelegatorFactoryImpl
>   |E| null
> java.lang.ClassNotFoundException: java.lang.Class
> at
> org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:205)
> ~[ofbiz-base.jar:?]
> at
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
> [ofbiz-entity.jar:?]
> at
> org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
> [ofbiz-entity.jar:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [?:1.8.0_92]
> at
>

[jira] [Created] (OFBIZ-7900) Exception in Multi-Tenant Env - When Using an non existence Tenant ID

2016-07-19 Thread Derek Lew (JIRA)

Derek Lew created OFBIZ-7900:


 Summary: Exception in Multi-Tenant Env - When Using an non 
existence Tenant ID
 Key: OFBIZ-7900
 URL: https://issues.apache.org/jira/browse/OFBIZ-7900
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 14.12
 Environment: Win 10, Derby
Reporter: Derek Lew
Priority: Minor


Steps to recreate:

1) Enable Multi-tenant, and using only the default derby DB
2) ant clean-all
3) ant load-demo-multitenant
4) ./tools/startofbiz.bat
5) go to https://localhost:8443/partymgr/control/login
6) login using admin/ofbiz/DEMO3, DEMO3 being the non existence tenant ID.  And 
you got the following error:

2016-07-19 15:13:59,397 |main |UtilXml   
|E| XmlFileLoader: File 
file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
63. Error message: cvc-enumeration-valid: Value 'Themes' is not facet-valid 
with respect to enumeration '[main, secondary]'. It must be a value from the 
enumeration.
2016-07-19 15:13:59,397 |main |UtilXml   
|E| XmlFileLoader: File 
file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
63. Error message: cvc-attribute.3: The value 'Themes' of attribute 'menu-name' 
on element 'webapp' is not valid with respect to its type, 
'#AnonType_menu-nameattlist.webapp'.
2016-07-19 15:13:59,407 |main |UtilXml   
|E| XmlFileLoader: File 
file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
63. Error message: cvc-enumeration-valid: Value 'Themes' is not facet-valid 
with respect to enumeration '[main, secondary]'. It must be a value from the 
enumeration.
2016-07-19 15:13:59,407 |main |UtilXml   
|E| XmlFileLoader: File 
file:/E:/OfBiz14.12/themes/ecdefault/ofbiz-component.xml process error. Line: 
63. Error message: cvc-attribute.3: The value 'Themes' of attribute 'menu-name' 
on element 'webapp' is not valid with respect to its type, 
'#AnonType_menu-nameattlist.webapp'.
2016-07-19 15:14:17,357 |delegator-startup-9  |DelegatorFactoryImpl  
|E| Error creating delegator
org.ofbiz.entity.GenericEntityException: No Tenant record found for delegator 
[default#DEMO3] with tenantId [DEMO3]
at org.ofbiz.entity.GenericDelegator.(GenericDelegator.java:202) 
~[ofbiz-entity.jar:?]
at 
org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:33) 
[ofbiz-entity.jar:?]
at 
org.ofbiz.entity.DelegatorFactoryImpl.getInstance(DelegatorFactoryImpl.java:25) 
[ofbiz-entity.jar:?]
at 
org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:200) 
[ofbiz-base.jar:?]
at 
org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
 [ofbiz-entity.jar:?]
at 
org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
 [ofbiz-entity.jar:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[?:1.8.0_92]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 [?:1.8.0_92]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 [?:1.8.0_92]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:1.8.0_92]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:1.8.0_92]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
2016-07-19 15:14:17,363 |delegator-startup-9  |DelegatorFactoryImpl  
|E| null
java.lang.ClassNotFoundException: java.lang.Class
at 
org.ofbiz.base.util.UtilObject.getObjectFromFactory(UtilObject.java:205) 
~[ofbiz-base.jar:?]
at 
org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:83)
 [ofbiz-entity.jar:?]
at 
org.ofbiz.entity.DelegatorFactory$DelegatorConfigurable.call(DelegatorFactory.java:74)
 [ofbiz-entity.jar:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[?:1.8.0_92]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_92]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 [?:1.8.0_92]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 [?:1.8.0_92]
at

Re: Proposal to modify the testing framework for OFBiz

As with anything, the law of diminishing returns also applies to OFBiz and
tests. This is not true for unit tests and system integration tests, but
also for user acceptance and performance tests.

Nevertheless, the work done up to now is a good start and - I feel
confident - appreciated. And unit tests are certainly valuable in the
framework stack. How it will be for functions (regarding components in
application and special purpose stack) needs to be addressed when we reach
that bridge.


Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 8:22 AM, Taher Alkhateeb  wrote:

> Hi Scott,
>
> Well spoken thank you. Okay may I suggest that for any such work we will
> discuss it here see its Merit and if it makes sense then we take it in. It
> is a little early to discuss it right now because we did not yet go to the
> higher-level components. Once we do I'll be sure to have a conversation
> about this in here and would appreciate your input to it.
>
> Regards,
>
> Taher Alkhateeb
>
> On Jul 19, 2016 9:00 AM, "Scott Gray" 
> wrote:
>
> > Yeah I'm sure unit tests probably worked well for the start component
> given
> > it is the lowest level component in the system and closest to a basic
> java
> > app.  I just think the value proposition might decrease the further up
> the
> > stack we move with them.  I'm not against unit tests when they prove
> > useful, but further up the stack I think we should prove the case for
> them
> > before doing much work to support the mocking that will be required to
> keep
> > them inline with 'best practices'.
> >
> > In OFBiz "bad or unwanted" tends to come mostly in the way of increasing
> > complexity from features that require more effort to maintain than the
> > value they provide to the community.  I think there's a chance attempting
> > to mock service tests could fall into that bucket.  I could be wrong,
> but I
> > think it's worth looking into before we declare that unit tests are the
> > best form of testing for OFBiz.
> >
> > Regards
> > Scott
> >
> > On 19 July 2016 at 17:37, Taher Alkhateeb 
> > wrote:
> >
> > > Hi Scott,
> > >
> > > Thank you for the feedback. To be focused exactly on integration vs
> > unit, I
> > > already mentioned above that at least for me the main objective is to
> > > confidently and quickly run the tests in short bursts of red-green
> > > refactor. This allows me to refactor code without waiting in front of
> the
> > > screen in between test cycles thus giving me immediate feedback on any
> > > errors I made. Perhaps my intro was too long so this is the squeezed
> out
> > > version of it.
> > >
> > > I already had one round of testing in the start component which was
> much
> > > faster that way and had an immediate impact. Oh and by the way, you
> > cannot
> > > test the start component with integration tests for example unless you
> do
> > > it from an external component which cannot access package protected
> > items.
> > >
> > > This style of coding is applicable I think to any software project
> > > inclusive of OFBiz. Maybe in certain components more than others or
> > certain
> > > areas more than others. But I can't see how it could be bad or
> unwanted.
> > >
> > > Taher Alkhateeb
> > >
> > > On Jul 19, 2016 8:18 AM, "Scott Gray" 
> > > wrote:
> > >
> > > > Thanks Ron and Taher for your responses, I appreciate them but I
> don't
> > > hear
> > > > much in the conversation that speaks to the value of unit tests over
> > > > integration tests.  Most of the thoughts shared speaks more to the
> > value
> > > of
> > > > tests rather than differences in the type of tests.
> > > >
> > > > Speed: At an application level we have ~685 tests that run in 35
> > seconds
> > > > (excluding build and data load).  Another point is that there isn't
> > much
> > > > reason why tests can't be run in parallel rather than sequentially.
> > > > TDD: Integration tests in OFBiz are as simple if not simpler to write
> > > than
> > > > unit tests and just as useful for TDD.
> > > > I'm not sure if I missed any other points raised regarding
> integration
> > > vs.
> > > > unit tests?
> > > >
> > > > I'm not looking to start a big long debate on the topic, I just
> wanted
> > to
> > > > speak out that someone out there (me) doesn't think unit tests are
> the
> > > best
> > > > solution for testing OFBiz applications.
> > > >
> > > > Regards
> > > > Scott
> > > >
> > > > On 19 July 2016 at 16:52, Taher Alkhateeb <
> slidingfilame...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Scott,
> > > > >
> > > > > Thank you for your input. Your ideas are thought provoking and
> > > enriching
> > > > to
> > > > > the conversation.
> > > > >
> > > > > The way I look at it, the general rule is usually many unit tests,
> > less

[jira] [Commented] (OFBIZ-7896) Order: Remove inline js for toggleAll, checkToggle and selectAll calling from ftls.


[ 
https://issues.apache.org/jira/browse/OFBIZ-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383660#comment-15383660
 ] 

Amardeep Singh Jhajj commented on OFBIZ-7896:
-

Steps to test it:

Test selectAll functionality over ReturnItems screen.

1. Create Return.
2. Go to return item screen- 
https://ofbiz-trunk.hotwaxsystems.com/ordermgr/control/returnItems
3. Check/ Uncheck parent checkbox, its all child boxes should be 
checked/unchecked.
4. Parent checkbox should be checked, if its all child boxes is checked.

Test selectAll functionality over order items screen.

1. Go to order entry.
2. Next, go to order items screen and add products to order.
3. Check/ Uncheck parent checkbox of order items, its all child boxes should be 
checked/unchecked.
4. Parent checkbox should be checked, if its all child boxes is checked.




> Order: Remove inline js for toggleAll, checkToggle and selectAll calling from 
> ftls.
> ---
>
> Key: OFBIZ-7896
> URL: https://issues.apache.org/jira/browse/OFBIZ-7896
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: order
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
> Attachments: OFBIZ-7896.patch
>
>
> Remove inline js for toggleAll, checkToggle and selectAll calling from ftls 
> in Order component. Add class="selectAll" on parent checkbox element for 
> select all functionality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Proposal to modify the testing framework for OFBiz

Hi Scott,

Well spoken thank you. Okay may I suggest that for any such work we will
discuss it here see its Merit and if it makes sense then we take it in. It
is a little early to discuss it right now because we did not yet go to the
higher-level components. Once we do I'll be sure to have a conversation
about this in here and would appreciate your input to it.

Regards,

Taher Alkhateeb

On Jul 19, 2016 9:00 AM, "Scott Gray"  wrote:

> Yeah I'm sure unit tests probably worked well for the start component given
> it is the lowest level component in the system and closest to a basic java
> app.  I just think the value proposition might decrease the further up the
> stack we move with them.  I'm not against unit tests when they prove
> useful, but further up the stack I think we should prove the case for them
> before doing much work to support the mocking that will be required to keep
> them inline with 'best practices'.
>
> In OFBiz "bad or unwanted" tends to come mostly in the way of increasing
> complexity from features that require more effort to maintain than the
> value they provide to the community.  I think there's a chance attempting
> to mock service tests could fall into that bucket.  I could be wrong, but I
> think it's worth looking into before we declare that unit tests are the
> best form of testing for OFBiz.
>
> Regards
> Scott
>
> On 19 July 2016 at 17:37, Taher Alkhateeb 
> wrote:
>
> > Hi Scott,
> >
> > Thank you for the feedback. To be focused exactly on integration vs
> unit, I
> > already mentioned above that at least for me the main objective is to
> > confidently and quickly run the tests in short bursts of red-green
> > refactor. This allows me to refactor code without waiting in front of the
> > screen in between test cycles thus giving me immediate feedback on any
> > errors I made. Perhaps my intro was too long so this is the squeezed out
> > version of it.
> >
> > I already had one round of testing in the start component which was much
> > faster that way and had an immediate impact. Oh and by the way, you
> cannot
> > test the start component with integration tests for example unless you do
> > it from an external component which cannot access package protected
> items.
> >
> > This style of coding is applicable I think to any software project
> > inclusive of OFBiz. Maybe in certain components more than others or
> certain
> > areas more than others. But I can't see how it could be bad or unwanted.
> >
> > Taher Alkhateeb
> >
> > On Jul 19, 2016 8:18 AM, "Scott Gray" 
> > wrote:
> >
> > > Thanks Ron and Taher for your responses, I appreciate them but I don't
> > hear
> > > much in the conversation that speaks to the value of unit tests over
> > > integration tests.  Most of the thoughts shared speaks more to the
> value
> > of
> > > tests rather than differences in the type of tests.
> > >
> > > Speed: At an application level we have ~685 tests that run in 35
> seconds
> > > (excluding build and data load).  Another point is that there isn't
> much
> > > reason why tests can't be run in parallel rather than sequentially.
> > > TDD: Integration tests in OFBiz are as simple if not simpler to write
> > than
> > > unit tests and just as useful for TDD.
> > > I'm not sure if I missed any other points raised regarding integration
> > vs.
> > > unit tests?
> > >
> > > I'm not looking to start a big long debate on the topic, I just wanted
> to
> > > speak out that someone out there (me) doesn't think unit tests are the
> > best
> > > solution for testing OFBiz applications.
> > >
> > > Regards
> > > Scott
> > >
> > > On 19 July 2016 at 16:52, Taher Alkhateeb 
> > > wrote:
> > >
> > > > Hi Scott,
> > > >
> > > > Thank you for your input. Your ideas are thought provoking and
> > enriching
> > > to
> > > > the conversation.
> > > >
> > > > The way I look at it, the general rule is usually many unit tests,
> less
> > > > integration tests, lesser functional tests. So we are not excluding
> any
> > > > types of test, all of them are important in certain areas for certain
> > > > purposes with certain quantity. Usually integration tests are less
> > > because
> > > > as you said they just grab more. I like the picture below as a
> general
> > > > guideline
> > > >
> > > > http://i.stack.imgur.com/fjQvQ.png
> > > >
> > > > As you already mentioned unit tests are useful for the framework. I
> > > > discovered errors in code that I wrote which I was very very careful
> > > with.
> > > > I immediately learned the lesson that humans are not designed to
> code,
> > > and
> > > > TDD gives you confidence as you build your code with those short
> 30-60
> > > > second red-green refactors. I feel much much safer and more confident
> > > > writing code that way, the test also documents how to use the api,
> > > > refactoring and feature change becomes less terrifying. Also messy
> code

[jira] [Commented] (OFBIZ-7896) Order: Remove inline js for toggleAll, checkToggle and selectAll calling from ftls.


[ 
https://issues.apache.org/jira/browse/OFBIZ-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383641#comment-15383641
 ] 

Amardeep Singh Jhajj commented on OFBIZ-7896:
-

Please find attached patch for removal of inline toggleAll, checkToggle and 
selectAll function calling from ftls. Also removed redundant functions present 
in Javascript.ftl, which was used at one place only. Thanks.

> Order: Remove inline js for toggleAll, checkToggle and selectAll calling from 
> ftls.
> ---
>
> Key: OFBIZ-7896
> URL: https://issues.apache.org/jira/browse/OFBIZ-7896
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: order
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
> Attachments: OFBIZ-7896.patch
>
>
> Remove inline js for toggleAll, checkToggle and selectAll calling from ftls 
> in Order component. Add class="selectAll" on parent checkbox element for 
> select all functionality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OFBIZ-7720) Write one generic functionality for select all checkbox by removing currently written multiple fuctionality


[ 
https://issues.apache.org/jira/browse/OFBIZ-7720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383637#comment-15383637
 ] 

Amardeep Singh Jhajj commented on OFBIZ-7720:
-

Please find attached patch for one utility functionality for selectAll, 
toggleAll and checkToggle. Also added patch for its usage in OFBIZ-7896. Thanks.

> Write one generic functionality for select all checkbox by removing currently 
> written multiple fuctionality
> ---
>
> Key: OFBIZ-7720
> URL: https://issues.apache.org/jira/browse/OFBIZ-7720
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
> Attachments: OFBIZ-7720.patch
>
>
> We have many occurrence of selectAll, toggleAll abd checkToggle function 
> calling in ftls. Example: 
> {code}
> // For selecting all the child checkboxes
>  onclick="javascript:toggleAll(this, '${selectAllFormName}');"/>
> // For selecting the child checkboxes and parent (if all child boxes is 
> selected)
>  onclick="javascript:checkToggle(this, '${selectAllFormName}');"/>
> // For selecting all the child checkboxes if parent checbox is selected on 
> page load.
>  type="text/javascript">selectAll('selectAllForm');
> {code}
> Above all functionality should be replaced using one generic utility of 
> selectAll. Example:
> {code}
> // One class "selectAll" on parent checkbox will handle all above cases.
> 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OFBIZ-7896) Order: Remove inline js for toggleAll, checkToggle and selectAll calling from ftls.