Re: svn commit: r1594758 - /ofbiz/trunk/.gitignore

2014-05-18 Thread Jacques Le Roux

-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt


This change does not make sense. It will force people who use Git to search why 
their added component/s are ignored, I will revert it!

I add 2 other changes I have pending for months:

runtime/indexes/products/

So I agree with this one

What about adding?

framework/entity/lib/jdbc

I was reluctant because it might hide downloaded, JDBC drivers, not sure... 
opinions?

Jacques

Le 15/05/2014 04:24, hans...@apache.org a écrit :

Author: hansbak
Date: Thu May 15 02:24:27 2014
New Revision: 1594758

URL: http://svn.apache.org/r1594758
Log:
update git ignore for product indexes and components in hot-deploy

Modified:
 ofbiz/trunk/.gitignore

Modified: ofbiz/trunk/.gitignore
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.gitignore?rev=1594758r1=1594757r2=1594758view=diff
==
--- ofbiz/trunk/.gitignore (original)
+++ ofbiz/trunk/.gitignore Thu May 15 02:24:27 2014
@@ -4,7 +4,8 @@ framework/base/lib/cobertura-*.jar
  framework/base/lib/asm*.jar
  framework/base/lib/oro*.jar
  framework/entity/lib/jdbc/postgresql-*.jar
-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt
  specialpurpose/*/build
  applications/content/index/
  bin/
@@ -25,6 +26,7 @@ runtime/data/utilcache.*
  runtime/catalina/work/*
  runtime/jetty
  runtime/tempfiles/*
+runtime/indexes/products/
  themes/flatgrey/webapp/flatgrey/javascript-min.css
  themes/flatgrey/webapp/flatgrey/js/application-min.js
  themes/flatgrey/webapp/flatgrey/maincss-min.css





--


[jira] [Created] (OFBIZ-5648) Extend primary keys

2014-05-18 Thread Jacques Le Roux (JIRA)
Jacques Le Roux created OFBIZ-5648:
--

 Summary: Extend primary keys
 Key: OFBIZ-5648
 URL: https://issues.apache.org/jira/browse/OFBIZ-5648
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, 
Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux


At http://svn.apache.org/viewvc?view=revisionrevision=431009 David 
Implemented extend-entity for entity definitions to support adding field, 
relation and index elements to an entity; this is now also used to support 
further separation of the framework from the applications

But primary keys were not taken into account
{code}
// this will always be true for now as extend-entity fielsd are always nonpks
{code}

It turned I needed to extend a PK and using the attached simple 
ModelEntity.java.patch, it definitely works quite well.

I also attach a test.entity-extend.patch for testing with a localhost trunk 
demo instance
# Apply the test.entity-extend.patch
# Get to 
https://localhost:8443/webtools/control/FindGeneric?entityName=OrderHeader, you 
will see the orderId extension has been taken into account in the DB: orderId  
*   String, VARCHAR(60). I also checked creating a Postgres DB, the column 
is 60 chars wide.
# Get to 
https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
 you will see that you can't enter a PK longer than 20 chars
# Apply the ModelEntity.java.patch, clean-data load-demo, restart
# Get to 
https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
 you can enter a PK longer than 20 chars (up to 60) and create a new entity

Though I already use this change in a custom project, I will wait some time 
before committing, thanks for your reviews





--
This message was sent by Atlassian JIRA
(v6.2#6252)


Re: Duplicate webapp loads by birt component

2014-05-18 Thread Jacques Le Roux

Jacopo introduced a change to be able to move the Birt component from framework 
to specialpupose
So yes it's an intended change but I see no problems with it using trunk.
Those are loaded and used for Birt reports which are in those components

Jacques

Le 15/05/2014 18:18, c.schin...@gmail.com a écrit :

All,


I did an update from trunk and realize in the sniff test that logs show that 
birt's ofbiz-component.xml redefines three existing webapp mounts: accounting, 
facility and ordermgr. Embedded Tomcat does consequently not load these.

Is this expected behavior? Am I missing a config change for my runtime?
Or is this an issue?
If so, is there a JIRA open or does it merit one?

Thanks for letting me know.
Regards


Carsten


Gesendet von unterwegs mit BlackBerry® Webmail.




--


[jira] [Updated] (OFBIZ-5648) Extend primary keys

2014-05-18 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux updated OFBIZ-5648:
---

Attachment: test.entity-extend.patch
ModelEntity.java.patch

 Extend primary keys
 ---

 Key: OFBIZ-5648
 URL: https://issues.apache.org/jira/browse/OFBIZ-5648
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, 
 Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
  Labels: entity, extend
 Attachments: ModelEntity.java.patch, test.entity-extend.patch


 At http://svn.apache.org/viewvc?view=revisionrevision=431009 David 
 Implemented extend-entity for entity definitions to support adding field, 
 relation and index elements to an entity; this is now also used to support 
 further separation of the framework from the applications
 But primary keys were not taken into account
 {code}
 // this will always be true for now as extend-entity fielsd are always nonpks
 {code}
 It turned I needed to extend a PK and using the attached simple 
 ModelEntity.java.patch, it definitely works quite well.
 I also attach a test.entity-extend.patch for testing with a localhost trunk 
 demo instance
 # Apply the test.entity-extend.patch
 # Get to 
 https://localhost:8443/webtools/control/FindGeneric?entityName=OrderHeader, 
 you will see the orderId extension has been taken into account in the DB: 
 orderId*   String, VARCHAR(60). I also checked creating a 
 Postgres DB, the column is 60 chars wide.
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you will see that you can't enter a PK longer than 20 chars
 # Apply the ModelEntity.java.patch, clean-data load-demo, restart
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you can enter a PK longer than 20 chars (up to 60) and create a new entity
 Though I already use this change in a custom project, I will wait some time 
 before committing, thanks for your reviews



--
This message was sent by Atlassian JIRA
(v6.2#6252)


Re: Adding agreementId to OrderHeader

2014-05-18 Thread Jacques Le Roux

I don't think so

Jacques

Le 09/05/2014 11:57, Pierre Smits a écrit :

Is there a JIRA issue for this?

Regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com


On Fri, Jul 9, 2010 at 4:12 AM, BJ Freeman bjf...@free-man.net wrote:


Yes the datamodel that I referenced for partyrelationships is in Ofbiz.
However there is no supporting code that creates a partyreleationship
between the Company and Party with role of customer and
partyrelationshiptype of Customer.(CUSTOMER_REL)
So the queries I mentions will not return a list of customers that have a
partyrelationship with the company of the partyrelationshiptype of Customer.
So you cannot get agreements used for a customer this way, unless there is
an order.
I not see any code that would return agreements from a
partyrelationshiptype of Customer. In a order.


Jacopo Cappellato sent the following on 7/7/2010 11:15 PM:

  BJ,

the existing data model (as it is described in the Data Model Resource
Book as you have mentioned previously) already takes care of this and I am
not planning to change this.
My proposal was related to the agreements picked for an order.

Jacopo

On Jul 8, 2010, at 12:59 AM, BJ Freeman wrote:

  how will you get all the companies role of agreements for a particular

party that has a partyrelationship of customer?
how will you get all the Sales agreements for a partyrelationship of
customer with the company under the role of agreements?


BJ Freeman sent the following on 7/7/2010 10:19 AM:


=
BJ Freemanhttp://bjfreeman.elance.com
Strategic Power Office with Supplier Automationhttp://www.
businessesnetwork.com/automation/viewforum.php?f=52
Specialtymarket.comhttp://www.specialtymarket.com/
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man

  I have the implementation that uses the Sales agreement and a

productaggreemt for retail, wholesale, custom.
so as you think though the changes you might want to consider hooks to
allow this in future.

also the agreements are based on partyID role of customeras a
relationship with the company so I don't see how just AgreementOrderAppl
tied to the order header will accomplish this.

=
BJ Freemanhttp://bjfreeman.elance.com
Strategic Power Office with Supplier Automation
http://www.businessesnetwork.com/automation/viewforum.php?f=52
Specialtymarket.comhttp://www.specialtymarket.com/
Systems Integrator-- Glad to Assist

Chat Y! messenger: bjfr33man


Jacopo Cappellato sent the following on 7/7/2010 6:07 AM:


Thanks Scott,

the link was indeed useful.
I like the plan of creating the AgreementOrderAppl entity, because it
will be definitely very flexible.
However the existing order code (ui and business logic) is based on
the assumption that one agreement is associated to a cart/order, and I
would like to fix this process asap before enhancing the data model
with the AgreementOrderAppl entity.

So, what if I add the new field to the OrderHeader but instead of
naming it agreementId we use primaryAgreementId?

Kind regards,

Jacopo


On Jul 3, 2010, at 9:36 AM, Scott Gray wrote:

  Hi Jacopo,

Not sure if this is of any use to you:
http://ofbiz.135035.n4.nabble.com/orders-and-contracts-
td2248364.html#a2248394


Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 3/07/2010, at 6:24 PM, Jacopo Cappellato wrote:

  yes, I will do.

Jacopo

On Jul 2, 2010, at 8:01 PM, Jacques Le Roux wrote:

  Pretty logical, I see. Maybe Jacopo will consider it?

Thanks

Jacques

From: BJ Freemanbjf...@free-man.net


never saw it as enhanced only following the Data model book.
since most told me that features were not complete in ofbiz, I
completed them.
Since most of my discussion were ignored I just made my own, using
the OOTB as a basis.
I use what I can of the svn and add on top the way I see it.
=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier
Automationhttp://www.businessesnetwork.com/
automation/viewforum.php?f=52

Specialtymarket.comhttp://www.specialtymarket.com/
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Linkedinhttp://www.linkedin.com/profile?viewProfile=key=
1237480locale=en_UStrk=tab_pro

Jacques Le Roux sent the following on 7/2/2010 10:26 AM:


Interesting, so you enhanced the OOTB model and actions, right?

Jacques

From: BJ Freemanbjf...@free-man.net


I used the model on page 146
and the example agreementID 10002
since the Agreement has the product agreement, the service
matches the
product agreement productID and updates the orderitem
orderterms(page
128) and table 4.9(page 129) . an SECA checks that the order
terms can
be accepted based on the order, like a promo may be disqualified
based
on the order terms.



=
BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation

Re: Duplicate webapp loads by birt component

2014-05-18 Thread Carsten Schinzer
Thanks for the info,
I comfirm it is harmless.
Just wanted to be sure.
Regards

Carsten


2014-05-18 14:27 GMT+02:00 Jacques Le Roux jacques.le.r...@les7arts.com:

 Jacopo introduced a change to be able to move the Birt component from
 framework to specialpupose
 So yes it's an intended change but I see no problems with it using trunk.
 Those are loaded and used for Birt reports which are in those components

 Jacques

 Le 15/05/2014 18:18, c.schin...@gmail.com a écrit :

  All,


 I did an update from trunk and realize in the sniff test that logs show
 that birt's ofbiz-component.xml redefines three existing webapp mounts:
 accounting, facility and ordermgr. Embedded Tomcat does consequently not
 load these.

 Is this expected behavior? Am I missing a config change for my runtime?
 Or is this an issue?
 If so, is there a JIRA open or does it merit one?

 Thanks for letting me know.
 Regards


 Carsten


 Gesendet von unterwegs mit BlackBerry® Webmail.



 --



Re: Duplicate webapp loads by birt component

2014-05-18 Thread Jacques Le Roux

Just spotted the lines

[java] 2014-05-18 20:55:57,869 (main) [ CatalinaContainer.java:567:INFO ] 
createContext(ar)
[java] 2014-05-18 20:55:57,869 (main) [ CatalinaContainer.java:770:INFO ] Duplicate webapp mount; not loading : accounting / 
C:/projectsASF/ofbizVirgin/applications/accounting/webapp/accounting

[java] 2014-05-18 20:55:57,869 (main) [ CatalinaContainer.java:567:INFO ] 
createContext(manufacturing)
[java] 2014-05-18 20:55:57,869 (main) [ CatalinaContainer.java:770:INFO ] Duplicate webapp mount; not loading : facility / 
C:/projectsASF/ofbizVirgin/applications/product/webapp/facility

[java] 2014-05-18 20:55:57,869 (main) [ CatalinaContainer.java:567:INFO ] 
createContext(catalog)
[java] 2014-05-18 20:55:57,869 (main) [ CatalinaContainer.java:567:INFO ] 
createContext(ical)
[java] 2014-05-18 20:55:57,870 (main) [ CatalinaContainer.java:567:INFO ] 
createContext(workeffort)
[java] 2014-05-18 20:55:57,870 (main) [ CatalinaContainer.java:770:INFO ] Duplicate webapp mount; not loading : content / 
C:/projectsASF/ofbizVirgin/applications/content/webapp/content


Not sure what to do with those, Jacopo?

Jacques

Le 18/05/2014 20:11, Carsten Schinzer a écrit :

Thanks for the info,
I comfirm it is harmless.
Just wanted to be sure.
Regards

Carsten


2014-05-18 14:27 GMT+02:00 Jacques Le Roux jacques.le.r...@les7arts.com:


Jacopo introduced a change to be able to move the Birt component from
framework to specialpupose
So yes it's an intended change but I see no problems with it using trunk.
Those are loaded and used for Birt reports which are in those components

Jacques

Le 15/05/2014 18:18, c.schin...@gmail.com a écrit :

  All,


I did an update from trunk and realize in the sniff test that logs show
that birt's ofbiz-component.xml redefines three existing webapp mounts:
accounting, facility and ordermgr. Embedded Tomcat does consequently not
load these.

Is this expected behavior? Am I missing a config change for my runtime?
Or is this an issue?
If so, is there a JIRA open or does it merit one?

Thanks for letting me know.
Regards


Carsten


Gesendet von unterwegs mit BlackBerry® Webmail.




--



--


[jira] [Commented] (OFBIZ-5648) Extend primary keys

2014-05-18 Thread Adrian Crum (JIRA)

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

Adrian Crum commented on OFBIZ-5648:


I would oppose this change. Changing the pk might break all existing code.

The example you gave is overly simplistic. What would happen to existing code 
if I added a field to the pk using this feature? Think about it.


 Extend primary keys
 ---

 Key: OFBIZ-5648
 URL: https://issues.apache.org/jira/browse/OFBIZ-5648
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, 
 Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
  Labels: entity, extend
 Attachments: ModelEntity.java.patch, test.entity-extend.patch


 At http://svn.apache.org/viewvc?view=revisionrevision=431009 David 
 Implemented extend-entity for entity definitions to support adding field, 
 relation and index elements to an entity; this is now also used to support 
 further separation of the framework from the applications
 But primary keys were not taken into account
 {code}
 // this will always be true for now as extend-entity fielsd are always nonpks
 {code}
 It turned I needed to extend a PK and using the attached simple 
 ModelEntity.java.patch, it definitely works quite well.
 I also attach a test.entity-extend.patch for testing with a localhost trunk 
 demo instance
 # Apply the test.entity-extend.patch
 # Get to 
 https://localhost:8443/webtools/control/FindGeneric?entityName=OrderHeader, 
 you will see the orderId extension has been taken into account in the DB: 
 orderId*   String, VARCHAR(60). I also checked creating a 
 Postgres DB, the column is 60 chars wide.
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you will see that you can't enter a PK longer than 20 chars
 # Apply the ModelEntity.java.patch, clean-data load-demo, restart
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you can enter a PK longer than 20 chars (up to 60) and create a new entity
 Though I already use this change in a custom project, I will wait some time 
 before committing, thanks for your reviews



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (OFBIZ-5648) Extend primary keys

2014-05-18 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-5648:


Yes did not thought about adding, only changing the type. We could restrict to 
this case for PK, this should not be a problem and allow to use a longer PK 
when needed.

Note that it's currently possible to extend the PK field size but not 
completly. It's anyway currently inconsistent and confusing.

Of course you can always change the definition in the core entity model files 
(even adding another field as a PK if you want). But I want to keep these kind 
of changes out of the core files (ie extend in hot-deploy)

 Extend primary keys
 ---

 Key: OFBIZ-5648
 URL: https://issues.apache.org/jira/browse/OFBIZ-5648
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, 
 Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
  Labels: entity, extend
 Attachments: ModelEntity.java.patch, test.entity-extend.patch


 At http://svn.apache.org/viewvc?view=revisionrevision=431009 David 
 Implemented extend-entity for entity definitions to support adding field, 
 relation and index elements to an entity; this is now also used to support 
 further separation of the framework from the applications
 But primary keys were not taken into account
 {code}
 // this will always be true for now as extend-entity fielsd are always nonpks
 {code}
 It turned I needed to extend a PK and using the attached simple 
 ModelEntity.java.patch, it definitely works quite well.
 I also attach a test.entity-extend.patch for testing with a localhost trunk 
 demo instance
 # Apply the test.entity-extend.patch
 # Get to 
 https://localhost:8443/webtools/control/FindGeneric?entityName=OrderHeader, 
 you will see the orderId extension has been taken into account in the DB: 
 orderId*   String, VARCHAR(60). I also checked creating a 
 Postgres DB, the column is 60 chars wide.
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you will see that you can't enter a PK longer than 20 chars
 # Apply the ModelEntity.java.patch, clean-data load-demo, restart
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you can enter a PK longer than 20 chars (up to 60) and create a new entity
 Though I already use this change in a custom project, I will wait some time 
 before committing, thanks for your reviews



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (OFBIZ-5648) Extend primary keys

2014-05-18 Thread Adrian Crum (JIRA)

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

Adrian Crum commented on OFBIZ-5648:


You can change the pk by redefining the entity. This change is not necessary.

 Extend primary keys
 ---

 Key: OFBIZ-5648
 URL: https://issues.apache.org/jira/browse/OFBIZ-5648
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Release Branch 11.04, SVN trunk, Release Branch 12.04, 
 Release Branch 13.07
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
  Labels: entity, extend
 Attachments: ModelEntity.java.patch, test.entity-extend.patch


 At http://svn.apache.org/viewvc?view=revisionrevision=431009 David 
 Implemented extend-entity for entity definitions to support adding field, 
 relation and index elements to an entity; this is now also used to support 
 further separation of the framework from the applications
 But primary keys were not taken into account
 {code}
 // this will always be true for now as extend-entity fielsd are always nonpks
 {code}
 It turned I needed to extend a PK and using the attached simple 
 ModelEntity.java.patch, it definitely works quite well.
 I also attach a test.entity-extend.patch for testing with a localhost trunk 
 demo instance
 # Apply the test.entity-extend.patch
 # Get to 
 https://localhost:8443/webtools/control/FindGeneric?entityName=OrderHeader, 
 you will see the orderId extension has been taken into account in the DB: 
 orderId*   String, VARCHAR(60). I also checked creating a 
 Postgres DB, the column is 60 chars wide.
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you will see that you can't enter a PK longer than 20 chars
 # Apply the ModelEntity.java.patch, clean-data load-demo, restart
 # Get to 
 https://localhost:8443/webtools/control/ViewGeneric?entityName=OrderHeaderenableEdit=true,
  you can enter a PK longer than 20 chars (up to 60) and create a new entity
 Though I already use this change in a custom project, I will wait some time 
 before committing, thanks for your reviews



--
This message was sent by Atlassian JIRA
(v6.2#6252)


Re: svn commit: r1594758 - /ofbiz/trunk/.gitignore

2014-05-18 Thread Hans Bakker
With a proper installation, hot-deploy components will come from a 
different git repository and should not be stored together in order to 
be able to keep your ofbiz installation in sync with the ofbiz svn 
repository.


If they are not ignored, and you install ofbiz and later the components 
in hot-deploy, then do a 'git clean' your components are deleted


That is why it should be ignored by the OFBiz installation.

But as usual Jacques, up to you , however it shows you are not using git 
at all.


Regards, Hans




On 18/05/14 17:58, Jacques Le Roux wrote:

-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt


This change does not make sense. It will force people who use Git to 
search why their added component/s are ignored, I will revert it!


I add 2 other changes I have pending for months:

runtime/indexes/products/

So I agree with this one

What about adding?

framework/entity/lib/jdbc

I was reluctant because it might hide downloaded, JDBC drivers, not 
sure... opinions?


Jacques

Le 15/05/2014 04:24, hans...@apache.org a écrit :

Author: hansbak
Date: Thu May 15 02:24:27 2014
New Revision: 1594758

URL: http://svn.apache.org/r1594758
Log:
update git ignore for product indexes and components in hot-deploy

Modified:
 ofbiz/trunk/.gitignore

Modified: ofbiz/trunk/.gitignore
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.gitignore?rev=1594758r1=1594757r2=1594758view=diff
== 


--- ofbiz/trunk/.gitignore (original)
+++ ofbiz/trunk/.gitignore Thu May 15 02:24:27 2014
@@ -4,7 +4,8 @@ framework/base/lib/cobertura-*.jar
  framework/base/lib/asm*.jar
  framework/base/lib/oro*.jar
  framework/entity/lib/jdbc/postgresql-*.jar
-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt
  specialpurpose/*/build
  applications/content/index/
  bin/
@@ -25,6 +26,7 @@ runtime/data/utilcache.*
  runtime/catalina/work/*
  runtime/jetty
  runtime/tempfiles/*
+runtime/indexes/products/
  themes/flatgrey/webapp/flatgrey/javascript-min.css
  themes/flatgrey/webapp/flatgrey/js/application-min.js
  themes/flatgrey/webapp/flatgrey/maincss-min.css









Re: svn commit: r1594758 - /ofbiz/trunk/.gitignore

2014-05-18 Thread Adam Heath

I'm the one who originally added this file.  Hans, you're wrong.

Not everyone does git integration work the same way.  Some might use 
symlinks in hot-deploy, linked to locations outside of the ofbiz tree.  
In those cases, the symlinks should be maintained in the parent repo.


Other methods might make use of git modules; excluding * is most 
definitely wrong.


If you want to ignore stuff in your own hot-deploy, add the ignore 
locally, or create a new hot-deploy/.gitignore.


ps: I seem to not be able to commit, maybe my password is wrong. I'll 
have to fix that.


On 05/18/2014 08:38 PM, Hans Bakker wrote:
With a proper installation, hot-deploy components will come from a 
different git repository and should not be stored together in order to 
be able to keep your ofbiz installation in sync with the ofbiz svn 
repository.


If they are not ignored, and you install ofbiz and later the 
components in hot-deploy, then do a 'git clean' your components are 
deleted


That is why it should be ignored by the OFBiz installation.

But as usual Jacques, up to you , however it shows you are not using 
git at all.


Regards, Hans




On 18/05/14 17:58, Jacques Le Roux wrote:

-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt


This change does not make sense. It will force people who use Git to 
search why their added component/s are ignored, I will revert it!


I add 2 other changes I have pending for months:

runtime/indexes/products/

So I agree with this one

What about adding?

framework/entity/lib/jdbc

I was reluctant because it might hide downloaded, JDBC drivers, not 
sure... opinions?


Jacques

Le 15/05/2014 04:24, hans...@apache.org a écrit :

Author: hansbak
Date: Thu May 15 02:24:27 2014
New Revision: 1594758

URL: http://svn.apache.org/r1594758
Log:
update git ignore for product indexes and components in hot-deploy

Modified:
 ofbiz/trunk/.gitignore

Modified: ofbiz/trunk/.gitignore
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.gitignore?rev=1594758r1=1594757r2=1594758view=diff
== 


--- ofbiz/trunk/.gitignore (original)
+++ ofbiz/trunk/.gitignore Thu May 15 02:24:27 2014
@@ -4,7 +4,8 @@ framework/base/lib/cobertura-*.jar
  framework/base/lib/asm*.jar
  framework/base/lib/oro*.jar
  framework/entity/lib/jdbc/postgresql-*.jar
-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt
  specialpurpose/*/build
  applications/content/index/
  bin/
@@ -25,6 +26,7 @@ runtime/data/utilcache.*
  runtime/catalina/work/*
  runtime/jetty
  runtime/tempfiles/*
+runtime/indexes/products/
  themes/flatgrey/webapp/flatgrey/javascript-min.css
  themes/flatgrey/webapp/flatgrey/js/application-min.js
  themes/flatgrey/webapp/flatgrey/maincss-min.css











Re: svn commit: r1594758 - /ofbiz/trunk/.gitignore

2014-05-18 Thread Hans Bakker

Adam,

i looked at sub modules and git-tree, they are adding even more 
complexity to the already complex GIT and sorry i do not see the advantage.
Loading the components into hot-deploy from a separate git repository is 
working well here, however one need to ignore the hot-deploy content  
otherwise git will block you creating a new branch and 'clean' will 
otherwise delete them.


ok, when there is no support for this will do it locally which is now 
much easier with Git anyway.


Regards, Hans

On 19/05/14 09:43, Adam Heath wrote:

I'm the one who originally added this file.  Hans, you're wrong.

Not everyone does git integration work the same way.  Some might use 
symlinks in hot-deploy, linked to locations outside of the ofbiz 
tree.  In those cases, the symlinks should be maintained in the parent 
repo.


Other methods might make use of git modules; excluding * is most 
definitely wrong.


If you want to ignore stuff in your own hot-deploy, add the ignore 
locally, or create a new hot-deploy/.gitignore.


ps: I seem to not be able to commit, maybe my password is wrong. I'll 
have to fix that.


On 05/18/2014 08:38 PM, Hans Bakker wrote:
With a proper installation, hot-deploy components will come from a 
different git repository and should not be stored together in order 
to be able to keep your ofbiz installation in sync with the ofbiz svn 
repository.


If they are not ignored, and you install ofbiz and later the 
components in hot-deploy, then do a 'git clean' your components are 
deleted


That is why it should be ignored by the OFBiz installation.

But as usual Jacques, up to you , however it shows you are not using 
git at all.


Regards, Hans




On 18/05/14 17:58, Jacques Le Roux wrote:

-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt


This change does not make sense. It will force people who use Git to 
search why their added component/s are ignored, I will revert it!


I add 2 other changes I have pending for months:

runtime/indexes/products/

So I agree with this one

What about adding?

framework/entity/lib/jdbc

I was reluctant because it might hide downloaded, JDBC drivers, not 
sure... opinions?


Jacques

Le 15/05/2014 04:24, hans...@apache.org a écrit :

Author: hansbak
Date: Thu May 15 02:24:27 2014
New Revision: 1594758

URL: http://svn.apache.org/r1594758
Log:
update git ignore for product indexes and components in hot-deploy

Modified:
 ofbiz/trunk/.gitignore

Modified: ofbiz/trunk/.gitignore
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.gitignore?rev=1594758r1=1594757r2=1594758view=diff
== 


--- ofbiz/trunk/.gitignore (original)
+++ ofbiz/trunk/.gitignore Thu May 15 02:24:27 2014
@@ -4,7 +4,8 @@ framework/base/lib/cobertura-*.jar
  framework/base/lib/asm*.jar
  framework/base/lib/oro*.jar
  framework/entity/lib/jdbc/postgresql-*.jar
-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt
  specialpurpose/*/build
  applications/content/index/
  bin/
@@ -25,6 +26,7 @@ runtime/data/utilcache.*
  runtime/catalina/work/*
  runtime/jetty
  runtime/tempfiles/*
+runtime/indexes/products/
  themes/flatgrey/webapp/flatgrey/javascript-min.css
  themes/flatgrey/webapp/flatgrey/js/application-min.js
  themes/flatgrey/webapp/flatgrey/maincss-min.css













buildbot failure in ASF Buildbot on ofbiz-trunk

2014-05-18 Thread buildbot
The Buildbot has detected a new failure on builder ofbiz-trunk while building 
ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/ofbiz-trunk/builds/15

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: portunus_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch ofbiz/trunk] 1595732
Blamelist: hansbak

BUILD FAILED: failed compile_1

sincerely,
 -The Buildbot





Re: svn commit: r1594758 - /ofbiz/trunk/.gitignore

2014-05-18 Thread Adam Heath
Just because you don't see the need, doesn't mean it it should be 
actively discourage.  Adding that wildcard commit to trunk will 
discourage these other tools.


On 05/18/2014 10:10 PM, Hans Bakker wrote:

Adam,

i looked at sub modules and git-tree, they are adding even more 
complexity to the already complex GIT and sorry i do not see the 
advantage.
Loading the components into hot-deploy from a separate git repository 
is working well here, however one need to ignore the hot-deploy 
content  otherwise git will block you creating a new branch and 
'clean' will otherwise delete them.


ok, when there is no support for this will do it locally which is now 
much easier with Git anyway.


Regards, Hans

On 19/05/14 09:43, Adam Heath wrote:

I'm the one who originally added this file.  Hans, you're wrong.

Not everyone does git integration work the same way.  Some might use 
symlinks in hot-deploy, linked to locations outside of the ofbiz 
tree.  In those cases, the symlinks should be maintained in the 
parent repo.


Other methods might make use of git modules; excluding * is most 
definitely wrong.


If you want to ignore stuff in your own hot-deploy, add the ignore 
locally, or create a new hot-deploy/.gitignore.


ps: I seem to not be able to commit, maybe my password is wrong. I'll 
have to fix that.


On 05/18/2014 08:38 PM, Hans Bakker wrote:
With a proper installation, hot-deploy components will come from a 
different git repository and should not be stored together in order 
to be able to keep your ofbiz installation in sync with the ofbiz 
svn repository.


If they are not ignored, and you install ofbiz and later the 
components in hot-deploy, then do a 'git clean' your components are 
deleted


That is why it should be ignored by the OFBiz installation.

But as usual Jacques, up to you , however it shows you are not using 
git at all.


Regards, Hans




On 18/05/14 17:58, Jacques Le Roux wrote:

-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt


This change does not make sense. It will force people who use Git 
to search why their added component/s are ignored, I will revert it!


I add 2 other changes I have pending for months:

runtime/indexes/products/

So I agree with this one

What about adding?

framework/entity/lib/jdbc

I was reluctant because it might hide downloaded, JDBC drivers, not 
sure... opinions?


Jacques

Le 15/05/2014 04:24, hans...@apache.org a écrit :

Author: hansbak
Date: Thu May 15 02:24:27 2014
New Revision: 1594758

URL: http://svn.apache.org/r1594758
Log:
update git ignore for product indexes and components in hot-deploy

Modified:
 ofbiz/trunk/.gitignore

Modified: ofbiz/trunk/.gitignore
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/.gitignore?rev=1594758r1=1594757r2=1594758view=diff
== 


--- ofbiz/trunk/.gitignore (original)
+++ ofbiz/trunk/.gitignore Thu May 15 02:24:27 2014
@@ -4,7 +4,8 @@ framework/base/lib/cobertura-*.jar
  framework/base/lib/asm*.jar
  framework/base/lib/oro*.jar
  framework/entity/lib/jdbc/postgresql-*.jar
-hot-deploy/*/build
+hot-deploy/*
+!hot-deploy/README.txt
  specialpurpose/*/build
  applications/content/index/
  bin/
@@ -25,6 +26,7 @@ runtime/data/utilcache.*
  runtime/catalina/work/*
  runtime/jetty
  runtime/tempfiles/*
+runtime/indexes/products/
  themes/flatgrey/webapp/flatgrey/javascript-min.css
  themes/flatgrey/webapp/flatgrey/js/application-min.js
  themes/flatgrey/webapp/flatgrey/maincss-min.css