An issue we have with Buildbot when not using externals is how to load the
default data
This: Task 'loadDefault' not found in root project 'build'.
The root is, of course,
http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/trunk
There are maybe possibilities in BuildBot or with Gradle but enough for me for
today...
Jacques
Le 12/02/2017 à 20:05, Jacques Le Roux a écrit :
Can we focus on the questions please?
Jacques
Le 12/02/2017 à 18:52, Taher Alkhateeb a écrit :
It's confusing to have multiple threads just because your email client is
mixing things. We already participated in the other thread.
On Feb 12, 2017 8:50 PM, "Jacques Le Roux" <jacques.le.r...@les7arts.com>
wrote:
In (my) Thunderbird it was buried in the previous thread so I "created a
clean new thread to have it more prominent."
We should rather focus on the questions...
Jacques
Le 12/02/2017 à 18:42, Taher Alkhateeb a écrit :
Why did you start a new thread? What's wrong with the other thread?
On Sun, Feb 12, 2017 at 3:55 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Thanks Taher,
I create a clean new thread to have it more prominent.
This is really what needs to be discussed indeed.
Are we sure that's what we want for plugins?
Will they not be disregarded by committers?
Will plugins follow the framework trend?
This is a very important community decision.
I hope everybody will (try to) understand the consequences and
participate
to this discussion, before it will be too late...
Jacques
Le 12/02/2017 à 13:32, Taher Alkhateeb a écrit :
Let's take a look at the big picture for a moment before we decide. We
have
broken OFBiz into essentially two products: framework and plugins.
Why did we break it up? Why did we go through the trouble of creating
two
different repositories? I hope the answer is something like "because it
is
too big" or "because it carried a lot of non-essential functionality
around"
So breaking up the project brings the advantage of not having to _worry
about everything_ on each and every commit. These are two projects with
two
release cycles and they don't need to be developed together
simultaneously.
People can specialize and focus on different areas.
The whole idea of breaking the system up and then using gradle's plugin
API
for OFBiz is to remove the coupling between the two projects. If we
introduce svn externals then all we achieve is create two repositories
only to merge them again. Why! that's pointless!
Two products means two buildbot scripts, two releases, two development
cycles, two different things!
So to achieve true separation and decoupling, I suggest to avoid any
hacks
like svn externals.
On Sun, Feb 12, 2017 at 1:31 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi All,
This discussion already happened at OFBIZ-9182, but only between Taher,
Nicolas and I.
The question is simple, below reflects it, and the subject summarises
it.
So what are your thoughts and opinions?
Also when answering I guess we can remove '(was Re: Proposal to
create a
separate svn repository for the OFBiz official plugins)' from the
subject
(I was just "lazy" here)
Thanks
Jacques
Le 12/02/2017 à 11:22, Jacques Le Roux a écrit :
Sincerely I hardly see the benefit, but I see the disadvantages when I
remember what happened with R13.07. I mean how and by who will be
maintained the OOTB plugins?
I think this should be more discussed, and maybe voted, here
Jacques
Le 12/02/2017 à 11:18, Deepak Dixit a écrit :
Hi Jacques,
We can add gradle task to pull all plugins from remote. As we are
de-coupling plugins from core so I think its good idea to keep them
separate. If any committer or developer want he can use gradle task
for
the
same.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 3:43 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Yes this is the idea, why should we not? How else committers will
easily
maintain the plugins?
Jacques
Le 12/02/2017 à 10:25, Deepak Dixit a écrit :
Hi Jacques,
I think if wesvn:external on trunk, then it will always checkout
the
plugins with trunk
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 2:52 PM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:
