specialpurpose in R13.07 demo

[Ron Wheeler]

On 24/10/2014 3:58 AM, Jacques Le Roux wrote:

>
> Le 24/10/2014 00:02, Ron Wheeler a écrit :
>> On 23/10/2014 11:33 AM, Jacques Le Roux wrote:
>>>
>>> Le 23/10/2014 17:11, Ron Wheeler a écrit :
>>>> On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
>>>>>
>>>>> Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
>>>>>> On Oct 23, 2014, at 2:07 PM, Jacques Le Roux
>>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>>> I agree about the idea, but this applies only to releases or
>>>>>>> checked out code. Because there are no ways for users to
>>>>>>> enable/disable a component in demos, moreover demos are shared.
>>>>>> Could you please explain the above sentence? I don't understand
>>>>>> the meaning of it.
>>>>>
>>>>> Your idea of disabling some specialpurpose component can't be
>>>>> applied in R13.07 demo until we decide which component should be
>>>>> disabled in trunk.
>>>>> In the meantime we should keep the current state (ie all
>>>>> specialpurpose components present in trunk should be available in
>>>>> R13.07 demo)
>>>>
>>>> If they are in the demo they should be in the release.
>>>
>>> Actually the specialpurpose components are in the R13.07 demos
>>> because they can be there. But they are not maintained in the R13.07
>>> branch (but ecommerce) only in trunk.
>>>
>>>> As you can guess, I am troubled about the relation between releases
>>>> and the trunk and demos in OFBiz.
>>>
>>> Would you prefer to not have the specialpurpose components in R13.07
>>> demo?
>>
>> If they are not in the 13.07.01 release it creates a bit of a
>> mismatch between the demo and what you actually get.
>> Otherwise I would have no problem.
>
> It's also Jacopo's opinion, I don't know  if it's for the same reason.
> My proposed alternative is to keep only the ones which will be enabled
> in the trunk and explain somewhere (on the site main page?) why we do
> that and how to do the same using svn external or direct check out
> from trunk.
> The idea is it's a bit didactic on how to use the specialpurpose
> components in future releases. Except if we change our POV and keep
> the enabled ones in releases in future, which could be even simpler...
>

Is there an architectural overview describing the relationship between
the core functionality and the "supported" components?
Is there a difference between "available" and "enabled" that would be
clear to a new user?

I don't understand the technical details but I gather that there is a
potential for conflict between the components.
Has there been any guidelines about how to describe the conflict issue
to a system administrator so that modules are installed in the "right"
sequence to end up with a working system?
Has there been any discussion about how developers should construct
components so that their potential for interference is reduced and is
done in a consistent way.
Are there hooks that allow administrators to configure sets of
components to work the way that they should or to allow developers of
components to write components that interact with the core functionality
in a safe way? For example, a way to allow a system administrator to
chose between 2 data entry screens depending on what data needs to be
collected( if you enable component B, then you need to use order-entry
screen "B" rather than the core screen and if you do, the core order
processing will still work where it does not require or track the extra
data that screen "B" collects .


Ron

> I guess at some point the disabled specialpurpose components in trunk
> will end in Attic.
>
> Jacques
>
>>
>> Ron
>>
>>>
>>>> It is a bit odd and certainly goes against most product release
>>>> strategies wherein the current release is the recommended download
>>>> and carries whatever warranty that the project offers in terms of
>>>> testing and rapidity of bug fixes and the trunk is usually called
>>>> something that includes"nightly build" and "unstable" in the name
>>>> and comes with no warranty and a warning about using it at your own
>>>> risk.
>>>>
>>>> Demos should be of the latest release and should be stable and have
>>>> a fixed functionality that can be documented in the wiki and
>>>> marketing pages.
>>>
>>> They are, just that they use the branch instead of the packaged
>>> releases.  For R13.07 (current stable) there is an exception,
>>> because I thought it was better to have the specialpurpose
>>> components available. This is what Jacopo contests
>>>
>>>> It could be maintained by the documentation team once it is set up
>>>> since it should not require any technical skills to keep working
>>>> and fed with demo data.
>>>>
>>>>
>>>> If the developers need a test site based on the nightly build, they
>>>> should be free to set up as many combinations of configurations as
>>>> they require and can support  to be sure that the trunk still works
>>>> but this should not be the public demo or even be called a "demo".
>>>
>>> It's also, there are no official mention of the trunk demo, it's
>>> only a developers thing.
>>>
>>>>
>>>> Of course, this only works if a release is actually a Release and
>>>> the team stands behind it and uses it when establishing new customers.
>>>
>>> We have no customers, only users
>>>
>>> Jacques
>>>
>>>>
>>>> Does anyone have an opinion about the gap between 13.07.01 and what
>>>> the main SI companies are getting from using the trunk instead.
>>>> Would a monthly release pattern reduce this gap to a point where it
>>>> would be possible to use the official Release as the actual release?
>>>>
>>>>>
>>>>> I hope it's more clear
>>>>>
>>>>> Jacques
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Ron Wheeler]

On 24/10/2014 6:52 AM, Jacopo Cappellato wrote:
> On Oct 24, 2014, at 9:58 AM, Jacques Le Roux <[hidden email]> wrote:
>
>> I guess at some point the disabled specialpurpose components in trunk will end in Attic.
> Not necessarily: a disabled component could be a specialized version (e.g. for a specific industry or for a specific payment processor) of some of the application components and could be actively maintained; in this case it would make sense to disable it by default (because by default OFBiz should be as generic as possible) but still keep it in the trunk (and possibly in some releases, e.g. ofbiz-specialpurpose-13.07.03.zip).
>
> Jacopo
>
>
This is another area where sub-projects would help.
The software would be maintained in its own repo and would be supported
by an identifiable team that actually cared about it and would be
responsible for building the community to support that function.
There would be someone (or some people) able to say if it was going to
be ported to the latest release and bugs backported to previous releases.
If that sub-project died, it would be clear and everyone would know that
it was not going to be available as part of future OFBiz releases unless
some group took charge of the sub-project and did the work.

This structure would help everyone and increase the transparency around
the management of components.

Ron

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

Not sure I get to weigh in, but I saw and looked at lots of the special stuff in 12.04.
When I got 13.07 and did not see it, I was confused.

I still have not got over to SVN to see if I can download them.
I was just trying to see if an issue that was reported in pos happened to me, and was surprised to see it no longer in the project.

I think a demo should have as bullet proof code as possible, so removing stuff that can cause issues makes sense.

I think if I pull 13.07 from svn I should get all the code good or bad, and be able to enable it pretty easy if it is off because of possible conflicts.

Just from a not savvy point of view.

[Jacques Le Roux]

Le 24/10/2014 16:14, Ron Wheeler a écrit :

> On 24/10/2014 3:58 AM, Jacques Le Roux wrote:
>>
>> Le 24/10/2014 00:02, Ron Wheeler a écrit :
>>> On 23/10/2014 11:33 AM, Jacques Le Roux wrote:
>>>>
>>>> Le 23/10/2014 17:11, Ron Wheeler a écrit :
>>>>> On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
>>>>>>
>>>>>> Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
>>>>>>> On Oct 23, 2014, at 2:07 PM, Jacques Le Roux <[hidden email]> wrote:
>>>>>>>
>>>>>>>> I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a
>>>>>>>> component in demos, moreover demos are shared.
>>>>>>> Could you please explain the above sentence? I don't understand the meaning of it.
>>>>>>
>>>>>> Your idea of disabling some specialpurpose component can't be applied in R13.07 demo until we decide which component should be disabled in trunk.
>>>>>> In the meantime we should keep the current state (ie all specialpurpose components present in trunk should be available in R13.07 demo)
>>>>>
>>>>> If they are in the demo they should be in the release.
>>>>
>>>> Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
>>>> ecommerce) only in trunk.
>>>>
>>>>> As you can guess, I am troubled about the relation between releases and the trunk and demos in OFBiz.
>>>>
>>>> Would you prefer to not have the specialpurpose components in R13.07 demo?
>>>
>>> If they are not in the 13.07.01 release it creates a bit of a mismatch between the demo and what you actually get.
>>> Otherwise I would have no problem.
>>
>> It's also Jacopo's opinion, I don't know  if it's for the same reason.
>> My proposed alternative is to keep only the ones which will be enabled in the trunk and explain somewhere (on the site main page?) why we do that
>> and how to do the same using svn external or direct check out from trunk.
>> The idea is it's a bit didactic on how to use the specialpurpose components in future releases. Except if we change our POV and keep the enabled
>> ones in releases in future, which could be even simpler...
>>
>
> Is there an architectural overview describing the relationship between the core functionality and the "supported" components?

The best we have is this https://cwiki.apache.org/confluence/display/OFBTECH/Component+and+Component+Set+Dependencies

> Is there a difference between "available" and "enabled" that would be clear to a new user?

Available in releases would be the components enabled in trunk.

> I don't understand the technical details but I gather that there is a potential for conflict between the components.
> Has there been any guidelines about how to describe the conflict issue to a system administrator so that modules are installed in the "right"
> sequence to end up with a working system?

See above, this might need update

> Has there been any discussion about how developers should construct components so that their potential for interference is reduced and is done in a
> consistent way.

There are many in MLs history. By and large, there can be dependencies between components of the same levels. You can't build an ERP, where things are
integrated, else.
Then, the bottom level being framework, then applications, then specialpurpose and finally hot-deploy, there should not be dependencies from a lower
level component to a higher level one.

> Are there hooks that allow administrators to configure sets of components to work the way that they should or to allow developers of components to
> write components that interact with the core functionality in a safe way?

One of the most important and interesting thing in OFBiz is the possibility for a functional component (ie the framework level does not count here) to
override things done at a lower level. This is how hot-deploy works. You can override things from applications level in hot-deploy. I say things
because it concerns most artefacts.

> For example, a way to allow a system administrator to chose between 2 data entry screens depending on what data needs to be collected( if you enable
> component B, then you need to use order-entry screen "B" rather than the core screen and if you do, the core order processing will still work where
> it does not require or track the extra data that screen "B" collects .

This is certainly doable but would need some code glue, ie it's not available OOTB.
Also I'm not sure that the component concept is well adapated here, since you speak about screen. The component is not an artefact in the sense of
OFBiz, rather a container.
https://demo-trunk-ofbiz.apache.org/webtools/control/ViewComponents
https://demo-trunk-ofbiz.apache.org/webtools/control/ArtifactInfo (be patient this takes much resources)

Jacques

>
>
> Ron
>
>> I guess at some point the disabled specialpurpose components in trunk will end in Attic.
>>
>> Jacques
>>
>>>
>>> Ron
>>>
>>>>
>>>>> It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries
>>>>> whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that
>>>>> includes"nightly build" and "unstable" in the name and comes with no warranty and a warning about using it at your own risk.
>>>>>
>>>>> Demos should be of the latest release and should be stable and have a fixed functionality that can be documented in the wiki and marketing pages.
>>>>
>>>> They are, just that they use the branch instead of the packaged releases.  For R13.07 (current stable) there is an exception, because I thought
>>>> it was better to have the specialpurpose components available. This is what Jacopo contests
>>>>
>>>>> It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with
>>>>> demo data.
>>>>>
>>>>>
>>>>> If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they
>>>>> require and can support  to be sure that the trunk still works but this should not be the public demo or even be called a "demo".
>>>>
>>>> It's also, there are no official mention of the trunk demo, it's only a developers thing.
>>>>
>>>>>
>>>>> Of course, this only works if a release is actually a Release and the team stands behind it and uses it when establishing new customers.
>>>>
>>>> We have no customers, only users
>>>>
>>>> Jacques
>>>>
>>>>>
>>>>> Does anyone have an opinion about the gap between 13.07.01 and what the main SI companies are getting from using the trunk instead.
>>>>> Would a monthly release pattern reduce this gap to a point where it would be possible to use the official Release as the actual release?
>>>>>
>>>>>>
>>>>>> I hope it's more clear
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>