Re: OFBiz Version Info

[Michael Brohl]

-1 for storing the version in .properties.

+1 for using a VERSION or RELEASE file in the root folder to store this 
information.


It's easily accessible, you cannot overlook it and the content can be 
read by any functionality. It can also be automatically set by (custom) 
builds to be generated.


I think it might be a good idea to just render the version in the 
applications header or footer template as a HTML comment. Then it is 
viewable by anyone even if there is no access to the source. This should 
be made configurable in general.properties to prevent to show it if the 
user does not want this.


Thanks and regards,

Michael


Am 29.11.17 um 07:38 schrieb Taher Alkhateeb:

Hi James,

The purpose of Config.java is to configure critical server settings at
startup such as log location, admin settings, etc. These settings could be
also used in test.properties and load-data.properties and all such
properties get a default value if not set.

OFBiz version by definition is not a startup parameter. It is not something
you need to set so that the system works correctly. It's only a piece of
information. That is why I suggested that it might not be a good fit for
start.properties and Config.java. It's also hard for users to find the
version if it is hidden somewhere like that. And given the nature of
verbose logging in OFBiz I suspect that it might not be very useful to spit
out OFBiz version in the logs because it will be lost in the mix.

So if I may suggest maybe there are a few alternatives that could work like:
- adding it to another properties file like general.properties (although
still a bit hidden yet more related than start.properties)
- adding it to the UiLabelMap and putting it in the footer of the system
- putting it in a VERSION file or README.md as originally suggested

I'm sure you can also come up with good ideas to that end, I'm just
thinking quickly of alternatives that might fit.

On Nov 29, 2017 2:30 AM, "James Yong"  wrote:

Hi Taher,

The reason of putting released version (e.g. 16.11.03) in start.properties
file is because the start program is already reading that file and that
info will be included in the startup message. Printing released version to
the console is in line with what other applications, like Tomcat, have been
doing.

I haven't check how the start program will read the VERSION file but I have
no issue with this approach and we can further discuss how it can be done.

Regards,
James Yong

On 2017-11-29 02:51, Taher Alkhateeb  wrote:

Hi James,

I'm not sure of the purpose of doing all of that? start.properties is
a file to feed into Config.java which in turn configures the startup
settings of OFBiz. The version has nothing with the startup code so it
seems like an improper place to put the property and maybe it might
confuse users.

Also, why go through all this logic? why not simply create a VERSION
file and place the version in it? Much simpler and easier if all you
need is a version reference. Unless you want to introduce some logic?

On Tue, Nov 28, 2017 at 6:04 PM, James Yong  wrote:

Hi all,

If there is no further discusson, I will create a JIRA issue later to
1) add an ofbiz.version key in start.properties file; and
2) have the ofbiz.version key value included in the startup message.

Regards,
James Yong

On 2017-11-28 01:35, Jacques Le Roux 

wrote:

OK then if we have both, why not?

Jacques


Le 27/11/2017 à 17:15, James Yong a écrit :

Hi Jacques,

The developer can refer to the proposed ofbiz.version property if

needed.

Regards,
James Yong

On 2017-11-28 00:03, Jacques Le Roux 

wrote:

Hi James,

That's good when you start but could be hard to find after many

days running in production for instance

Jacques


Le 27/11/2017 à 15:43, James Yong a écrit :

Hi all,

How about hardcoding the released version in start.properties?
E.g.
ofbiz.version=v16.11.03

During startup, we can print out the version as part of the

startup message like:

    __  _
 / __ \/ / __ )(_)___
/ / / / /_  / __  / /_  /
/ /_/ / __/ / /_/ / / / /_
\/_/   /_/_/ /___/  v16.11.03 is started and ready.

Just update the released version in the properties before a

release.

Regards,
James Yong


On 2017-11-27 22:08, Akash Jain 

wrote:

+1, version information should available somewhere, it will be

helpful.

Thanks and Regards
--
Akash Jain

On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga 

wrote:

Hi

Having the version info available somehow could be useful.

Whenever a user

reports a problem on our user lists, one of the first questions

we ask them

is "What version are you using?"

Perhaps asking the question about version information, on the

user list

might help.

Thanks
Sharan

On 2017-11-27 08:49, Pierre Smits  wrote:

Hi Devanshu Vyas,

Please see inline.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OEM - The OFBiz Extensions Marketplace1
http://oem.ofbizci.net/oci-2/
1 not affiliate

Re: Fwd: ISO Notifications

[Jacques Le Roux]

Hi devs,

For the moment, using my "Online Browsing Platform (OBP)" personal information, I have subscribed this ML, to ISO notifications and created 
https://issues.apache.org/jira/browse/OFBIZ-10028


I think we should rather subscribe the dev ML on behalf of the OFBiz PMC

What do you think?

Jacques




Hi Michael,

Yes, that's why I think that rather than have myself subscribed and report here it would be easier to susbcribe the dev ML and let decide the team 
if a Jira issue is needed.


I'd say that for instance this time France is not concerned and I let people 
concerned handle it :)

It happens once a year or less so will not be a burden.

If nobody profoundly disagree I'll do so

Thanks

Jacques


Le 24/11/2017 à 18:39, Michael Brohl a écrit :

Hi Jacques,

I think it is enough to report that there are changes from time to time or file 
an issue for it.

If someone is interested in getting these notifications, he may subscribe 
himself to this newsletter.

Thanks and regards,

Michael


Am 24.11.17 um 15:29 schrieb Jacques Le Roux:

Hi,

If someone is interested, the China changes are a bit to heavy for me at the 
moment...

BTW, maybe we could subscribe this ML to these ISO notifications. What do you 
think?

Thanks

Jacques



 Message transféré 
Sujet : ISO Notifications
Date : Fri, 24 Nov 2017 02:02:13 +0100 (CET)
De : ISO Customer Service 
Répondre à : ISO Customer Service 
Pour : jacques.le.r...@les7arts.com



ISO Notification

Notification
International Organization for Standardization



/Dear Subscriber,/

Here are the latest changes to the ISO items that you are following.

If you need more information we’d be happy to help! Please contact the ISO Member in your country 
 or the ISO Customer Service team .


To manage your notification settings including the list of standards you are following, please log into your account 
 on the Online Browsing Platform (OBP).


Thanks for your interest in ISO standards and ISO’s work.



Country Codes Collection 

By clicking on a code, you will find a succinct description of the changes in the "Change history of country code" section at the bottom of the 
webpage.

Code Date Short name

Country codes updated
CN  2017-11-23 /China/
CY  2017-11-23 /Cyprus/
DE  2017-11-23 /Germany/
EC  2017-11-23 /Ecuador/
HK  2017-11-23 /Hong Kong/
HU  2017-11-23 /Hungary/
ID  2017-11-23 /Indonesia/
IS  2017-11-23 /Iceland/
KP  2017-11-23 /Korea (the 
Democratic People's Republic of)/
LA  2017-11-23 /Lao People's 
Democratic Republic (the)/
MD  2017-11-23 /Moldova (the 
Republic of)/
MH  2017-11-23 /Marshall 
Islands (the)/
ML  2017-11-23 /Mali/
MO  2017-11-23 /Macao/
MX  2017-11-23 /Mexico/
NR  2017-11-23 /Nauru/
PA  2017-11-23 /Panama/
PK  2017-11-23 /Pakistan/
QA  2017-11-23 /Qatar/
TG  2017-11-23 /Togo/
TJ  2017-11-23 /Tajikistan/
UG  2017-11-23 /Uganda/



    
  

Re: OFBiz Version Info

[Taher Alkhateeb]

Hi James,

The purpose of Config.java is to configure critical server settings at
startup such as log location, admin settings, etc. These settings could be
also used in test.properties and load-data.properties and all such
properties get a default value if not set.

OFBiz version by definition is not a startup parameter. It is not something
you need to set so that the system works correctly. It's only a piece of
information. That is why I suggested that it might not be a good fit for
start.properties and Config.java. It's also hard for users to find the
version if it is hidden somewhere like that. And given the nature of
verbose logging in OFBiz I suspect that it might not be very useful to spit
out OFBiz version in the logs because it will be lost in the mix.

So if I may suggest maybe there are a few alternatives that could work like:
- adding it to another properties file like general.properties (although
still a bit hidden yet more related than start.properties)
- adding it to the UiLabelMap and putting it in the footer of the system
- putting it in a VERSION file or README.md as originally suggested

I'm sure you can also come up with good ideas to that end, I'm just
thinking quickly of alternatives that might fit.

On Nov 29, 2017 2:30 AM, "James Yong"  wrote:

Hi Taher,

The reason of putting released version (e.g. 16.11.03) in start.properties
file is because the start program is already reading that file and that
info will be included in the startup message. Printing released version to
the console is in line with what other applications, like Tomcat, have been
doing.

I haven't check how the start program will read the VERSION file but I have
no issue with this approach and we can further discuss how it can be done.

Regards,
James Yong

On 2017-11-29 02:51, Taher Alkhateeb  wrote:
> Hi James,
>
> I'm not sure of the purpose of doing all of that? start.properties is
> a file to feed into Config.java which in turn configures the startup
> settings of OFBiz. The version has nothing with the startup code so it
> seems like an improper place to put the property and maybe it might
> confuse users.
>
> Also, why go through all this logic? why not simply create a VERSION
> file and place the version in it? Much simpler and easier if all you
> need is a version reference. Unless you want to introduce some logic?
>
> On Tue, Nov 28, 2017 at 6:04 PM, James Yong  wrote:
> > Hi all,
> >
> > If there is no further discusson, I will create a JIRA issue later to
> > 1) add an ofbiz.version key in start.properties file; and
> > 2) have the ofbiz.version key value included in the startup message.
> >
> > Regards,
> > James Yong
> >
> > On 2017-11-28 01:35, Jacques Le Roux 
wrote:
> >> OK then if we have both, why not?
> >>
> >> Jacques
> >>
> >>
> >> Le 27/11/2017 à 17:15, James Yong a écrit :
> >> > Hi Jacques,
> >> >
> >> > The developer can refer to the proposed ofbiz.version property if
needed.
> >> >
> >> > Regards,
> >> > James Yong
> >> >
> >> > On 2017-11-28 00:03, Jacques Le Roux 
wrote:
> >> >> Hi James,
> >> >>
> >> >> That's good when you start but could be hard to find after many
days running in production for instance
> >> >>
> >> >> Jacques
> >> >>
> >> >>
> >> >> Le 27/11/2017 à 15:43, James Yong a écrit :
> >> >>> Hi all,
> >> >>>
> >> >>> How about hardcoding the released version in start.properties?
> >> >>> E.g.
> >> >>> ofbiz.version=v16.11.03
> >> >>>
> >> >>> During startup, we can print out the version as part of the
startup message like:
> >> >>>    __  _
> >> >>> / __ \/ / __ )(_)___
> >> >>>/ / / / /_  / __  / /_  /
> >> >>> / /_/ / __/ / /_/ / / / /_
> >> >>> \/_/   /_/_/ /___/  v16.11.03 is started and ready.
> >> >>>
> >> >>> Just update the released version in the properties before a
release.
> >> >>>
> >> >>> Regards,
> >> >>> James Yong
> >> >>>
> >> >>>
> >> >>> On 2017-11-27 22:08, Akash Jain 
wrote:
> >>  +1, version information should available somewhere, it will be
helpful.
> >> 
> >>  Thanks and Regards
> >>  --
> >>  Akash Jain
> >> 
> >>  On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga 
wrote:
> >> 
> >> > Hi
> >> >
> >> > Having the version info available somehow could be useful.
Whenever a user
> >> > reports a problem on our user lists, one of the first questions
we ask them
> >> > is "What version are you using?"
> >> >
> >> > Perhaps asking the question about version information, on the
user list
> >> > might help.
> >> >
> >> > Thanks
> >> > Sharan
> >> >
> >> > On 2017-11-27 08:49, Pierre Smits  wrote:
> >> >> Hi Devanshu Vyas,
> >> >>
> >> >> Please see inline.
> >> >>
> >> >> Best regards,
> >> >>
> >> >> Pierre Smits
> >> >>
> >> >> ORRTIZ.COM 
> >> >> OFBiz based solutions & services
> >> >>
> >> >> OEM - The OFBiz Extensions Marketplace1
> >> >> http://oem.ofbizci.net/

Re: Permission overrides auth parameter of service

[Jacques Le Roux]

Le 17/11/2017 à 09:20, Jacques Le Roux a écrit :

Le 03/11/2017 à 05:35, Suraj Khurana a écrit :

Hello team,

I noticed that in any service definition if auth is set to false and
permission service is also the service definition, it overrides the auth
parameter to true by itself.

For quick reference, it is written at *createPermission* method of
*ModelServiceReader* class.
Can someone please elaborate this behavior. IMO, this should not happen.

--
Thanks and Regards,
*Suraj Khurana* | Sr. Enterprise Software Engineer
*HotWax* *Commerce* by  *HotWax Systems*
Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010


Hi Suraj,

I guess you mean "permission service is also *IN* the service definition", 
right?

If yes this is indeed a weird behaviour, fortunately it's not reverse (I mean 
it does not change from true to false) but still

Jacques



Hi Suraj,

No actions (Jira created, etc.) here?

Jacques

Re: OFBiz Version Info

[James Yong]

Hi Taher,

The reason of putting released version (e.g. 16.11.03) in start.properties file 
is because the start program is already reading that file and that info will be 
included in the startup message. Printing released version to the console is in 
line with what other applications, like Tomcat, have been doing.

I haven't check how the start program will read the VERSION file but I have no 
issue with this approach and we can further discuss how it can be done.

Regards,
James Yong  

On 2017-11-29 02:51, Taher Alkhateeb  wrote: 
> Hi James,
> 
> I'm not sure of the purpose of doing all of that? start.properties is
> a file to feed into Config.java which in turn configures the startup
> settings of OFBiz. The version has nothing with the startup code so it
> seems like an improper place to put the property and maybe it might
> confuse users.
> 
> Also, why go through all this logic? why not simply create a VERSION
> file and place the version in it? Much simpler and easier if all you
> need is a version reference. Unless you want to introduce some logic?
> 
> On Tue, Nov 28, 2017 at 6:04 PM, James Yong  wrote:
> > Hi all,
> >
> > If there is no further discusson, I will create a JIRA issue later to
> > 1) add an ofbiz.version key in start.properties file; and
> > 2) have the ofbiz.version key value included in the startup message.
> >
> > Regards,
> > James Yong
> >
> > On 2017-11-28 01:35, Jacques Le Roux  wrote:
> >> OK then if we have both, why not?
> >>
> >> Jacques
> >>
> >>
> >> Le 27/11/2017 à 17:15, James Yong a écrit :
> >> > Hi Jacques,
> >> >
> >> > The developer can refer to the proposed ofbiz.version property if needed.
> >> >
> >> > Regards,
> >> > James Yong
> >> >
> >> > On 2017-11-28 00:03, Jacques Le Roux  
> >> > wrote:
> >> >> Hi James,
> >> >>
> >> >> That's good when you start but could be hard to find after many days 
> >> >> running in production for instance
> >> >>
> >> >> Jacques
> >> >>
> >> >>
> >> >> Le 27/11/2017 à 15:43, James Yong a écrit :
> >> >>> Hi all,
> >> >>>
> >> >>> How about hardcoding the released version in start.properties?
> >> >>> E.g.
> >> >>> ofbiz.version=v16.11.03
> >> >>>
> >> >>> During startup, we can print out the version as part of the startup 
> >> >>> message like:
> >> >>>    __  _
> >> >>> / __ \/ / __ )(_)___
> >> >>>/ / / / /_  / __  / /_  /
> >> >>> / /_/ / __/ / /_/ / / / /_
> >> >>> \/_/   /_/_/ /___/  v16.11.03 is started and ready.
> >> >>>
> >> >>> Just update the released version in the properties before a release.
> >> >>>
> >> >>> Regards,
> >> >>> James Yong
> >> >>>
> >> >>>
> >> >>> On 2017-11-27 22:08, Akash Jain  wrote:
> >>  +1, version information should available somewhere, it will be 
> >>  helpful.
> >> 
> >>  Thanks and Regards
> >>  --
> >>  Akash Jain
> >> 
> >>  On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga  
> >>  wrote:
> >> 
> >> > Hi
> >> >
> >> > Having the version info available somehow could be useful. Whenever 
> >> > a user
> >> > reports a problem on our user lists, one of the first questions we 
> >> > ask them
> >> > is "What version are you using?"
> >> >
> >> > Perhaps asking the question about version information, on the user 
> >> > list
> >> > might help.
> >> >
> >> > Thanks
> >> > Sharan
> >> >
> >> > On 2017-11-27 08:49, Pierre Smits  wrote:
> >> >> Hi Devanshu Vyas,
> >> >>
> >> >> Please see inline.
> >> >>
> >> >> Best regards,
> >> >>
> >> >> Pierre Smits
> >> >>
> >> >> ORRTIZ.COM 
> >> >> OFBiz based solutions & services
> >> >>
> >> >> OEM - The OFBiz Extensions Marketplace1
> >> >> http://oem.ofbizci.net/oci-2/
> >> >> 1 not affiliated to (and not endorsed by) the OFBiz project
> >> >>
> >> >> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas <
> >> > vyas.devansh...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Thank you all for your thoughts on this.
> >> >>>
> >> >>> I really like the idea shared by Taher to create a version file 
> >> >>> using
> >> >>> target and after second thought I agree that it can be a tiresome 
> >> >>> task
> >> > to
> >> >>> update version info manually with each release.
> >> >>> But before we conclude this discussion, I would like to share 
> >> >>> another
> >> >>> thought with you. I think we can add OFBiz version info in the
> >> > licensing
> >> >>> information we add to our files.
> >> >>> I know it will be a manual task, but can be easily done with a 
> >> >>> simple
> >> > Find
> >> >>> & Replace.
> >> >>>
> >> >>> I am happy to work on the whichever implementation we decide
> >> > here(hoping I
> >> >>> am not stepping on anyone's toes).
> >> >>>
> >> >> Don't worry. I bet you aren't. ;)
> >> >>
> >> >>
> >> >

Re: Planning for the creation of the new 17.xx branch(es)

[Taher Alkhateeb]

I think Rishi makes a good point. OFBIZ-9501 is a big task but it
would be nice to create the release after the majority of data is
moved. Rishi is already progressing in this task I think it might be
worth waiting a little bit to have a clean datamodel component.

On Tue, Nov 28, 2017 at 7:20 PM, Rishi Solanki  wrote:
> Jacopo,
> Thanks  for heads-up, I have OFBIZ-9501 with me, and I think it should be
> part of new release. As the data movement will impact on ease of debugging
> and maintenance. I'm planning to move most seed and seed-initial data by
> this weekend.
>
> This should not impact the release date, because If community allow to
> commit after release cut then we can migrate the changes to new release
> after that as well. I'm saying this because I have already move few
> components data to data model component like party, content and work
> effort. So for the release the data consistency should be there at least
> for seed and seed-initial data.
>
> If community not allowing to move data after release cut then I would say
> to hold for few days, so that we can make the data pattern consistent. Also
> may be others may have more tickets/bugs with them.
>
> Kind Regards,
>
> --
> Rishi Solanki
> Sr Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
> www.hotwax.co
>
> On Tue, Nov 28, 2017 at 9:12 PM, Jacopo Cappellato  hotwaxsystems.com> wrote:
>
>> It's the end of November and we are close to the deadline for the creation
>> of the 17.11 branches: how do we feel about it?
>> Let me know if you want me to proceed, otherwise we will create the
>> branches in December and they will be named 17.12
>>
>> Regards,
>>
>> Jacopo
>>
>> On Thu, Oct 12, 2017 at 6:09 PM, Nicolas Malin 
>> wrote:
>>
>> > Hi,
>> >
>> > Agree to create the release 17.11 with a separate products framework &
>> > plugins.
>> >
>> > It's woulb be nice to create this release one week after the next
>> > community days :)
>> >
>> > Nicolas
>> >
>> >
>> >
>> > Le 10/10/2017 à 09:35, Jacopo Cappellato a écrit :
>> >
>> >> Hi all,
>> >>
>> >> I think it is time to start thinking about if, when, how we should
>> create
>> >> the new release branch out of the trunk. Actually, for the first time,
>> we
>> >> should probably create two branches: one for the framework and one for
>> the
>> >> plugins.
>> >> What do you think?
>> >>
>> >> In my opinion we could try to get all the changes we want to have in the
>> >> trunk to be included in the branch by end of November: this means that
>> the
>> >> the creation of the branch could happen at the end of November.
>> >> If this is the case then the names could be:
>> >> release17.11-framework
>> >> release17.11-plugins
>> >>
>> >> The above is for the release *branches* only, not for the actual
>> releases.
>> >> We could decide at a later point if the actual releases will be shipped
>> as
>> >> two separate products (e.g. "Apache OFBiz Framework 17.11.01" and
>> "Apache
>> >> OFBiz Plugins 17.11.01") or merged into one (e.g. "Apache OFBiz
>> >> 17.11.01").
>> >>
>> >> Best regards,
>> >>
>> >> Jacopo
>> >>
>> >>
>> >
>>

Re: OFBiz Version Info

[Taher Alkhateeb]

Hi James,

I'm not sure of the purpose of doing all of that? start.properties is
a file to feed into Config.java which in turn configures the startup
settings of OFBiz. The version has nothing with the startup code so it
seems like an improper place to put the property and maybe it might
confuse users.

Also, why go through all this logic? why not simply create a VERSION
file and place the version in it? Much simpler and easier if all you
need is a version reference. Unless you want to introduce some logic?

On Tue, Nov 28, 2017 at 6:04 PM, James Yong  wrote:
> Hi all,
>
> If there is no further discusson, I will create a JIRA issue later to
> 1) add an ofbiz.version key in start.properties file; and
> 2) have the ofbiz.version key value included in the startup message.
>
> Regards,
> James Yong
>
> On 2017-11-28 01:35, Jacques Le Roux  wrote:
>> OK then if we have both, why not?
>>
>> Jacques
>>
>>
>> Le 27/11/2017 à 17:15, James Yong a écrit :
>> > Hi Jacques,
>> >
>> > The developer can refer to the proposed ofbiz.version property if needed.
>> >
>> > Regards,
>> > James Yong
>> >
>> > On 2017-11-28 00:03, Jacques Le Roux  wrote:
>> >> Hi James,
>> >>
>> >> That's good when you start but could be hard to find after many days 
>> >> running in production for instance
>> >>
>> >> Jacques
>> >>
>> >>
>> >> Le 27/11/2017 à 15:43, James Yong a écrit :
>> >>> Hi all,
>> >>>
>> >>> How about hardcoding the released version in start.properties?
>> >>> E.g.
>> >>> ofbiz.version=v16.11.03
>> >>>
>> >>> During startup, we can print out the version as part of the startup 
>> >>> message like:
>> >>>    __  _
>> >>> / __ \/ / __ )(_)___
>> >>>/ / / / /_  / __  / /_  /
>> >>> / /_/ / __/ / /_/ / / / /_
>> >>> \/_/   /_/_/ /___/  v16.11.03 is started and ready.
>> >>>
>> >>> Just update the released version in the properties before a release.
>> >>>
>> >>> Regards,
>> >>> James Yong
>> >>>
>> >>>
>> >>> On 2017-11-27 22:08, Akash Jain  wrote:
>>  +1, version information should available somewhere, it will be helpful.
>> 
>>  Thanks and Regards
>>  --
>>  Akash Jain
>> 
>>  On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga  wrote:
>> 
>> > Hi
>> >
>> > Having the version info available somehow could be useful. Whenever a 
>> > user
>> > reports a problem on our user lists, one of the first questions we ask 
>> > them
>> > is "What version are you using?"
>> >
>> > Perhaps asking the question about version information, on the user list
>> > might help.
>> >
>> > Thanks
>> > Sharan
>> >
>> > On 2017-11-27 08:49, Pierre Smits  wrote:
>> >> Hi Devanshu Vyas,
>> >>
>> >> Please see inline.
>> >>
>> >> Best regards,
>> >>
>> >> Pierre Smits
>> >>
>> >> ORRTIZ.COM 
>> >> OFBiz based solutions & services
>> >>
>> >> OEM - The OFBiz Extensions Marketplace1
>> >> http://oem.ofbizci.net/oci-2/
>> >> 1 not affiliated to (and not endorsed by) the OFBiz project
>> >>
>> >> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas <
>> > vyas.devansh...@gmail.com>
>> >> wrote:
>> >>
>> >>> Thank you all for your thoughts on this.
>> >>>
>> >>> I really like the idea shared by Taher to create a version file using
>> >>> target and after second thought I agree that it can be a tiresome 
>> >>> task
>> > to
>> >>> update version info manually with each release.
>> >>> But before we conclude this discussion, I would like to share another
>> >>> thought with you. I think we can add OFBiz version info in the
>> > licensing
>> >>> information we add to our files.
>> >>> I know it will be a manual task, but can be easily done with a simple
>> > Find
>> >>> & Replace.
>> >>>
>> >>> I am happy to work on the whichever implementation we decide
>> > here(hoping I
>> >>> am not stepping on anyone's toes).
>> >>>
>> >> Don't worry. I bet you aren't. ;)
>> >>
>> >>
>> >>> And my reason to raise the concern was that it is very difficult to
>> >>> identify which version of code a user is using(a real-time scenario
>> > where I
>> >>> was exposed to OFBiz code and I couldn't perform anything on it. So
>> > just by
>> >>> looking at it, I was unable to determine what version it was)
>> >>>
>> >>>
>> >> So you experienced a user being exposed to a OOTB OFBiz deployment,
>> >> deployed by your employer HotWax? Or was the user exposed to a 
>> >> deployment
>> >> that was also modified? In either case this is an issue related to the
>> >> Release Management process applied. And not necessarily an OFBIZ 
>> >> problem.
>> >>
>> >>
>> >>> Waiting for your replies!!
>> >>>
>> >>>
>> >>> Thanks & Regards,
>> >>> Devanshu Vyas.
>> >>>
>> >>
>>
>>

Re: Planning for the creation of the new 17.xx branch(es)

[Rishi Solanki]

Jacopo,
Thanks  for heads-up, I have OFBIZ-9501 with me, and I think it should be
part of new release. As the data movement will impact on ease of debugging
and maintenance. I'm planning to move most seed and seed-initial data by
this weekend.

This should not impact the release date, because If community allow to
commit after release cut then we can migrate the changes to new release
after that as well. I'm saying this because I have already move few
components data to data model component like party, content and work
effort. So for the release the data consistency should be there at least
for seed and seed-initial data.

If community not allowing to move data after release cut then I would say
to hold for few days, so that we can make the data pattern consistent. Also
may be others may have more tickets/bugs with them.

Kind Regards,

--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co

On Tue, Nov 28, 2017 at 9:12 PM, Jacopo Cappellato  wrote:

> It's the end of November and we are close to the deadline for the creation
> of the 17.11 branches: how do we feel about it?
> Let me know if you want me to proceed, otherwise we will create the
> branches in December and they will be named 17.12
>
> Regards,
>
> Jacopo
>
> On Thu, Oct 12, 2017 at 6:09 PM, Nicolas Malin 
> wrote:
>
> > Hi,
> >
> > Agree to create the release 17.11 with a separate products framework &
> > plugins.
> >
> > It's woulb be nice to create this release one week after the next
> > community days :)
> >
> > Nicolas
> >
> >
> >
> > Le 10/10/2017 à 09:35, Jacopo Cappellato a écrit :
> >
> >> Hi all,
> >>
> >> I think it is time to start thinking about if, when, how we should
> create
> >> the new release branch out of the trunk. Actually, for the first time,
> we
> >> should probably create two branches: one for the framework and one for
> the
> >> plugins.
> >> What do you think?
> >>
> >> In my opinion we could try to get all the changes we want to have in the
> >> trunk to be included in the branch by end of November: this means that
> the
> >> the creation of the branch could happen at the end of November.
> >> If this is the case then the names could be:
> >> release17.11-framework
> >> release17.11-plugins
> >>
> >> The above is for the release *branches* only, not for the actual
> releases.
> >> We could decide at a later point if the actual releases will be shipped
> as
> >> two separate products (e.g. "Apache OFBiz Framework 17.11.01" and
> "Apache
> >> OFBiz Plugins 17.11.01") or merged into one (e.g. "Apache OFBiz
> >> 17.11.01").
> >>
> >> Best regards,
> >>
> >> Jacopo
> >>
> >>
> >
>

Re: Planning for the creation of the new 17.xx branch(es)

[Michael Brohl]

Hi Jacopo,

I am planning to do a bunch of FindBugs/refactoring commits in the 
coming days/weeks, hopefully all of the currently open issues.


It would be great if we can move the release to December.

@all: any help on the FindBugs/refactoring issues by fellow committers 
are greatly appreciated ;-)


Thanks and regards,

Michael


Am 28.11.17 um 16:42 schrieb Jacopo Cappellato:

It's the end of November and we are close to the deadline for the creation
of the 17.11 branches: how do we feel about it?
Let me know if you want me to proceed, otherwise we will create the
branches in December and they will be named 17.12

Regards,

Jacopo

On Thu, Oct 12, 2017 at 6:09 PM, Nicolas Malin 
wrote:


Hi,

Agree to create the release 17.11 with a separate products framework &
plugins.

It's woulb be nice to create this release one week after the next
community days :)

Nicolas



Le 10/10/2017 à 09:35, Jacopo Cappellato a écrit :


Hi all,

I think it is time to start thinking about if, when, how we should create
the new release branch out of the trunk. Actually, for the first time, we
should probably create two branches: one for the framework and one for the
plugins.
What do you think?

In my opinion we could try to get all the changes we want to have in the
trunk to be included in the branch by end of November: this means that the
the creation of the branch could happen at the end of November.
If this is the case then the names could be:
release17.11-framework
release17.11-plugins

The above is for the release *branches* only, not for the actual releases.
We could decide at a later point if the actual releases will be shipped as
two separate products (e.g. "Apache OFBiz Framework 17.11.01" and "Apache
OFBiz Plugins 17.11.01") or merged into one (e.g. "Apache OFBiz
17.11.01").

Best regards,

Jacopo







smime.p7s
Description: S/MIME Cryptographic Signature

Re: Planning for the creation of the new 17.xx branch(es)

[Jacques Le Roux]

Hi Jacopo,

If nobody minds I'd prefer to wait a month more (or a bit less)

I have several actions pending and my mind is in a mess because of that.

So 15+ days more would help

Thanks

Jacques


Le 28/11/2017 à 16:42, Jacopo Cappellato a écrit :

It's the end of November and we are close to the deadline for the creation
of the 17.11 branches: how do we feel about it?
Let me know if you want me to proceed, otherwise we will create the
branches in December and they will be named 17.12

Regards,

Jacopo

On Thu, Oct 12, 2017 at 6:09 PM, Nicolas Malin 
wrote:


Hi,

Agree to create the release 17.11 with a separate products framework &
plugins.

It's woulb be nice to create this release one week after the next
community days :)

Nicolas



Le 10/10/2017 à 09:35, Jacopo Cappellato a écrit :


Hi all,

I think it is time to start thinking about if, when, how we should create
the new release branch out of the trunk. Actually, for the first time, we
should probably create two branches: one for the framework and one for the
plugins.
What do you think?

In my opinion we could try to get all the changes we want to have in the
trunk to be included in the branch by end of November: this means that the
the creation of the branch could happen at the end of November.
If this is the case then the names could be:
release17.11-framework
release17.11-plugins

The above is for the release *branches* only, not for the actual releases.
We could decide at a later point if the actual releases will be shipped as
two separate products (e.g. "Apache OFBiz Framework 17.11.01" and "Apache
OFBiz Plugins 17.11.01") or merged into one (e.g. "Apache OFBiz
17.11.01").

Best regards,

Jacopo

Re: Planning for the creation of the new 17.xx branch(es)

[Jacopo Cappellato]

It's the end of November and we are close to the deadline for the creation
of the 17.11 branches: how do we feel about it?
Let me know if you want me to proceed, otherwise we will create the
branches in December and they will be named 17.12

Regards,

Jacopo

On Thu, Oct 12, 2017 at 6:09 PM, Nicolas Malin 
wrote:

> Hi,
>
> Agree to create the release 17.11 with a separate products framework &
> plugins.
>
> It's woulb be nice to create this release one week after the next
> community days :)
>
> Nicolas
>
>
>
> Le 10/10/2017 à 09:35, Jacopo Cappellato a écrit :
>
>> Hi all,
>>
>> I think it is time to start thinking about if, when, how we should create
>> the new release branch out of the trunk. Actually, for the first time, we
>> should probably create two branches: one for the framework and one for the
>> plugins.
>> What do you think?
>>
>> In my opinion we could try to get all the changes we want to have in the
>> trunk to be included in the branch by end of November: this means that the
>> the creation of the branch could happen at the end of November.
>> If this is the case then the names could be:
>> release17.11-framework
>> release17.11-plugins
>>
>> The above is for the release *branches* only, not for the actual releases.
>> We could decide at a later point if the actual releases will be shipped as
>> two separate products (e.g. "Apache OFBiz Framework 17.11.01" and "Apache
>> OFBiz Plugins 17.11.01") or merged into one (e.g. "Apache OFBiz
>> 17.11.01").
>>
>> Best regards,
>>
>> Jacopo
>>
>>
>

Re: Translating simple-method codes to Groovy

[Jacopo Cappellato]

Hi Dennis,

in general the best way to go is to wrap up the Minilang method into a
service definition and then convert simple-method-call into service-call.
For this specific case, genericBasePermissionCheck, you will find that the
method has been already wrapped into the homonymous service so you should
be able to use that (check the service definition and also the interface
service definition named permissionInterface).

I hope it helps!

Jacopo

On Tue, Nov 28, 2017 at 2:35 PM, Dennis Balkir 
wrote:

> Hello Devs,
>
> while converting some of the Mini-Lang files to Groovy I have encountered
> a problem.
>
> I started converting the file CatalogServices.xml to Groovy, as I noticed,
> that one of its methods made a simple-method-call for the method
> „genericBasePermissionCheck“ from CommonPermissionServices.xml.
> Is there an equivalent for simple-method-calls which I can use in Groovy
> or do I have to use a service-call, and if the latter, is there some things
> I have to know when changing from a simple-method-call to a service-call?
>
> Best regards,
> Dennis Balkir
> --
> 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: OFBiz Version Info

[James Yong]

Hi all,

If there is no further discusson, I will create a JIRA issue later to 
1) add an ofbiz.version key in start.properties file; and 
2) have the ofbiz.version key value included in the startup message.

Regards,
James Yong

On 2017-11-28 01:35, Jacques Le Roux  wrote: 
> OK then if we have both, why not?
> 
> Jacques
> 
> 
> Le 27/11/2017 à 17:15, James Yong a écrit :
> > Hi Jacques,
> >
> > The developer can refer to the proposed ofbiz.version property if needed.
> >
> > Regards,
> > James Yong
> >
> > On 2017-11-28 00:03, Jacques Le Roux  wrote:
> >> Hi James,
> >>
> >> That's good when you start but could be hard to find after many days 
> >> running in production for instance
> >>
> >> Jacques
> >>
> >>
> >> Le 27/11/2017 à 15:43, James Yong a écrit :
> >>> Hi all,
> >>>
> >>> How about hardcoding the released version in start.properties?
> >>> E.g.
> >>> ofbiz.version=v16.11.03
> >>>
> >>> During startup, we can print out the version as part of the startup 
> >>> message like:
> >>>    __  _
> >>> / __ \/ / __ )(_)___
> >>>/ / / / /_  / __  / /_  /
> >>> / /_/ / __/ / /_/ / / / /_
> >>> \/_/   /_/_/ /___/  v16.11.03 is started and ready.
> >>>
> >>> Just update the released version in the properties before a release.
> >>>
> >>> Regards,
> >>> James Yong
> >>>
> >>>
> >>> On 2017-11-27 22:08, Akash Jain  wrote:
>  +1, version information should available somewhere, it will be helpful.
> 
>  Thanks and Regards
>  --
>  Akash Jain
> 
>  On Mon, Nov 27, 2017 at 6:07 PM, Sharan Foga  wrote:
> 
> > Hi
> >
> > Having the version info available somehow could be useful. Whenever a 
> > user
> > reports a problem on our user lists, one of the first questions we ask 
> > them
> > is "What version are you using?"
> >
> > Perhaps asking the question about version information, on the user list
> > might help.
> >
> > Thanks
> > Sharan
> >
> > On 2017-11-27 08:49, Pierre Smits  wrote:
> >> Hi Devanshu Vyas,
> >>
> >> Please see inline.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM 
> >> OFBiz based solutions & services
> >>
> >> OEM - The OFBiz Extensions Marketplace1
> >> http://oem.ofbizci.net/oci-2/
> >> 1 not affiliated to (and not endorsed by) the OFBiz project
> >>
> >> On Mon, Nov 27, 2017 at 7:33 AM, Devanshu Vyas <
> > vyas.devansh...@gmail.com>
> >> wrote:
> >>
> >>> Thank you all for your thoughts on this.
> >>>
> >>> I really like the idea shared by Taher to create a version file using
> >>> target and after second thought I agree that it can be a tiresome task
> > to
> >>> update version info manually with each release.
> >>> But before we conclude this discussion, I would like to share another
> >>> thought with you. I think we can add OFBiz version info in the
> > licensing
> >>> information we add to our files.
> >>> I know it will be a manual task, but can be easily done with a simple
> > Find
> >>> & Replace.
> >>>
> >>> I am happy to work on the whichever implementation we decide
> > here(hoping I
> >>> am not stepping on anyone's toes).
> >>>
> >> Don't worry. I bet you aren't. ;)
> >>
> >>
> >>> And my reason to raise the concern was that it is very difficult to
> >>> identify which version of code a user is using(a real-time scenario
> > where I
> >>> was exposed to OFBiz code and I couldn't perform anything on it. So
> > just by
> >>> looking at it, I was unable to determine what version it was)
> >>>
> >>>
> >> So you experienced a user being exposed to a OOTB OFBiz deployment,
> >> deployed by your employer HotWax? Or was the user exposed to a 
> >> deployment
> >> that was also modified? In either case this is an issue related to the
> >> Release Management process applied. And not necessarily an OFBIZ 
> >> problem.
> >>
> >>
> >>> Waiting for your replies!!
> >>>
> >>>
> >>> Thanks & Regards,
> >>> Devanshu Vyas.
> >>>
> >>
> 
> 

Translating simple-method codes to Groovy

[Dennis Balkir]

Hello Devs,

while converting some of the Mini-Lang files to Groovy I have encountered a 
problem.

I started converting the file CatalogServices.xml to Groovy, as I noticed, that 
one of its methods made a simple-method-call for the method 
„genericBasePermissionCheck“ from CommonPermissionServices.xml.
Is there an equivalent for simple-method-calls which I can use in Groovy or do 
I have to use a service-call, and if the latter, is there some things I have to 
know when changing from a simple-method-call to a service-call?

Best regards,
Dennis Balkir
-- 
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: svn propchange: r1816537 - svn:log

[Jacques Le Roux]

Thanks Deepak,

I also reopened https://issues.apache.org/jira/browse/OFBIZ-9264 in case it helps you. Anyway there are other related issues with OFBIZ-9264, so other 
reasons to reopen


A pity Francis did not answer so far :-(

Jacques


Le 28/11/2017 à 11:53, jler...@apache.org a écrit :

Author: jleroux
Revision: 1816537
Modified property: svn:log

Modified: svn:log at Tue Nov 28 10:53:11 2017
--
--- svn:log (original)
+++ svn:log Tue Nov 28 10:53:11 2017
@@ -2,3 +2,5 @@ Improved: Use console.log instead of ale
setLocaleFromBrowser request called setUserLocale.js and its executed for 
each request,
 auth is set true for setLocaleFromBrowser service so it return error if it 
executed from login screen.
 Still need to refine way to set setLocaleFromBrowser as this request 
executed with each time when page refreshed.
+
+This is an improvement related with OFBIZ-9264

Re: svn propchange: r1816537 - svn:log

[Deepak Dixit]

Thanks Jacques.

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

On Tue, Nov 28, 2017 at 4:23 PM,  wrote:

> Author: jleroux
> Revision: 1816537
> Modified property: svn:log
>
> Modified: svn:log at Tue Nov 28 10:53:11 2017
> 
> --
> --- svn:log (original)
> +++ svn:log Tue Nov 28 10:53:11 2017
> @@ -2,3 +2,5 @@ Improved: Use console.log instead of ale
>setLocaleFromBrowser request called setUserLocale.js and its executed
> for each request,
> auth is set true for setLocaleFromBrowser service so it return error
> if it executed from login screen.
> Still need to refine way to set setLocaleFromBrowser as this request
> executed with each time when page refreshed.
> +
> +This is an improvement related with OFBIZ-9264
>
>