This was introduced by OFBIZ-1794, not sure we want to remove it, Jacopo Cappellato, Harsh Vijaywargiya?

Moreover other people might use it. I prefer to close as won't fix!

Other people?

So, you're suggesting to not clean up unused code?

I mean that people could have used it in custom projects and removing it from the trunk might impair their projects

"The road to hell is paved with good intentions"

Then I suggest to let them come forward and explain the dependency before you close the issue as a won't fix. Now you know nothing and make assumptions.

Are you serious?

This argument is good for branches, but i find it strange for trunk. The use of trunk code from potential users, shouldn't block cleaning or improving the project.

It not the first time we talk about project based on trunk, that should be done at their own risk.

That's true, but it exists and why annoy them? Of course we can't know before since few people seriously follows things...
I don't see a problem keeping that

No problem either to me, it's a very basic/usable view. I just pointed the argument

+1 for removing it, if it is not used by OFBiz.

Reopening the issue, to allow any interested party to create functionality utilising the entity.

If not done within a reasonable amount of time, this issue should be considered a reminder to remove it before the creation of the next release branch.

(resend as requested)
I'm sure that there are a few of these cases - i.e. where entities are not referenced in any Screen, Form and Service definition. I suspect that this would be the case with especially view-entities which are used mainly in summary/report type screens and less so in transactional screens. I just did a quick search on the BenefitTypeAndParty view-entity and could not find any reference to it in Screen, Form or Service definitions. Does this qualify it for removal/deprecation? I don't think so. Just because it has not being used does not necessarily translate into it not being useful. We should approach deprecating entities with caution, particularly those which related to core ERP functionalities. Long story short - I don't think its a good idea to deprecate this entity or any other at this stage. Entity deprecation should be done at a customization level and not at a Project level.

I don't know if we have one - but a Deprecation Policy might be helpful when dealing with these kinds of issues. As an example see - https://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy

Gavin

Deprecation policies for a view entity don't make much sense because removing it will not impact the data but only the data extraction code.

I agree that https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+Requiring+Data+Migration+-+upgrade+ofbiz is not directly concerned. A word about it would not harm though, I can't think of a better place

This patch addresses the issue.

Ping?

Thanks Pierre,

your modified patch is in trunk at revision 1756365.