[OFBIZ-10147] Buildbot script refactoring to put in a R17 branch build

[Jacques Le Roux]

Hi,

I created OFBIZ-10147 for that, so bear with me if we encounter some quirks 
with Buildbot in the next days...

Jacques

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Jacopo Cappellato]

Thank you, both changes are implemented in rev. 1820297

Jacopo

On Fri, Jan 5, 2018 at 11:18 AM, Michael Brohl 
wrote:

> +1
>
> I think we should also change the headline "Apache OFBiz 13.07 and
> earlier" to "Earlier Releases" or similar, so that we do not have to
> maintain this section when the releases change.
>
> Regards,
>
> Michael
>
>
> Am 05.01.18 um 11:02 schrieb Jacopo Cappellato:
>
> Hi all,
>>
>> I think we should now remove the section titled "Special Notice Regarding
>> Branches 14.12 and 15.12" from the OFBiz download page:
>>
>> https://ofbiz.apache.org/download.html
>>
>> The page should only list the most recent release from each actively
>> maintained branch; the section has been useful while we were migrating our
>> scripts but I think that now only adds confusion.
>>
>> Any objections?
>>
>> Jacopo
>>
>>
>
>

Minilang to Groovy: login-required tag questions

[Dennis Balkir]

Hi Devs,

at the moment I am doing some Minilang to Groovy conversions (CategoryServices 
to be precise) and I found a simple method (getAssociatedProductsList), which 
set the tag „login-required“ to false.
I then checked the service-definition of this method (which it had), and there 
it also sets the „auth“ tag to false.
I tried to find, where these tags get checked in the Engine-Codes, specifically 
the serviceengine.xml, SimpleServiceEngine.java, ServiceEngine.java and 
SimpleMethod.java, but I cannot find for sure, where the authentication gets 
checked.

The question for me is now: Is it necessary for the simple method to have the 
„login-required“ tag set to false, if the service definition set "auth" to 
false already?
Where does this get checked and when?
And of course: When the set of the „login-required“ tag in the simple-method is 
necessary, as well as the set „auth“ tag, how do I implement the 
„login-required=false“ in Groovy?

Thanks in advance for your help

Kind regards
-- 
Dennis Balkir
Trainee

Fon +49 521 448 157-90
Fax +49 521 448 157-99

Company and Management Headquarters:
ecomify GmbH, Gustav-Winkler-Str. 22, 33699 Bielefeld, Deutschland
Fon: +49 521 448157-90, Fax: +49 521 448157-99, www.ecomify.de

Court Registration: Amtsgericht Bielefeld HRB 41683
Chief Executive Officer: Martin Becker, Michael Brohl

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Ratnesh Upadhyay]

+1

Regards,
Ratnesh Upadhyay
HotWax Systems | www.hotwaxsystems.com

On Fri, Jan 5, 2018 at 3:32 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Hi all,
>
> I think we should now remove the section titled "Special Notice Regarding
> Branches 14.12 and 15.12" from the OFBiz download page:
>
> https://ofbiz.apache.org/download.html
>
> The page should only list the most recent release from each actively
> maintained branch; the section has been useful while we were migrating our
> scripts but I think that now only adds confusion.
>
> Any objections?
>
> Jacopo
>

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Ashish Vijaywargiya]

+1

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997 


On Fri, Jan 5, 2018 at 3:32 PM, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:

> Hi all,
>
> I think we should now remove the section titled "Special Notice Regarding
> Branches 14.12 and 15.12" from the OFBiz download page:
>
> https://ofbiz.apache.org/download.html
>
> The page should only list the most recent release from each actively
> maintained branch; the section has been useful while we were migrating our
> scripts but I think that now only adds confusion.
>
> Any objections?
>
> Jacopo
>

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Deepak Dixit]

+1

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
www.hotwax.co

On Fri, Jan 5, 2018 at 4:21 PM, Sharan Foga  wrote:

> +1
>
> Thanks
> Sharan
>
>
> On 05/01/18 11:43, Taher Alkhateeb wrote:
>
>> +1
>>
>> On Jan 5, 2018 1:34 PM, "Jacques Le Roux" 
>> wrote:
>>
>> +1 for both
>>
>> Jacques
>>
>>
>>
>> Le 05/01/2018 à 11:18, Michael Brohl a écrit :
>>
>> +1
>>>
>>> I think we should also change the headline "Apache OFBiz 13.07 and
>>> earlier" to "Earlier Releases" or similar, so that we do not have to
>>> maintain this section when the releases change.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 05.01.18 um 11:02 schrieb Jacopo Cappellato:
>>>
>>> Hi all,

 I think we should now remove the section titled "Special Notice
 Regarding
 Branches 14.12 and 15.12" from the OFBiz download page:

 https://ofbiz.apache.org/download.html

 The page should only list the most recent release from each actively
 maintained branch; the section has been useful while we were migrating
 our
 scripts but I think that now only adds confusion.

 Any objections?

 Jacopo



>>>
>

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Sharan Foga]

+1

Thanks
Sharan

On 05/01/18 11:43, Taher Alkhateeb wrote:

+1

On Jan 5, 2018 1:34 PM, "Jacques Le Roux" 
wrote:

+1 for both

Jacques



Le 05/01/2018 à 11:18, Michael Brohl a écrit :


+1

I think we should also change the headline "Apache OFBiz 13.07 and
earlier" to "Earlier Releases" or similar, so that we do not have to
maintain this section when the releases change.

Regards,

Michael


Am 05.01.18 um 11:02 schrieb Jacopo Cappellato:


Hi all,

I think we should now remove the section titled "Special Notice Regarding
Branches 14.12 and 15.12" from the OFBiz download page:

https://ofbiz.apache.org/download.html

The page should only list the most recent release from each actively
maintained branch; the section has been useful while we were migrating our
scripts but I think that now only adds confusion.

Any objections?

Jacopo

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Taher Alkhateeb]

+1

On Jan 5, 2018 1:34 PM, "Jacques Le Roux" 
wrote:

+1 for both

Jacques



Le 05/01/2018 à 11:18, Michael Brohl a écrit :

> +1
>
> I think we should also change the headline "Apache OFBiz 13.07 and
> earlier" to "Earlier Releases" or similar, so that we do not have to
> maintain this section when the releases change.
>
> Regards,
>
> Michael
>
>
> Am 05.01.18 um 11:02 schrieb Jacopo Cappellato:
>
>> Hi all,
>>
>> I think we should now remove the section titled "Special Notice Regarding
>> Branches 14.12 and 15.12" from the OFBiz download page:
>>
>> https://ofbiz.apache.org/download.html
>>
>> The page should only list the most recent release from each actively
>> maintained branch; the section has been useful while we were migrating our
>> scripts but I think that now only adds confusion.
>>
>> Any objections?
>>
>> Jacopo
>>
>>
>
>

Re: Variables created from properties should not be final

[Jacques Le Roux]

Le 05/01/2018 à 10:03, Jacopo Cappellato a écrit :

On Fri, Jan 5, 2018 at 9:26 AM, Michael Brohl 
wrote:


[...]

So,

-1 for applying this as a general rule,
+1 for a thorough review of the 53 cases and changes where they make sense.


I agree with the reasoning and conclusions above; to them I would add my:
+1 for a thorough review of the 3461 other cases to see if among them there
are variables that should be declared final

Jacopo


Good point Jacopo, but a large task ;)

Jacques

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Jacques Le Roux]

+1 for both

Jacques


Le 05/01/2018 à 11:18, Michael Brohl a écrit :

+1

I think we should also change the headline "Apache OFBiz 13.07 and earlier" to "Earlier Releases" or similar, so that we do not have to maintain 
this section when the releases change.


Regards,

Michael


Am 05.01.18 um 11:02 schrieb Jacopo Cappellato:

Hi all,

I think we should now remove the section titled "Special Notice Regarding
Branches 14.12 and 15.12" from the OFBiz download page:

https://ofbiz.apache.org/download.html

The page should only list the most recent release from each actively
maintained branch; the section has been useful while we were migrating our
scripts but I think that now only adds confusion.

Any objections?

Jacopo

Re: Proposal to remove the "Special Notice" section from the OFBiz download page

[Michael Brohl]

+1

I think we should also change the headline "Apache OFBiz 13.07 and 
earlier" to "Earlier Releases" or similar, so that we do not have to 
maintain this section when the releases change.


Regards,

Michael


Am 05.01.18 um 11:02 schrieb Jacopo Cappellato:

Hi all,

I think we should now remove the section titled "Special Notice Regarding
Branches 14.12 and 15.12" from the OFBiz download page:

https://ofbiz.apache.org/download.html

The page should only list the most recent release from each actively
maintained branch; the section has been useful while we were migrating our
scripts but I think that now only adds confusion.

Any objections?

Jacopo






smime.p7s
Description: S/MIME Cryptographic Signature

Proposal to remove the "Special Notice" section from the OFBiz download page

[Jacopo Cappellato]

Hi all,

I think we should now remove the section titled "Special Notice Regarding
Branches 14.12 and 15.12" from the OFBiz download page:

https://ofbiz.apache.org/download.html

The page should only list the most recent release from each actively
maintained branch; the section has been useful while we were migrating our
scripts but I think that now only adds confusion.

Any objections?

Jacopo

Re: Variables created from properties should not be final

[Jacques Le Roux]

Le 05/01/2018 à 09:26, Michael Brohl a écrit :

Hi Jacques,

inline..

Am 05.01.18 um 08:31 schrieb Jacques Le Roux:

Hi,

We have roughly 3514 variables created from properties, either from properties 
files or from DB values.

Among them 53 are declared final, this does not make sense to me.

It might make sense depending on the business logic...

Agreed, see my answer to Taher



Because a variable which depends on a properties is cached and can be 
dynamically changed.

You simply change the value in the properties file and clear the cache in 
webtools (either all caches or only the properties cache).

So it's not a constant. We also  use EntityUtilProperties, but same can happen 
with DB values, just change it and clear cache.


From the class view, this is wrong. If you declare a constant as a class variable from property files (e.g. as a final class attribute) the property 
is only read once and assigned to the final variable. You can change the variable in the properties or on the db and clear the cache, it will have 
no impact for the instantiated class.


If you want to freshly read the property value every time you need it and you want the possibility to change it dynamically at runtime, you'll have 
to read it in the respective code and cannot declare it once as a class attribute.


Because of that, IMO those variables should never be final, it's contradictory.

What do you think?


I think that you cannot apply this as a general rule because it depends on how you want to use the property/variable. Taher has given a good example 
with the start component and there will be others.

Yes sure


So,

-1 for applying this as a general rule,
+1 for a thorough review of the 53 cases and changes where they make sense.

Exactly what I intended to do. Jacopo suggests to review all case but then it's 
really a large task!

Jacques


Thanks,
Michael



Jacques

Re: Variables created from properties should not be final

[Jacques Le Roux]

Le 05/01/2018 à 08:45, Taher Alkhateeb a écrit :

-1

This is a perfect example of why mass-updates following a certain pattern
are a bad idea.

I did not say that all should be done. Of course every case should be checked.


The properties files in the start component define critical startup
parameters that cannot be changed without critically corrupting or even
crashing the system.

That's a good example where it should not be done


Therefore, I believe you should study each variable separately before
deciding if you are going to change it.

That was exactly my thoughts, I should have said it therefore. I have already 
quickly reviewed and in most cases they should be changed

Jacques



On Jan 5, 2018 10:31 AM, "Jacques Le Roux" 
wrote:

Hi,

We have roughly 3514 variables created from properties, either from
properties files or from DB values.

Among them 53 are declared final, this does not make sense to me.

Because a variable which depends on a properties is cached and can be
dynamically changed.

You simply change the value in the properties file and clear the cache in
webtools (either all caches or only the properties cache).

So it's not a constant. We also  use EntityUtilProperties, but same can
happen with DB values, just change it and clear cache.

Because of that, IMO those variables should never be final, it's
contradictory.

What do you think?

Jacques

Re: Variables created from properties should not be final

[Jacopo Cappellato]

On Fri, Jan 5, 2018 at 9:26 AM, Michael Brohl 
wrote:

> [...]

So,
>
> -1 for applying this as a general rule,
> +1 for a thorough review of the 53 cases and changes where they make sense.
>

I agree with the reasoning and conclusions above; to them I would add my:
+1 for a thorough review of the 3461 other cases to see if among them there
are variables that should be declared final

Jacopo

Re: Variables created from properties should not be final

[Michael Brohl]

Hi Jacques,

inline..

Am 05.01.18 um 08:31 schrieb Jacques Le Roux:

Hi,

We have roughly 3514 variables created from properties, either from 
properties files or from DB values.


Among them 53 are declared final, this does not make sense to me.

It might make sense depending on the business logic...


Because a variable which depends on a properties is cached and can be 
dynamically changed.


You simply change the value in the properties file and clear the cache 
in webtools (either all caches or only the properties cache).


So it's not a constant. We also  use EntityUtilProperties, but same 
can happen with DB values, just change it and clear cache.


From the class view, this is wrong. If you declare a constant as a 
class variable from property files (e.g. as a final class attribute) the 
property is only read once and assigned to the final variable. You can 
change the variable in the properties or on the db and clear the cache, 
it will have no impact for the instantiated class.


If you want to freshly read the property value every time you need it 
and you want the possibility to change it dynamically at runtime, you'll 
have to read it in the respective code and cannot declare it once as a 
class attribute.


Because of that, IMO those variables should never be final, it's 
contradictory.


What do you think?


I think that you cannot apply this as a general rule because it depends 
on how you want to use the property/variable. Taher has given a good 
example with the start component and there will be others.


So,

-1 for applying this as a general rule,
+1 for a thorough review of the 53 cases and changes where they make sense.

Thanks,
Michael



Jacques






smime.p7s
Description: S/MIME Cryptographic Signature