NP.
This is a new idea for OfBiz.
Some Apache examples
http://db.apache.org/ where Derby is a sub-project with some others.
http://xmlgraphics.apache.org/ is an example where the skill sets and
interests of the sub-projects are very different from the core
http://portals.apache.org/ is more of a layered approach similar to
OFBiz where Jetspeed depends on Pluto and the Applications project
depends on Jetspeed.
http://hadoop.apache.org/ has a number of sub-projects and has spawned a
number of top-level projects that could be sub-projects but they have
sufficient communities to run their own and are able to use Hadoop "as
released".
There are probably more.
Ron
On 28/11/2014 11:06 AM, gil portenseigne wrote:
Oh, sorry i did miss a big point :)
I miss-interpreted Adrian proposal on "seperate project", not enough
self-explanatory for me I guess :).
Gil
Le 28/11/2014 17:01, Ron Wheeler a écrit :
The components not supported as part of the core and framework would
not leave Apache.
They become separate sub-projects under OFBiz so that they stay in
the community but are released and supported separately so that there
is more transparency about their state.
The release of new core and framework versions gets easier.
The implied warranties get clearer and the sub-communities supporting
each of the non-core components are :
-easier to identify
- free to set their own roadmaps based on the needs and the resources
- easier to join since you only need to learn a small set of code in
order to contribute
- do not affect the core and framework code, roadmap or release plans
except when they request extensions to the core or framework through
JIRA issues.
The core and framework team will not have to worry about the side
components unless they belong to the sub-project and can release with
a full warranty.
Ron
On 28/11/2014 10:30 AM, gil portenseigne wrote:
First I might be a bit confuse in this email, sorry for that, quite
ideas came up while writing it, some organization missing.
Le 28/11/2014 14:31, Ron Wheeler a écrit :
What is the downside if the non-core components are released on
their own with a clear set of documentation that describes the
state of the component?
I guess there is none at first glance, it's quite the same idea :
- A big release with core components active, and non-core component
unactive (with included documentations)
A monolythique one, all-included...
- A Core release, first with then optional non-core component
releases with their own documentations
A core with packages. Less heavy but more actions... not a problem
The things that make me wonder, and that's we try to achieve for
several years with an extension management tool, are all the
deviance possible without the control of such an Apache project.
It is Out of Apache ! The component community can build their own
component at the speed they need (often dependant on a personal
project), without the quality control. It's good for this side
community, we are already doing that in our way. But can lead to a
branch component, which can't be contributed anymore to OFBiz if
needed (for any reasons I guess).
Why not stick with Apache OFBiz in contributing more, into
desactivated non-core component using the side community
advancement, and managing to level up these non-core quality too
make them stable and reliable into Apache OFBiz.
Specifics devs that can't be contributed into OFBiz, will remain as
extension into the side community.
If side community meets some deviance in his evolution, not
following Apache OFBiz way, it must not have consequences like
removing these non-core component from trunk or branches.
That's why i like the idea to have in Apache OFBiz, release with
unactive components (which can always be used and follow the Ofbiz
way), and then everyone have the opportunity to offer other
community components to replace unactive one, or to add to the core.
Then some questions remains :
- How can user be informed of such side communities from the OFBiz
official site ? Is that possible ?
- We tried to introduce a new tool to manage extension (which could
be a solution for the first question, becoming a tool of indexation
) to serve this kind of purpose, but their wasn't much reactions to
it. Cf : http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
Gil
My feeling is that it is better to release a clean core and
framework where ALL component are "warranteed" by the team to be
tested and supported.
Components that are not part of the core would be released on their
own with the warranty and support specified on an individual basis.
At least the user community would know where it stands if it
depends a non-core component to run their business.
I think this is preferable than releasing a big conglomeration of
working and non-working software that the user has to sort through
to figure out if they can make a usable OFBiz.
It also simplifies the release process for the core and framework.
Ron
On 28/11/2014 7:18 AM, gil portenseigne wrote:
Hello all !
I followed the discussion, a bit late :
Le 28/11/2014 11:24, Jacques Le Roux a écrit :
Afterthought: we agreed about having the same setting in both the
releases branches and the trunk. So if we disable a component in
the releases branches it will be also in the trunk.
Then, even we enable tests, we will not be aware of UI related
issues and globally all those which are no covered by tests.
Apart if an users enable the component and report issues.
This might be a compromise, but we need our users to be aware of.
So they will need to be warned in the download page IMO.
I think it's a good compromise, warning is needed to ensure that
user is aware or possible disfunctionment within these components.
No tricks needed anymore to import components from trunk. Good
enough for me.
My opinion is that OOTB functionnalities are usable but rarely
sufficient for End-User, advanced skills are needed in each
project to make OFBiz fit the needs. So i guess there is no harm
to let inactive (uncomplete or so) component at disposal for user
who might need them.
Also if you remember this thread started with my idea of creating
a wiki page to explain to our users the alternative strategy of
using release branches rather than released packages.
I'd like to have a direct link to this wiki page from the
download page. This link name could be simply "alternative
strategy". What do you think?
Using the same method, i like the idea.
Gil
I will stop this thread here and will create a new thread to
discuss the modality of putting back the specialpurpose
components in the R13.07 branch.
Jacques
Le 27/11/2014 23:38, Jacques Le Roux a écrit :
That sounds like a good enough solution to me
Jacques
Le 27/11/2014 19:41, Jacopo Cappellato a écrit :
This is a good point. We could find a way to programmatically
enable/disable the components just for the test run:
./ant -Denable-all=true clean-all load-demo run-tests
but this is just an idea; we could figure out the best way to go.
Jacopo
On Nov 27, 2014, at 7:14 PM, Adrian Crum
<adrian.c...@sandglass-software.com> wrote:
Be aware that disabling a component does two things:
1. Speeds up unit tests because the disabled component is
excluded from them.
2. Increases the chance of regressions because the disabled
component is not being tested.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 11/27/2014 5:41 PM, Jacopo Cappellato wrote:
On Nov 27, 2014, at 6:25 PM, Jacques Le Roux
<jacques.le.r...@les7arts.com> wrote:
Yes, so we need to define which are those components. So 3
points, which should be discussed separately it seems, not
sure of the order yet but probably this one
1) Components to move to Attic. They will be freezed but
still available in this state in Attic (in other words
slowly dying)
2) Components to disable. They will be maintained, but OOTB
will not interfere with other components (applications or
other specialpurpose)
3) Components to keep enabled. They must be maintained and
have no interactions with other components
Components enabled and disabled must be maintained in the
same way: it is not that a group is more important than the
other.
Also, disabling a component doesn't mean that it will not go
in a release: we could have disabled components in releases
and enabled components excluded from a release or vice versa.
For the point 2 we need to clarify if it could applies to
trunk also. I'd now tend to avoid differences between trunk
and branch releases, at the functionality or other levels.
I agree that the same settings should be maintained in the
trunk and in the release branches.
Jacopo
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
