Re: [DISCUSSION] Plugins: svn:external or Gradle Task?

[Michael Brohl]

Hi Taher,

inline...

Am 13.02.17 um 06:33 schrieb Taher Alkhateeb:

Hi Michael, All

All good points, thank you for your thoughts. So a solution that I proposed
in jira to easily manage and maintain our official plugins is to have a
gradle task named for example pullPluginSourceAll which pulls all the
plugins in one shot for testing and development purposes. Maybe we can also
add logic in this task so that it updates already downloaded plugins.

That's a good approach if you want to test plugins/integration within the framework without the need to work on plugin sources under source control, if I understand it right. This should be the default case.

Maybe there are other good solutions as well.

Additionally, I suggest to provide a task which creates the svn:externals file for the case where you want the plugin sources in your project and have them under source control. Or, if we don't want to have such a task in the codebase, provide some documentation on how to achieve this manually. Else I cannot think of an easy process for a plugin developer to create patches or make commits against the repository without hassle.

I'm sure there are other good ideas as well. My point of emphasis is to
Simply keep the two projects clearly separated, and to avoid relying
directly on tools not embedded within the framework like subversion.

I completely agree on this point and this should be the default. I just think that we should provide some (non default) alternatives or at least how-to's to make it easy for everyone to contribute.

We should think about different types of users and contributors.

Regards,

Michael

On Feb 13, 2017 12:08 AM, "Michael Brohl" <michael.br...@ecomify.de> wrote:

Hi,

first of all: great work and many thanks to Taher, Jacques and Deepak for
their efforts on the repository separation this weekend.

I think we should provide processes and support for the following cases:

1. separated development of the framework and core applications without
forced embedding of the plugins

2. separated development of the plugins with the support to embed the
framework part in the development environment

3. combined development of both framework and plugins.

I think we'll need convenience tools/processes/support for these
combinations because we should make contributions for and use of framework
+ plugins as easy as possible without forcing the entanglement of the
different projects.

As far as I understand forced use of svn:externals is contra productive
because it prevents the separation. We should instead describe the
mechanism and provide a set of svn:externals files for all users who want
to use it. Maybe also a gradle task which generates the needed file(s) for
convenience.

I think we cannot only rely on the pull plugin mechanism because combined
development needs to have framework and plugins in the IDE under version
control.

Users and developers should have a choice (and low hurdles to contribute),
on the other hand we should keep it lean and simple per default.

Not sure if I could make my viewpoint clear enough, I'm currently too
tired to concentrate on better words :-)

Best regards,

Michael


Am 12.02.17 um 20:59 schrieb Taher Alkhateeb:

Hi Sharan,

I think this is not the topic under discussion, and since it seems vague
to
you I will try to clarify:

The question now that we split framework and plugins is how to combine
them. The discussion so far between myself and Jacques is as follows:
- Jacques wants to use svn:externals so that subversion pulls all the
plugins into the framework and keep everything as is (testing, builds,
etc)
the way they were.
- My position is that we should use gradle to pull the plugins we need
without reliance on Subversion or any other tool and to treat the two
projects as two separate projects.

Both reasons / concerns from me and Jacques are expressed by reading the
history of this thread (that partly exists in another thread for which
Deepak contributed his opinion).

On Sun, Feb 12, 2017 at 10:49 PM, Sharan Foga <sha...@apache.org> wrote:

Hi All

I'm not exactly completely sure what this discussion is all about. The
title talks about svn and Gradle but questions in the thread seem to
about
something different. If it is as important as you say then we need to
make
sure that everyone understands exactly what this means.

Are you saying that because of the framework / plugin split then
committers will work only on the framework? If so, then remember that it
was our contributors and committers that put the 'plugins' into OFBiz in
the first place which means that people who are interested in developing
a
particular functionality further can do it without worrying about or
breaking the framework.

  From my side I know that we also have some OFBiz application
documentation
that is sitting in docbook inside OFBiz I think would be better
implemented
as a plugin. It would be good to be able to work on and test this
separately.

I apologise if I've misunderstood this thread but as I say - it's not
very
clear what it is all about.

Thanks
Sharan

On 2017-02-12 13:55 (+0100), 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:

smime.p7s
Description: S/MIME Cryptographic Signature