[DISCUSSION] Simplification of the create component process

[Pierre Smits]

Hi all,

Currently our create component process (./gradlew createComponent) is error
prone.

It requires 4 variables to successfully create a new component in the
hot-deploy folder to jumpstart development with a component skeleton. These
variables are:

   - componentName
   - componentResourceName
   - webappName
   - basePermission

I believe we should reduce the number of variables to just 1 variable (e.g.
componentId) to create consistency throughout the skeleton and its
associated datasets. The developer can, after a skeleton has been built,
then apply any kind of changes according to his/her requirements an needs.

What is your opinion on this?

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

[taher]

Hi Pierre,

Hmmm, that's actually a nice idea. I suggest however we avoid componentId
and just apply the following to the variables:

componentName: mandatory
componentResourceName: optional, defaults to componentName
webappName: optional, defaults to componentName
basePermission: optional, defaults to OFBTOOLS (or whatever defaults were)

This way, You get a real nice and simple command for end-users to create
new components while at the same time allowing more expressiveness. This
becomes similar to the createTenant task which also has everything optional
except the tenantId and tenantName

Taher Alkhateeb

On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <[hidden email]>
wrote:

> Hi all,
>
> Currently our create component process (./gradlew createComponent) is error
> prone.
>
> It requires 4 variables to successfully create a new component in the
> hot-deploy folder to jumpstart development with a component skeleton. These
> variables are:
>
>    - componentName
>    - componentResourceName
>    - webappName
>    - basePermission
>
> I believe we should reduce the number of variables to just 1 variable (e.g.
> componentId) to create consistency throughout the skeleton and its
> associated datasets. The developer can, after a skeleton has been built,
> then apply any kind of changes according to his/her requirements an needs.
>
> What is your opinion on this?
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>

[Pierre Smits]

Hi Taher,

OFBTOOLS is not required as it is already defined in the template to be
included. When added in basePermission it leads to duplication in the
generated ofbiz-component.xml file.

I already created an issue for that, see
https://issues.apache.org/jira/browse/OFBIZ-7785

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
[hidden email]> wrote:

> Hi Pierre,
>
> Hmmm, that's actually a nice idea. I suggest however we avoid componentId
> and just apply the following to the variables:
>
> componentName: mandatory
> componentResourceName: optional, defaults to componentName
> webappName: optional, defaults to componentName
> basePermission: optional, defaults to OFBTOOLS (or whatever defaults were)
>
> This way, You get a real nice and simple command for end-users to create
> new components while at the same time allowing more expressiveness. This
> becomes similar to the createTenant task which also has everything optional
> except the tenantId and tenantName
>
> Taher Alkhateeb
>
> On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <[hidden email]>
> wrote:
>
> > Hi all,
> >
> > Currently our create component process (./gradlew createComponent) is
> error
> > prone.
> >
> > It requires 4 variables to successfully create a new component in the
> > hot-deploy folder to jumpstart development with a component skeleton.
> These
> > variables are:
> >
> >    - componentName
> >    - componentResourceName
> >    - webappName
> >    - basePermission
> >
> > I believe we should reduce the number of variables to just 1 variable
> (e.g.
> > componentId) to create consistency throughout the skeleton and its
> > associated datasets. The developer can, after a skeleton has been built,
> > then apply any kind of changes according to his/her requirements an
> needs.
> >
> > What is your opinion on this?
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
>

[taher]

Noted, thank you.

On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <[hidden email]>
wrote:

> Hi Taher,
>
> OFBTOOLS is not required as it is already defined in the template to be
> included. When added in basePermission it leads to duplication in the
> generated ofbiz-component.xml file.
>
> I already created an issue for that, see
> https://issues.apache.org/jira/browse/OFBIZ-7785
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> [hidden email]> wrote:
>
> > Hi Pierre,
> >
> > Hmmm, that's actually a nice idea. I suggest however we avoid componentId
> > and just apply the following to the variables:
> >
> > componentName: mandatory
> > componentResourceName: optional, defaults to componentName
> > webappName: optional, defaults to componentName
> > basePermission: optional, defaults to OFBTOOLS (or whatever defaults
> were)
> >
> > This way, You get a real nice and simple command for end-users to create
> > new components while at the same time allowing more expressiveness. This
> > becomes similar to the createTenant task which also has everything
> optional
> > except the tenantId and tenantName
> >
> > Taher Alkhateeb
> >
> > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <[hidden email]>
> > wrote:
> >
> > > Hi all,
> > >
> > > Currently our create component process (./gradlew createComponent) is
> > error
> > > prone.
> > >
> > > It requires 4 variables to successfully create a new component in the
> > > hot-deploy folder to jumpstart development with a component skeleton.
> > These
> > > variables are:
> > >
> > >    - componentName
> > >    - componentResourceName
> > >    - webappName
> > >    - basePermission
> > >
> > > I believe we should reduce the number of variables to just 1 variable
> > (e.g.
> > > componentId) to create consistency throughout the skeleton and its
> > > associated datasets. The developer can, after a skeleton has been
> built,
> > > then apply any kind of changes according to his/her requirements an
> > needs.
> > >
> > > What is your opinion on this?
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM <http://www.orrtiz.com>
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> >
>

[Jacopo Cappellato-5]

+1 to the idea, with defaults for optional resources (1 mandatory, 3
optional).

Wish: it would be nice to have more control on the component structure; for
example create a component without a webapp, add a webapp to an existing
component etc...

Jacopo

On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
[hidden email]> wrote:

> Noted, thank you.
>
> On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <[hidden email]>
> wrote:
>
> > Hi Taher,
> >
> > OFBTOOLS is not required as it is already defined in the template to be
> > included. When added in basePermission it leads to duplication in the
> > generated ofbiz-component.xml file.
> >
> > I already created an issue for that, see
> > https://issues.apache.org/jira/browse/OFBIZ-7785
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > [hidden email]> wrote:
> >
> > > Hi Pierre,
> > >
> > > Hmmm, that's actually a nice idea. I suggest however we avoid
> componentId
> > > and just apply the following to the variables:
> > >
> > > componentName: mandatory
> > > componentResourceName: optional, defaults to componentName
> > > webappName: optional, defaults to componentName
> > > basePermission: optional, defaults to OFBTOOLS (or whatever defaults
> > were)
> > >
> > > This way, You get a real nice and simple command for end-users to
> create
> > > new components while at the same time allowing more expressiveness.
> This
> > > becomes similar to the createTenant task which also has everything
> > optional
> > > except the tenantId and tenantName
> > >
> > > Taher Alkhateeb
> > >
> > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <[hidden email]
> >
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Currently our create component process (./gradlew createComponent) is
> > > error
> > > > prone.
> > > >
> > > > It requires 4 variables to successfully create a new component in the
> > > > hot-deploy folder to jumpstart development with a component skeleton.
> > > These
> > > > variables are:
> > > >
> > > >    - componentName
> > > >    - componentResourceName
> > > >    - webappName
> > > >    - basePermission
> > > >
> > > > I believe we should reduce the number of variables to just 1 variable
> > > (e.g.
> > > > componentId) to create consistency throughout the skeleton and its
> > > > associated datasets. The developer can, after a skeleton has been
> > built,
> > > > then apply any kind of changes according to his/her requirements an
> > > needs.
> > > >
> > > > What is your opinion on this?
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > >
> >
>

[taher]

By the way, this is a good example of the problems of interactive tasks. If
we create an interactive task for createComponent then we have to update
its implementation because it will break based on these new requirements.

So everytime we change something on which an interactive task depends, we
have to update that task as well. Usually interactive tasks have more
business logic for validation and hence are more brittle to such changes. I
know this is off topic but couldn't help notice it.

On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
[hidden email]> wrote:

> +1 to the idea, with defaults for optional resources (1 mandatory, 3
> optional).
>
> Wish: it would be nice to have more control on the component structure; for
> example create a component without a webapp, add a webapp to an existing
> component etc...
>
> Jacopo
>
> On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> [hidden email]> wrote:
>
> > Noted, thank you.
> >
> > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <[hidden email]>
> > wrote:
> >
> > > Hi Taher,
> > >
> > > OFBTOOLS is not required as it is already defined in the template to be
> > > included. When added in basePermission it leads to duplication in the
> > > generated ofbiz-component.xml file.
> > >
> > > I already created an issue for that, see
> > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > ORRTIZ.COM <http://www.orrtiz.com>
> > > OFBiz based solutions & services
> > >
> > > OFBiz Extensions Marketplace
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > [hidden email]> wrote:
> > >
> > > > Hi Pierre,
> > > >
> > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > componentId
> > > > and just apply the following to the variables:
> > > >
> > > > componentName: mandatory
> > > > componentResourceName: optional, defaults to componentName
> > > > webappName: optional, defaults to componentName
> > > > basePermission: optional, defaults to OFBTOOLS (or whatever defaults
> > > were)
> > > >
> > > > This way, You get a real nice and simple command for end-users to
> > create
> > > > new components while at the same time allowing more expressiveness.
> > This
> > > > becomes similar to the createTenant task which also has everything
> > > optional
> > > > except the tenantId and tenantName
> > > >
> > > > Taher Alkhateeb
> > > >
> > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Currently our create component process (./gradlew createComponent)
> is
> > > > error
> > > > > prone.
> > > > >
> > > > > It requires 4 variables to successfully create a new component in
> the
> > > > > hot-deploy folder to jumpstart development with a component
> skeleton.
> > > > These
> > > > > variables are:
> > > > >
> > > > >    - componentName
> > > > >    - componentResourceName
> > > > >    - webappName
> > > > >    - basePermission
> > > > >
> > > > > I believe we should reduce the number of variables to just 1
> variable
> > > > (e.g.
> > > > > componentId) to create consistency throughout the skeleton and its
> > > > > associated datasets. The developer can, after a skeleton has been
> > > built,
> > > > > then apply any kind of changes according to his/her requirements an
> > > > needs.
> > > > >
> > > > > What is your opinion on this?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > > OFBiz based solutions & services
> > > > >
> > > > > OFBiz Extensions Marketplace
> > > > > http://oem.ofbizci.net/oci-2/
> > > > >
> > > >
> > >
> >
>

[Pierre Smits]

Taher,

What you are saying is not off topic. Thus it is good to bring these to the
table. And they need to be addressed before a solution can gather consensus
and gets implemented.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 11:27 AM, Taher Alkhateeb <
[hidden email]> wrote:

> By the way, this is a good example of the problems of interactive tasks. If
> we create an interactive task for createComponent then we have to update
> its implementation because it will break based on these new requirements.
>
> So everytime we change something on which an interactive task depends, we
> have to update that task as well. Usually interactive tasks have more
> business logic for validation and hence are more brittle to such changes. I
> know this is off topic but couldn't help notice it.
>
> On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
> [hidden email]> wrote:
>
> > +1 to the idea, with defaults for optional resources (1 mandatory, 3
> > optional).
> >
> > Wish: it would be nice to have more control on the component structure;
> for
> > example create a component without a webapp, add a webapp to an existing
> > component etc...
> >
> > Jacopo
> >
> > On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> > [hidden email]> wrote:
> >
> > > Noted, thank you.
> > >
> > > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <[hidden email]
> >
> > > wrote:
> > >
> > > > Hi Taher,
> > > >
> > > > OFBTOOLS is not required as it is already defined in the template to
> be
> > > > included. When added in basePermission it leads to duplication in the
> > > > generated ofbiz-component.xml file.
> > > >
> > > > I already created an issue for that, see
> > > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > OFBiz based solutions & services
> > > >
> > > > OFBiz Extensions Marketplace
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > > [hidden email]> wrote:
> > > >
> > > > > Hi Pierre,
> > > > >
> > > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > > componentId
> > > > > and just apply the following to the variables:
> > > > >
> > > > > componentName: mandatory
> > > > > componentResourceName: optional, defaults to componentName
> > > > > webappName: optional, defaults to componentName
> > > > > basePermission: optional, defaults to OFBTOOLS (or whatever
> defaults
> > > > were)
> > > > >
> > > > > This way, You get a real nice and simple command for end-users to
> > > create
> > > > > new components while at the same time allowing more expressiveness.
> > > This
> > > > > becomes similar to the createTenant task which also has everything
> > > > optional
> > > > > except the tenantId and tenantName
> > > > >
> > > > > Taher Alkhateeb
> > > > >
> > > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> > [hidden email]
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Currently our create component process (./gradlew
> createComponent)
> > is
> > > > > error
> > > > > > prone.
> > > > > >
> > > > > > It requires 4 variables to successfully create a new component in
> > the
> > > > > > hot-deploy folder to jumpstart development with a component
> > skeleton.
> > > > > These
> > > > > > variables are:
> > > > > >
> > > > > >    - componentName
> > > > > >    - componentResourceName
> > > > > >    - webappName
> > > > > >    - basePermission
> > > > > >
> > > > > > I believe we should reduce the number of variables to just 1
> > variable
> > > > > (e.g.
> > > > > > componentId) to create consistency throughout the skeleton and
> its
> > > > > > associated datasets. The developer can, after a skeleton has been
> > > > built,
> > > > > > then apply any kind of changes according to his/her requirements
> an
> > > > > needs.
> > > > > >
> > > > > > What is your opinion on this?
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Pierre Smits
> > > > > >
> > > > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > > > OFBiz based solutions & services
> > > > > >
> > > > > > OFBiz Extensions Marketplace
> > > > > > http://oem.ofbizci.net/oci-2/
> > > > > >
> > > > >
> > > >
> > >
> >
>

[taher]

I know a little fast, but I have a patch that does the following:

componentName: mandatory
componentResourceName: optional, defaults to componentName
webappName: optional, defaults to componentName
basePermission: optional, defaults to ${componentName}_ADMIN

so the security permissions are OFBTOOLS followed by ${componentName}_ADMIN

Total size of new code? 9 lines :)

Whenever you folks want to I can push this to whatever JIRA requires it.

On Tue, Jul 19, 2016 at 12:33 PM, Pierre Smits <[hidden email]>
wrote:

> Taher,
>
> What you are saying is not off topic. Thus it is good to bring these to the
> table. And they need to be addressed before a solution can gather consensus
> and gets implemented.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 19, 2016 at 11:27 AM, Taher Alkhateeb <
> [hidden email]> wrote:
>
> > By the way, this is a good example of the problems of interactive tasks.
> If
> > we create an interactive task for createComponent then we have to update
> > its implementation because it will break based on these new requirements.
> >
> > So everytime we change something on which an interactive task depends, we
> > have to update that task as well. Usually interactive tasks have more
> > business logic for validation and hence are more brittle to such
> changes. I
> > know this is off topic but couldn't help notice it.
> >
> > On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
> > [hidden email]> wrote:
> >
> > > +1 to the idea, with defaults for optional resources (1 mandatory, 3
> > > optional).
> > >
> > > Wish: it would be nice to have more control on the component structure;
> > for
> > > example create a component without a webapp, add a webapp to an
> existing
> > > component etc...
> > >
> > > Jacopo
> > >
> > > On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> > > [hidden email]> wrote:
> > >
> > > > Noted, thank you.
> > > >
> > > > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Hi Taher,
> > > > >
> > > > > OFBTOOLS is not required as it is already defined in the template
> to
> > be
> > > > > included. When added in basePermission it leads to duplication in
> the
> > > > > generated ofbiz-component.xml file.
> > > > >
> > > > > I already created an issue for that, see
> > > > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > > OFBiz based solutions & services
> > > > >
> > > > > OFBiz Extensions Marketplace
> > > > > http://oem.ofbizci.net/oci-2/
> > > > >
> > > > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > > > [hidden email]> wrote:
> > > > >
> > > > > > Hi Pierre,
> > > > > >
> > > > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > > > componentId
> > > > > > and just apply the following to the variables:
> > > > > >
> > > > > > componentName: mandatory
> > > > > > componentResourceName: optional, defaults to componentName
> > > > > > webappName: optional, defaults to componentName
> > > > > > basePermission: optional, defaults to OFBTOOLS (or whatever
> > defaults
> > > > > were)
> > > > > >
> > > > > > This way, You get a real nice and simple command for end-users to
> > > > create
> > > > > > new components while at the same time allowing more
> expressiveness.
> > > > This
> > > > > > becomes similar to the createTenant task which also has
> everything
> > > > > optional
> > > > > > except the tenantId and tenantName
> > > > > >
> > > > > > Taher Alkhateeb
> > > > > >
> > > > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> > > [hidden email]
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Currently our create component process (./gradlew
> > createComponent)
> > > is
> > > > > > error
> > > > > > > prone.
> > > > > > >
> > > > > > > It requires 4 variables to successfully create a new component
> in
> > > the
> > > > > > > hot-deploy folder to jumpstart development with a component
> > > skeleton.
> > > > > > These
> > > > > > > variables are:
> > > > > > >
> > > > > > >    - componentName
> > > > > > >    - componentResourceName
> > > > > > >    - webappName
> > > > > > >    - basePermission
> > > > > > >
> > > > > > > I believe we should reduce the number of variables to just 1
> > > variable
> > > > > > (e.g.
> > > > > > > componentId) to create consistency throughout the skeleton and
> > its
> > > > > > > associated datasets. The developer can, after a skeleton has
> been
> > > > > built,
> > > > > > > then apply any kind of changes according to his/her
> requirements
> > an
> > > > > > needs.
> > > > > > >
> > > > > > > What is your opinion on this?
> > > > > > >
> > > > > > > Best regards,
> > > > > > >
> > > > > > > Pierre Smits
> > > > > > >
> > > > > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > > > > OFBiz based solutions & services
> > > > > > >
> > > > > > > OFBiz Extensions Marketplace
> > > > > > > http://oem.ofbizci.net/oci-2/
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Pierre Smits]

The basePermission parameters leads to a few things:
* being used in ofbiz-component.xml of the new component
* being used in the *SecurityPermissionSeedData.xml of the new component
* being used in the *SecurityGroupDemoData.xml of the new component

A specific security group is not set in the ofbiz-component.xml, where
OFBTOOLS is also defined.

For what it is worth, we (in our environment) differentiate between
componentID and componentName and have enhanced the ANT task also in such a
way that we can make new components tenant specific and/or component type
specific.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 19, 2016 at 11:47 AM, Taher Alkhateeb <
[hidden email]> wrote:

> I know a little fast, but I have a patch that does the following:
>
> componentName: mandatory
> componentResourceName: optional, defaults to componentName
> webappName: optional, defaults to componentName
> basePermission: optional, defaults to ${componentName}_ADMIN
>
> so the security permissions are OFBTOOLS followed by ${componentName}_ADMIN
>
> Total size of new code? 9 lines :)
>
> Whenever you folks want to I can push this to whatever JIRA requires it.
>
> On Tue, Jul 19, 2016 at 12:33 PM, Pierre Smits <[hidden email]>
> wrote:
>
> > Taher,
> >
> > What you are saying is not off topic. Thus it is good to bring these to
> the
> > table. And they need to be addressed before a solution can gather
> consensus
> > and gets implemented.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > ORRTIZ.COM <http://www.orrtiz.com>
> > OFBiz based solutions & services
> >
> > OFBiz Extensions Marketplace
> > http://oem.ofbizci.net/oci-2/
> >
> > On Tue, Jul 19, 2016 at 11:27 AM, Taher Alkhateeb <
> > [hidden email]> wrote:
> >
> > > By the way, this is a good example of the problems of interactive
> tasks.
> > If
> > > we create an interactive task for createComponent then we have to
> update
> > > its implementation because it will break based on these new
> requirements.
> > >
> > > So everytime we change something on which an interactive task depends,
> we
> > > have to update that task as well. Usually interactive tasks have more
> > > business logic for validation and hence are more brittle to such
> > changes. I
> > > know this is off topic but couldn't help notice it.
> > >
> > > On Tue, Jul 19, 2016 at 12:22 PM, Jacopo Cappellato <
> > > [hidden email]> wrote:
> > >
> > > > +1 to the idea, with defaults for optional resources (1 mandatory, 3
> > > > optional).
> > > >
> > > > Wish: it would be nice to have more control on the component
> structure;
> > > for
> > > > example create a component without a webapp, add a webapp to an
> > existing
> > > > component etc...
> > > >
> > > > Jacopo
> > > >
> > > > On Tue, Jul 19, 2016 at 11:15 AM, Taher Alkhateeb <
> > > > [hidden email]> wrote:
> > > >
> > > > > Noted, thank you.
> > > > >
> > > > > On Tue, Jul 19, 2016 at 12:09 PM, Pierre Smits <
> > [hidden email]
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Taher,
> > > > > >
> > > > > > OFBTOOLS is not required as it is already defined in the template
> > to
> > > be
> > > > > > included. When added in basePermission it leads to duplication in
> > the
> > > > > > generated ofbiz-component.xml file.
> > > > > >
> > > > > > I already created an issue for that, see
> > > > > > https://issues.apache.org/jira/browse/OFBIZ-7785
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Pierre Smits
> > > > > >
> > > > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > > > OFBiz based solutions & services
> > > > > >
> > > > > > OFBiz Extensions Marketplace
> > > > > > http://oem.ofbizci.net/oci-2/
> > > > > >
> > > > > > On Tue, Jul 19, 2016 at 11:04 AM, Taher Alkhateeb <
> > > > > > [hidden email]> wrote:
> > > > > >
> > > > > > > Hi Pierre,
> > > > > > >
> > > > > > > Hmmm, that's actually a nice idea. I suggest however we avoid
> > > > > componentId
> > > > > > > and just apply the following to the variables:
> > > > > > >
> > > > > > > componentName: mandatory
> > > > > > > componentResourceName: optional, defaults to componentName
> > > > > > > webappName: optional, defaults to componentName
> > > > > > > basePermission: optional, defaults to OFBTOOLS (or whatever
> > > defaults
> > > > > > were)
> > > > > > >
> > > > > > > This way, You get a real nice and simple command for end-users
> to
> > > > > create
> > > > > > > new components while at the same time allowing more
> > expressiveness.
> > > > > This
> > > > > > > becomes similar to the createTenant task which also has
> > everything
> > > > > > optional
> > > > > > > except the tenantId and tenantName
> > > > > > >
> > > > > > > Taher Alkhateeb
> > > > > > >
> > > > > > > On Tue, Jul 19, 2016 at 11:58 AM, Pierre Smits <
> > > > [hidden email]
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > Currently our create component process (./gradlew
> > > createComponent)
> > > > is
> > > > > > > error
> > > > > > > > prone.
> > > > > > > >
> > > > > > > > It requires 4 variables to successfully create a new
> component
> > in
> > > > the
> > > > > > > > hot-deploy folder to jumpstart development with a component
> > > > skeleton.
> > > > > > > These
> > > > > > > > variables are:
> > > > > > > >
> > > > > > > >    - componentName
> > > > > > > >    - componentResourceName
> > > > > > > >    - webappName
> > > > > > > >    - basePermission
> > > > > > > >
> > > > > > > > I believe we should reduce the number of variables to just 1
> > > > variable
> > > > > > > (e.g.
> > > > > > > > componentId) to create consistency throughout the skeleton
> and
> > > its
> > > > > > > > associated datasets. The developer can, after a skeleton has
> > been
> > > > > > built,
> > > > > > > > then apply any kind of changes according to his/her
> > requirements
> > > an
> > > > > > > needs.
> > > > > > > >
> > > > > > > > What is your opinion on this?
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > >
> > > > > > > > Pierre Smits
> > > > > > > >
> > > > > > > > ORRTIZ.COM <http://www.orrtiz.com>
> > > > > > > > OFBiz based solutions & services
> > > > > > > >
> > > > > > > > OFBiz Extensions Marketplace
> > > > > > > > http://oem.ofbizci.net/oci-2/
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Jacques Le Roux]

Le 26/07/2016 à 09:10, Pierre Smits a écrit :

> The basePermission parameters leads to a few things:
> * being used in ofbiz-component.xml of the new component
> * being used in the *SecurityPermissionSeedData.xml of the new component
> * being used in the *SecurityGroupDemoData.xml of the new component
>
> A specific security group is not set in the ofbiz-component.xml, where
> OFBTOOLS is also defined.
>
> For what it is worth, we (in our environment) differentiate between
> componentID and componentName and have enhanced the ANT task also in such a
> way that we can make new components tenant specific and/or component type
> specific.

What is the reason to differentiate componentID and componentName?

Jacques

[Pierre Smits]

For starters:

   - A componentId needs to be unique
   - A componentName need not be

as an example:
-PcomponentId=1 -PcomponentName=webshop
-PcomponentId=2 -PcomponentName="webshop

The componentName parameters is more for humans than for a software system.
It provides convenience. And has less restrictions regarding format, eg:

   - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" - is
   allowable.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
[hidden email]> wrote:

> Le 26/07/2016 à 09:10, Pierre Smits a écrit :
>
>> The basePermission parameters leads to a few things:
>> * being used in ofbiz-component.xml of the new component
>> * being used in the *SecurityPermissionSeedData.xml of the new component
>> * being used in the *SecurityGroupDemoData.xml of the new component
>>
>> A specific security group is not set in the ofbiz-component.xml, where
>> OFBTOOLS is also defined.
>>
>> For what it is worth, we (in our environment) differentiate between
>> componentID and componentName and have enhanced the ANT task also in such
>> a
>> way that we can make new components tenant specific and/or component type
>> specific.
>>
>
> What is the reason to differentiate componentID and componentName?
>
> Jacques
>
>

[taher]

The component name is unique because it creates a directory with that name.

On Tue, Jul 26, 2016 at 11:10 AM, Pierre Smits <[hidden email]>
wrote:

> For starters:
>
>    - A componentId needs to be unique
>    - A componentName need not be
>
> as an example:
> -PcomponentId=1 -PcomponentName=webshop
> -PcomponentId=2 -PcomponentName="webshop
>
> The componentName parameters is more for humans than for a software system.
> It provides convenience. And has less restrictions regarding format, eg:
>
>    - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" - is
>    allowable.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Le 26/07/2016 à 09:10, Pierre Smits a écrit :
> >
> >> The basePermission parameters leads to a few things:
> >> * being used in ofbiz-component.xml of the new component
> >> * being used in the *SecurityPermissionSeedData.xml of the new component
> >> * being used in the *SecurityGroupDemoData.xml of the new component
> >>
> >> A specific security group is not set in the ofbiz-component.xml, where
> >> OFBTOOLS is also defined.
> >>
> >> For what it is worth, we (in our environment) differentiate between
> >> componentID and componentName and have enhanced the ANT task also in
> such
> >> a
> >> way that we can make new components tenant specific and/or component
> type
> >> specific.
> >>
> >
> > What is the reason to differentiate componentID and componentName?
> >
> > Jacques
> >
> >
>

[Jacques Le Roux]

Pierre all that is obvious to me, I expected a more argumented answer :)
Maybe I did not well phrase my sentence, here is a new try: I still don't see what prevent componentId and componentName to be same

Thanks

Jacques

Le 26/07/2016 à 10:10, Pierre Smits a écrit :

> For starters:
>
>     - A componentId needs to be unique
>     - A componentName need not be
>
> as an example:
> -PcomponentId=1 -PcomponentName=webshop
> -PcomponentId=2 -PcomponentName="webshop
>
> The componentName parameters is more for humans than for a software system.
> It provides convenience. And has less restrictions regarding format, eg:
>
>     - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" - is
>     allowable.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 26/07/2016 à 09:10, Pierre Smits a écrit :
>>
>>> The basePermission parameters leads to a few things:
>>> * being used in ofbiz-component.xml of the new component
>>> * being used in the *SecurityPermissionSeedData.xml of the new component
>>> * being used in the *SecurityGroupDemoData.xml of the new component
>>>
>>> A specific security group is not set in the ofbiz-component.xml, where
>>> OFBTOOLS is also defined.
>>>
>>> For what it is worth, we (in our environment) differentiate between
>>> componentID and componentName and have enhanced the ANT task also in such
>>> a
>>> way that we can make new components tenant specific and/or component type
>>> specific.
>>>
>> What is the reason to differentiate componentID and componentName?
>>
>> Jacques
>>
>>

[Pierre Smits]

Jacques,

Of course there is nothing to prevent the two parameters to be the same.
But is that not in the domain of the adopter? And in relation to his
policies and procedures?

In my viewpoint, this project should not limit the flexibility of the
product (for any - potential - adopter) just to cater to the viewpoint of a
(few) contributor(s). It is technically feasible (to differentiate between
the two parameters) and limiting this flexibility in the product will lead
to adopters having to spend more effort to make it work for them
(especially when taking into consideration the existing adopters with their
deviations from 'default' OFBiz).

If that can be avoided with a few more considerations up front, I would say
it increases the appeal of the product (and the project,  for - potential -
contributors to participate in.).

If that doesn't provide you sufficient arguments, please elaborate more.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Tue, Jul 26, 2016 at 11:17 AM, Jacques Le Roux <
[hidden email]> wrote:

> Pierre all that is obvious to me, I expected a more argumented answer :)
> Maybe I did not well phrase my sentence, here is a new try: I still don't
> see what prevent componentId and componentName to be same
>
> Thanks
>
> Jacques
>
> Le 26/07/2016 à 10:10, Pierre Smits a écrit :
>
>> For starters:
>>
>>     - A componentId needs to be unique
>>     - A componentName need not be
>>
>> as an example:
>> -PcomponentId=1 -PcomponentName=webshop
>> -PcomponentId=2 -PcomponentName="webshop
>>
>> The componentName parameters is more for humans than for a software
>> system.
>> It provides convenience. And has less restrictions regarding format, eg:
>>
>>     - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" - is
>>     allowable.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Le 26/07/2016 à 09:10, Pierre Smits a écrit :
>>>
>>> The basePermission parameters leads to a few things:
>>>> * being used in ofbiz-component.xml of the new component
>>>> * being used in the *SecurityPermissionSeedData.xml of the new component
>>>> * being used in the *SecurityGroupDemoData.xml of the new component
>>>>
>>>> A specific security group is not set in the ofbiz-component.xml, where
>>>> OFBTOOLS is also defined.
>>>>
>>>> For what it is worth, we (in our environment) differentiate between
>>>> componentID and componentName and have enhanced the ANT task also in
>>>> such
>>>> a
>>>> way that we can make new components tenant specific and/or component
>>>> type
>>>> specific.
>>>>
>>>> What is the reason to differentiate componentID and componentName?
>>>
>>> Jacques
>>>
>>>
>>>
>

[Jacques Le Roux]

That's a good answer for me

Thanks

Jacques


Le 26/07/2016 à 11:36, Pierre Smits a écrit :

> Jacques,
>
> Of course there is nothing to prevent the two parameters to be the same.
> But is that not in the domain of the adopter? And in relation to his
> policies and procedures?
>
> In my viewpoint, this project should not limit the flexibility of the
> product (for any - potential - adopter) just to cater to the viewpoint of a
> (few) contributor(s). It is technically feasible (to differentiate between
> the two parameters) and limiting this flexibility in the product will lead
> to adopters having to spend more effort to make it work for them
> (especially when taking into consideration the existing adopters with their
> deviations from 'default' OFBiz).
>
> If that can be avoided with a few more considerations up front, I would say
> it increases the appeal of the product (and the project,  for - potential -
> contributors to participate in.).
>
> If that doesn't provide you sufficient arguments, please elaborate more.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 26, 2016 at 11:17 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Pierre all that is obvious to me, I expected a more argumented answer :)
>> Maybe I did not well phrase my sentence, here is a new try: I still don't
>> see what prevent componentId and componentName to be same
>>
>> Thanks
>>
>> Jacques
>>
>> Le 26/07/2016 à 10:10, Pierre Smits a écrit :
>>
>>> For starters:
>>>
>>>      - A componentId needs to be unique
>>>      - A componentName need not be
>>>
>>> as an example:
>>> -PcomponentId=1 -PcomponentName=webshop
>>> -PcomponentId=2 -PcomponentName="webshop
>>>
>>> The componentName parameters is more for humans than for a software
>>> system.
>>> It provides convenience. And has less restrictions regarding format, eg:
>>>
>>>      - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" - is
>>>      allowable.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> ORRTIZ.COM <http://www.orrtiz.com>
>>> OFBiz based solutions & services
>>>
>>> OFBiz Extensions Marketplace
>>> http://oem.ofbizci.net/oci-2/
>>>
>>> On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> Le 26/07/2016 à 09:10, Pierre Smits a écrit :
>>>> The basePermission parameters leads to a few things:
>>>>> * being used in ofbiz-component.xml of the new component
>>>>> * being used in the *SecurityPermissionSeedData.xml of the new component
>>>>> * being used in the *SecurityGroupDemoData.xml of the new component
>>>>>
>>>>> A specific security group is not set in the ofbiz-component.xml, where
>>>>> OFBTOOLS is also defined.
>>>>>
>>>>> For what it is worth, we (in our environment) differentiate between
>>>>> componentID and componentName and have enhanced the ANT task also in
>>>>> such
>>>>> a
>>>>> way that we can make new components tenant specific and/or component
>>>>> type
>>>>> specific.
>>>>>
>>>>> What is the reason to differentiate componentID and componentName?
>>>> Jacques
>>>>
>>>>
>>>>

[taher]

Actually I didn't understand! What is the specific difference between
componentName and componentId, what purpose do they exactly serve? How
would differentiation add value?

On Tue, Jul 26, 2016 at 12:48 PM, Jacques Le Roux <
[hidden email]> wrote:

> That's a good answer for me
>
> Thanks
>
> Jacques
>
>
>
> Le 26/07/2016 à 11:36, Pierre Smits a écrit :
>
>> Jacques,
>>
>> Of course there is nothing to prevent the two parameters to be the same.
>> But is that not in the domain of the adopter? And in relation to his
>> policies and procedures?
>>
>> In my viewpoint, this project should not limit the flexibility of the
>> product (for any - potential - adopter) just to cater to the viewpoint of
>> a
>> (few) contributor(s). It is technically feasible (to differentiate between
>> the two parameters) and limiting this flexibility in the product will lead
>> to adopters having to spend more effort to make it work for them
>> (especially when taking into consideration the existing adopters with
>> their
>> deviations from 'default' OFBiz).
>>
>> If that can be avoided with a few more considerations up front, I would
>> say
>> it increases the appeal of the product (and the project,  for - potential
>> -
>> contributors to participate in.).
>>
>> If that doesn't provide you sufficient arguments, please elaborate more.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM <http://www.orrtiz.com>
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Tue, Jul 26, 2016 at 11:17 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Pierre all that is obvious to me, I expected a more argumented answer :)
>>> Maybe I did not well phrase my sentence, here is a new try: I still don't
>>> see what prevent componentId and componentName to be same
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>> Le 26/07/2016 à 10:10, Pierre Smits a écrit :
>>>
>>> For starters:
>>>>
>>>>      - A componentId needs to be unique
>>>>      - A componentName need not be
>>>>
>>>> as an example:
>>>> -PcomponentId=1 -PcomponentName=webshop
>>>> -PcomponentId=2 -PcomponentName="webshop
>>>>
>>>> The componentName parameters is more for humans than for a software
>>>> system.
>>>> It provides convenience. And has less restrictions regarding format, eg:
>>>>
>>>>      - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" -
>>>> is
>>>>      allowable.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> ORRTIZ.COM <http://www.orrtiz.com>
>>>> OFBiz based solutions & services
>>>>
>>>> OFBiz Extensions Marketplace
>>>> http://oem.ofbizci.net/oci-2/
>>>>
>>>> On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> Le 26/07/2016 à 09:10, Pierre Smits a écrit :
>>>>
>>>>> The basePermission parameters leads to a few things:
>>>>>
>>>>>> * being used in ofbiz-component.xml of the new component
>>>>>> * being used in the *SecurityPermissionSeedData.xml of the new
>>>>>> component
>>>>>> * being used in the *SecurityGroupDemoData.xml of the new component
>>>>>>
>>>>>> A specific security group is not set in the ofbiz-component.xml, where
>>>>>> OFBTOOLS is also defined.
>>>>>>
>>>>>> For what it is worth, we (in our environment) differentiate between
>>>>>> componentID and componentName and have enhanced the ANT task also in
>>>>>> such
>>>>>> a
>>>>>> way that we can make new components tenant specific and/or component
>>>>>> type
>>>>>> specific.
>>>>>>
>>>>>> What is the reason to differentiate componentID and componentName?
>>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>>
>

[Scott Gray-3]

I'm confused Pierre, didn't you start this thread with a simple and
straightforward solution to the createComponent task?  Where did it diverge
so that you now appear to be arguing against your original proposal?  I'm
sorry if I missed the divergence but I haven't been able to spot it.

Regards
Scott

On 26 July 2016 at 21:36, Pierre Smits <[hidden email]> wrote:

> Jacques,
>
> Of course there is nothing to prevent the two parameters to be the same.
> But is that not in the domain of the adopter? And in relation to his
> policies and procedures?
>
> In my viewpoint, this project should not limit the flexibility of the
> product (for any - potential - adopter) just to cater to the viewpoint of a
> (few) contributor(s). It is technically feasible (to differentiate between
> the two parameters) and limiting this flexibility in the product will lead
> to adopters having to spend more effort to make it work for them
> (especially when taking into consideration the existing adopters with their
> deviations from 'default' OFBiz).
>
> If that can be avoided with a few more considerations up front, I would say
> it increases the appeal of the product (and the project,  for - potential -
> contributors to participate in.).
>
> If that doesn't provide you sufficient arguments, please elaborate more.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Jul 26, 2016 at 11:17 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Pierre all that is obvious to me, I expected a more argumented answer :)
> > Maybe I did not well phrase my sentence, here is a new try: I still don't
> > see what prevent componentId and componentName to be same
> >
> > Thanks
> >
> > Jacques
> >
> > Le 26/07/2016 à 10:10, Pierre Smits a écrit :
> >
> >> For starters:
> >>
> >>     - A componentId needs to be unique
> >>     - A componentName need not be
> >>
> >> as an example:
> >> -PcomponentId=1 -PcomponentName=webshop
> >> -PcomponentId=2 -PcomponentName="webshop
> >>
> >> The componentName parameters is more for humans than for a software
> >> system.
> >> It provides convenience. And has less restrictions regarding format, eg:
> >>
> >>     - -PcomponentName="This is a a large DESCRIPTIVE piece of T3xt" - is
> >>     allowable.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> ORRTIZ.COM <http://www.orrtiz.com>
> >> OFBiz based solutions & services
> >>
> >> OFBiz Extensions Marketplace
> >> http://oem.ofbizci.net/oci-2/
> >>
> >> On Tue, Jul 26, 2016 at 9:57 AM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >> Le 26/07/2016 à 09:10, Pierre Smits a écrit :
> >>>
> >>> The basePermission parameters leads to a few things:
> >>>> * being used in ofbiz-component.xml of the new component
> >>>> * being used in the *SecurityPermissionSeedData.xml of the new
> component
> >>>> * being used in the *SecurityGroupDemoData.xml of the new component
> >>>>
> >>>> A specific security group is not set in the ofbiz-component.xml, where
> >>>> OFBTOOLS is also defined.
> >>>>
> >>>> For what it is worth, we (in our environment) differentiate between
> >>>> componentID and componentName and have enhanced the ANT task also in
> >>>> such
> >>>> a
> >>>> way that we can make new components tenant specific and/or component
> >>>> type
> >>>> specific.
> >>>>
> >>>> What is the reason to differentiate componentID and componentName?
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >
>

[Jacopo Cappellato-5]

On Tue, Jul 26, 2016 at 11:36 AM, Pierre Smits <[hidden email]>
wrote:

> ...
> In my viewpoint, this project should not limit the flexibility of the
> product (for any - potential - adopter) just to cater to the viewpoint of a
> (few) contributor(s).


It is always difficult to foresee the impact of such decisions and for
every feature/solution some decisions that influence its flexibility vs
complexity vs usability vs configurability vs customizability are
"hardcoded" in the implementation.
As a general rule of thumb, when in doubt or when there are different
opinions, I would recommend to implement a neat and simple solution, even
if it may not cover all the possible use cases; community feedback will
then help to identify, among all the features asked by the adopters, the
most popular ones that will be the candidate for inspiring enhancements and
refinement of the core functionality.

Jacopo