Re: Apache POI 3.15 released

+1 always to update to stable new releases On Thu, Sep 22, 2016 at 2:22 AM, Michael Brohl wrote: > Hi everyone, > > Apache POI 3.15 is released, we are currently using 3.14. > > Should we do an update? > > I'd create a Jira and do this work. > > What do you think? > >

Re: [ANNOUNCE] Apache Solr 6.2.1 released

I think an update is _always_ a welcomed thing not only for feature set but also security and bug fixes. So always +1 to upgrade to new versions of anything. However, I have to say Solr and Birt are two massive components in terms of dependencies. So while upgrading and fixing compilation errors

Re: Apache POI 3.15 released

Hi everyone, Apache POI 3.15 is released, we are currently using 3.14. Should we do an update? I'd create a Jira and do this work. What do you think? Regards, Michael Am 22.09.16 um 00:32 schrieb David North: The Apache POI PMC are pleased to announce the release of Apache POI 3.15. For

Re: [ANNOUNCE] Apache Solr 6.2.1 released

Hi everyone, there's an new Solr/Lucene version released. Should we do an update? It will need some refactoring, there are a few compile errors to be solved. I'd create a Jira and do this work if we want to update, what do you think? Regards, Michael Am 20.09.16 um 22:26 schrieb Shalin

Re: Preliminary question about themes before possible votes

Hi Julien, We spoke about having themes like plugins, but I think it was just a small talk so far In 1st place they should go in attic (ie stay in OFBiz trunk in svn repo ) and then possibly resurrected from there as themes-plugins, or not. Jacques Le 21/09/2016 à 22:59, Julien NICOLAS a

Re: Preliminary question about themes before possible votes

Hi Jacques, I agree that it's important to remove themes from the framework (keep at least one is important ^^ ). But you don't mention what's happening with theme that is not in the OOTB. I think it could be available from public repository instead of simply deleted. For me pors is to

Re: Put "Reverts" in the commit template?

I have changed it to "Reverted" for consistency reasons. Jacopo On Wed, Sep 21, 2016 at 7:01 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Done > > Jacques > > > Le 18/09/2016 à 11:19, Jacques Le Roux a écrit : > >> Hi, >> >> In some cases we need to revert a commit done for a

Re: Put "Reverts" in the commit template?

Done Jacques Le 18/09/2016 à 11:19, Jacques Le Roux a écrit : Hi, In some cases we need to revert a commit done for a Jira after we discover it causes an issue. We have not yet other means that using the fix word. I suggest we put in the "Reverts" (or "Revert for" or "Reverted" as it please

Re: Use ecomseo on demo rather than ecommerce

After 3 day, I consider this a lazy consensus since nobody chimed in and will change accordingly tomorrow Jacques Le 18/09/2016 à 15:27, Jacques Le Roux a écrit : Hi, Maybe you don't know about or did not try it, but we have ecomseo a clone of the ecommerce component tailored for SEO

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Nice that you're trying to keep this alive, Jacques. But there is basically nothing to discuss as it is a done deal. Best regards, Pierre Smits ORRTIZ.COM OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Sep 21, 2016

Re: Preliminary question about themes before possible votes

Ah something I missed to precise: it's not about giving arguments, pro or cons. It's only about taking decisions, so again: please stay focused. Thanks Jacques Le 21/09/2016 à 18:13, Jacques Le Roux a écrit : Hi All, At OFBIZ-8293 we began to informally discuss about reducing the number of

Preliminary question about themes before possible votes

Hi All, At OFBIZ-8293 we began to informally discuss about reducing the number of OOTB themes. But we could clearly agree and believe a vote is better/ 1. Now the 1st question which has been already discussed several time without a clear decision in this ML: do we, as a community, want to

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

I'm not against reverting myself. Doing so it also means that everybody agree about continuing to use the FormFieldTitle_ feature So if you really don't like it and have arguments, it's the moment to raise your hand. Before I revert in, say 2 days, and put this discussion back in the limbo

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Jacques, please take care of the revert, this will keep the commit history cleaner. Thanks, Michael Am 21.09.16 um 14:04 schrieb Jacques Le Roux: I'm not against reverting it, it's a moot point to me. Please help yourselves (Michael or Taher. Or maybe Christian? :D) Jacques Le

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

I'm not against reverting it, it's a moot point to me. Please help yourselves (Michael or Taher. Or maybe Christian? :D) Jacques Le 21/09/2016 à 11:11, Taher Alkhateeb a écrit : I suggest also to revert. If we want to apply such a change in the future then we must take a decision to stop

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

I don't think the performance argument is solid here But the FormFieldTitle_ thing is questionnable, yes. Even if I must say I missed this point when I committed this in my haste to close OFBIZ-8110. I'm actually slightly for FormFieldTitle_s, though it's maybe blurring things a bit, really a

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

This is a moot point, ask Christian :) Jacques Le 21/09/2016 à 09:47, gil portenseigne a écrit : Hi Jacques, Like Nicolas said in previous Michael commit answer: http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332 I do not understand these kindof improvements. Adding a title when and

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

So what is the point you're trying to make? Pierre Smits ORRTIZ.COM OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/ On Wed, Sep 21, 2016 at 12:18 PM, gil portenseigne < gil.portensei...@nereide.fr> wrote: > Yes i did express

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Yes idid express myself bad :), it was not a point i wanted to insist on. Sorry for the distraction. Le 21/09/2016 à 12:16, Pierre Smits a écrit : No it doesn't. In fact it is completely off. Because the inclusion of the component name (MyComponent, in your reference) is nowhere required.

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

No it doesn't. In fact it is completely off. Because the inclusion of the component name (MyComponent, in your reference) is nowhere required. Unless I am misunderstanding you. Best regards, Pierre Smits ORRTIZ.COM OFBiz based solutions & services OFBiz Extensions

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

In the commit for instance : title="${uiLabelMap.CommonDescription}" the MyComponent/Common explain both possible cases... Le 21/09/2016 à 11:52, Pierre Smits a écrit : HI Gil, Where do you see "uiLabelMap.MyComponent/CommonX" in widgets and templates? Nowhere, as far as I can tell. But

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

HI Gil, Where do you see "uiLabelMap.MyComponent/CommonX" in widgets and templates? Nowhere, as far as I can tell. But in each (most?) component you'll find {code} {code} And for what it is worth: a product in manufacturing, accounting, party, workeffort or any other component referencing a

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

I suggest also to revert. If we want to apply such a change in the future then we must take a decision to stop using convention-over-configuration for _all_ widget fields. And if we do not want to use that convention then we should remove the related code accordingly. On Wed, Sep 21, 2016 at

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Hi Gil, Am 21.09.16 um 11:25 schrieb gil portenseigne: Labels for products or others object could be different in each component, thus i don't like replacing all with CommonXXX I agree, this would be an unwanted regression. Regards, Michael smime.p7s Description: S/MIME Cryptographic

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Hi Pierre, I do not agree that FormFieldTitle_XXX is *only* for lazy programmer (and i remember a teacher that used to tell that to be good, you have to be smartly lazy :) ). The fact that this label contains default translation for XXX fields allow speed developpmentand is far more

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

I'd suggest to revert this commit. Thanks, Michael Am 21.09.16 um 09:47 schrieb gil portenseigne: Hi Jacques, Like Nicolas said in previous Michael commit answer: http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332 I do not understand these kindof improvements. Adding a title when

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

FormFieldTitle_XXX is for lazy programmers, only considering the OFBiz Demo implementation as the only adopter of the product. Who use {code}{code} as their means to display entity elements (fields) in forms. Unfortunately that doesn't work for all. Furthermore, like I said in

Re: svn commit: r1761687 - /ofbiz/trunk/specialpurpose/myportal/widget/PortalAdmForms.xml

Hi Jacques, Like Nicolas said in previous Michael commit answer: http://markmail.org/message/x4ulworuwgbotvrv?q=r1761332 I do not understand these kindof improvements. Adding a title when and FormFieldTitle_XXX properties exists is not good in my opinion (i did not check these ones).

Re: Limit the length of comments commits lines

OK, found it at https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html It's somehow tsvn:logwidthmarker. I say somehow because the limit marker is fine but the split is really not helping much. You still have to do it by hand to be realistic, at least you see where to