Re: Request for enhance entity:SystemProperty.

[Wai]

Is anyone interested in this enhancement?
Thanks



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-Request-for-enhance-entity-SystemProperty-tp4709235p4709546.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Oracle: Java unlimited cryptographic policy

[Jacques Le Roux]

Hi,

I don't think we are concerned, but it's still worth to be noted

https://s.apache.org/r3mQ

Jacques

Re: Welcome Rishi Solanki as a New Committer!

[Rishi Solanki]

Thanks to all for the wonderful wishes and support.

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

On Fri, Aug 11, 2017 at 1:01 PM, Michael Brohl 
wrote:

> Welcome to the team, Rishi!
>
> Regards,
>
> Michael
>
> Am 09.08.17 um 10:56 schrieb Sharan Foga:
>
> The OFBiz PMC has invited Rishi Solanki to become a new committer and are
>> happy to announce that he has accepted.
>>
>> Some of the key factors considered for inviting him were as follows:
>>
>> - He has been involved with the OFBiz project for quite a while which
>> shows dedication and commitment
>> - He has a lot of good knowledge that he is happy to share which shows he
>> is a good team player
>> - His work is consistent, has good code quality and he has provided a
>> range of patches
>> - He is friendly, respectful and keen to help out others in the community
>>
>> Please join me in welcoming and congratulating Rishi!
>>
>> Thanks
>> Sharan
>>
>
>
>

Re: Welcome Akash Jain as a New Committer!

[Rishi Solanki]

Congratulations Akash! :-)

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

On Fri, Aug 11, 2017 at 1:01 PM, Michael Brohl 
wrote:

> Welcome to the team, Akash!
>
> Regards,
>
> Michael
>
> Am 09.08.17 um 10:58 schrieb Sharan Foga:
>
> The OFBiz PMC has invited Akash Jain to become a new committer and are
>> happy to announce that he has accepted.
>>
>> Some of the key factors considered for inviting him were as follows:
>>
>> - He has been involved with the OFBiz project for quite a while which
>> shows his dedication and commitment
>> - He has a lot of good knowledge (both functional and technical) that he
>> is happy to share which shows he is a good team player
>> - He is very active, positive and respectful to others in the community
>> - He has contributed patches and shows a willingness to learn which is
>> really important as the project continues to go through changes
>>
>> Please join me in welcoming and congratulating Akash.
>>
>> Thanks
>> Sharan
>>
>
>
>

Re: Rule to deprecated a service

[Michael Brohl]

Since we do a major release only once a year, maybe more, I think it is 
enough time for users to follow-up the changes if we proceed as you 
described.


There might be exceptions, e.g. if we make changes in an API which is 
widely used.


One thing I would like to add: if we deprecate code, we should also 
change the use of the deprecated code to an alternative (if there is 
one) *in the same commit*. This way all users have enough time to get 
used to the alternative API/code and can also follow the changes as a 
migration example for their own code.


We should also have a Jira for every deprecation and the corresponding 
changes.


Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 12.08.17 um 11:03 schrieb Jacques Le Roux:

Thanks Nicolas,

Actually when I read OFBIZ-6273 it seems Jacopo are on the same page 
than me:


The code that has been deprecated before December 2014 will be released
in the releases of the 14.12 branch: in this way users will be notified
about deprecated methods/code.

For this reason we can proceed and remove all the deprecated code from 
trunk, deprecated before December 2014.


Anyway I'd like to have more opinions about *when to remove deprecated 
code before writing definitive rules about it*.


It seems Jacopo, Scott and I are on the same page (please confirm guys).

And you Nicolas propose something which lets more time to users. This 
is maybe not a bad idea, our users are our most important assets!


Jacques


Le 11/08/2017 à 20:52, Nicolas Malin a écrit :
Imagine we are the 30 december 2019 and we decide to create a new 
release.

We have on trunk :
 * addCatalogMember deprecated since="next release"
 * deleteRateAmount deprecated since="17.11"
 * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
 * addCatalogMember deprecated since="19.12"
 * deleteRateAmount deprecated since="17.11"
 * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
 * addCatalogMember deprecated since="19.12"
 * deleteWorkEffortAssignment depraceted since="18.12"

I hope this example is less confused that the sentence :)

Nicolas

Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :

Hi Nicolas,

I'm unsure about your point

"remove all element contains with a since not on the last stable 
branch on trunk"


I guess you mean

"to remove on trunk all elements which contains a 
'since=releaseBranchNumber' with releaseBranchNumber being different 
from the last stable branch just created"


For instance in your example we would remove all elements deprecated 
but not those marked with deprecated with 'since=17.11'


Right?

Please confirm and others please raise a hand if you disagree.

IMO we could remove all deprecated code from trunk at this moment. I 
mean, we would not even keep services with 'since=17.11'


So to be totally clear, my take is to remove all deprecated code 
(not only services) when we release a branch. In other words just 
after the 1st release of a branch the trunk should no longer contain 
any deprecated code.

Is that too much and early ?
Another possibility would be to remove all the deprecated code from 
the trunk when releasing the last release of the last branch (ie 
when a branch get to its End Of Life/Support)


Would be the rule Nicolas proposes better ? ie, if I have well 
understood, we keep in trunk the deprecated code deprecated between 
the creation of the "old" (previous stable) and the (new) stable branch


I guess whether rule we pick we all agree that it must apply to all 
code not only services, or Java code, etc.


Some suggest to keep the deprecated code during 2-3 versions (OFBiz 
code can be considered an API): 
https://softwareengineering.stackexchange.com/questions/67837/when-to-deprecate-and-when-to-delete-in-java


So what are your opinions :) ?

Jacques


Le 11/08/2017 à 12:08, Nicolas Malin a écrit :

Hello,

I imagine the following process :
* deprecated on trunk an element and indicate 
since="$NextReleaseBranch" (or somethink like that)

* When before create the new release branch like 17.11 :
** run a replaceAll $NextReleaseBranch by 17.11
** update the trunk
* Create the new stable branch
* remove all element contains with a since not on the last stable 
branch on trunk

* update trunk

With this we have a new stable branch with the deprecated from the 
previous stable branch (keep stability much as possible), and a 
trunk cleaned of old deprecated who may introduce a potential 
instability but we have the time to correct it.


Nicolas


Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :

Le 10/08/2017 à 13:25, Scott Gray a écrit :
I think we've had these discussions before Jacques, I'd search 
the mailing
lists and then perhaps only continue the conversation if you have 
concerns

about what was agreed previously.

I'm pretty sure the policy was "remove after the next release is 
out", and

actually released, not 

Re: Rule to deprecated a service

[Jacques Le Roux]

Thanks Nicolas,

Actually when I read OFBIZ-6273 it seems Jacopo are on the same page than me:

The code that has been deprecated before December 2014 will be released
in the releases of the 14.12 branch: in this way users will be notified
about deprecated methods/code.

For this reason we can proceed and remove all the deprecated code from trunk, 
deprecated before December 2014.

Anyway I'd like to have more opinions about *when to remove deprecated code 
before writing definitive rules about it*.

It seems Jacopo, Scott and I are on the same page (please confirm guys).

And you Nicolas propose something which lets more time to users. This is maybe 
not a bad idea, our users are our most important assets!

Jacques


Le 11/08/2017 à 20:52, Nicolas Malin a écrit :

Imagine we are the 30 december 2019 and we decide to create a new release.
We have on trunk :
 * addCatalogMember deprecated since="next release"
 * deleteRateAmount deprecated since="17.11"
 * deleteWorkEffortAssignment depraceted since="18.12"

We prepare the release, we have on trunk :
 * addCatalogMember deprecated since="19.12"
 * deleteRateAmount deprecated since="17.11"
 * deleteWorkEffortAssignment depraceted since="18.12"

We create the stable branche and after clean the trunk,
now on trunk we have :
 * addCatalogMember deprecated since="19.12"
 * deleteWorkEffortAssignment depraceted since="18.12"

I hope this example is less confused that the sentence :)

Nicolas

Le 11/08/2017 à 17:05, Jacques Le Roux a écrit :

Hi Nicolas,

I'm unsure about your point

"remove all element contains with a since not on the last stable branch on 
trunk"

I guess you mean

"to remove on trunk all elements which contains a 'since=releaseBranchNumber' with releaseBranchNumber being different from the last stable branch 
just created"


For instance in your example we would remove all elements deprecated but not 
those marked with deprecated with 'since=17.11'

Right?

Please confirm and others please raise a hand if you disagree.

IMO we could remove all deprecated code from trunk at this moment. I mean, we 
would not even keep services with 'since=17.11'

So to be totally clear, my take is to remove all deprecated code (not only services) when we release a branch. In other words just after the 1st 
release of a branch the trunk should no longer contain any deprecated code.

Is that too much and early ?
Another possibility would be to remove all the deprecated code from the trunk when releasing the last release of the last branch (ie when a branch 
get to its End Of Life/Support)


Would be the rule Nicolas proposes better ? ie, if I have well understood, we keep in trunk the deprecated code deprecated between the creation of 
the "old" (previous stable) and the (new) stable branch


I guess whether rule we pick we all agree that it must apply to all code not 
only services, or Java code, etc.

Some suggest to keep the deprecated code during 2-3 versions (OFBiz code can be considered an API): 
https://softwareengineering.stackexchange.com/questions/67837/when-to-deprecate-and-when-to-delete-in-java


So what are your opinions :) ?

Jacques


Le 11/08/2017 à 12:08, Nicolas Malin a écrit :

Hello,

I imagine the following process :
* deprecated on trunk an element and indicate since="$NextReleaseBranch" (or 
somethink like that)
* When before create the new release branch like 17.11 :
** run a replaceAll $NextReleaseBranch by 17.11
** update the trunk
* Create the new stable branch
* remove all element contains with a since not on the last stable branch on 
trunk
* update trunk

With this we have a new stable branch with the deprecated from the previous stable branch (keep stability much as possible), and a trunk cleaned 
of old deprecated who may introduce a potential instability but we have the time to correct it.


Nicolas


Le 10/08/2017 à 13:46, Jacques Le Roux a écrit :

Le 10/08/2017 à 13:25, Scott Gray a écrit :

I think we've had these discussions before Jacques, I'd search the mailing
lists and then perhaps only continue the conversation if you have concerns
about what was agreed previously.

I'm pretty sure the policy was "remove after the next release is out", and
actually released, not just when a branch is cut.

Oops, that's what I meant too with "deprecate code when we create the first release 
of the last freezed branch".
I tried to be more precise there than in my previous sentence "remove all deprecated 
code in trunk when for instance creating a new release."
But I did not notice I misused "deprecate code" for "remove deprecated code".

I think we are on the same page and don't want to wait loo long keeping 
deprecated code, first occasion is best ;)

Jacques

Re: Permission service not on the same transaction

[Jacques Le Roux]

Hi Nicolas,

Just stumbled upon this. Is there a Jira? What is the revision commit number?

Thanks
Jacques (sent from PonyMail)

On 2016-04-14 21:03, Nicolas Malin  wrote: 
> No remarks on this case ?
> 
> If the silent is present I open an issue and commit this patch ;)
> 
> Nicolas
> 
> Le 07/04/2016 10:00, Nicolas Malin a écrit :
> > Hello,
> >
> > Currently I continue the conversion on shipment  crud service and I 
> > detected that many service use the same mini-lang call to check if the 
> > shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
> >
> > I convert it on service to call it directly by the permission-service 
> > like that :
> >
> >  > default-entity-name="ShipmentPackageContent" engine="entity-auto" 
> > invoke="create" auth="true">...
> >  > service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
> > ...
> > 
> >
> > The problem with this change that when I run the unit tests, I have 
> > some failed to due database lock on shipment.
> > After some analyse I founded that the permission service wasn't call 
> > on the same service's transaction.
> > I a realize this change :
> >
> > Index: framework/service/src/org/ofbiz/service/ModelService.java
> > ===
> > --- framework/service/src/org/ofbiz/service/ModelService.java 
> > (révision 1737860)
> > +++ framework/service/src/org/ofbiz/service/ModelService.java (copie 
> > de travail)
> > @@ -985,7 +985,7 @@
> >  LocalDispatcher dispatcher = dctx.getDispatcher();
> >  Map resp;
> >  try {
> > -resp = dispatcher.runSync(permission.name, ctx, 
> > 300, true);
> > +resp = dispatcher.runSync(permission.name, ctx);
> >  } catch (GenericServiceException e) {
> >  Debug.logError(e, module);
> >  Map result = 
> > ServiceUtil.returnSuccess();
> >
> > All unit test pass.
> > Anyone know the reason to call the permission service on a new 
> > transaction ?
> > I couldn't spot any valid reason.
> >
> > Thnaks for help ;)
> >
> > Nicolas
> >
> > -- 
> > #jeSuisCharlie
> > logoNrd 
> > Nicolas Malin
> > Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom 
> > pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
> > informat...@nereide.fr
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz  | ofbiz-fr 
> >  | | réseau LE 
> > 
> 
>