Le 14/02/2017 à 09:08, Jacques Le Roux a écrit :
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
So, apart if I missed something, technically it's OK. I believe committers need now to agree about checking out all plugins and maintaining them as
we did before. This must be documented in our poli
Le 08/03/2017 à 19:57, Jacques Le Roux a écrit :
Le 14/02/2017 à 08:57, Jacques Le Roux a écrit :
We now just need INFRA-13496 to be fixed :) (the port 8080 issue again)
Have a nice day
Jacques
Here we go again
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13573
Jacques
Le 14/02/2017 à 08:57, Jacques Le Roux a écrit :
We now just need INFRA-13496 to be fixed :) (the port 8080 issue again)
Have a nice day
Jacques
Here we go again
https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-13573
Jacques
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
So updting a plugin by hand with svn, or even several plugins at a time with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
So we don't need Gradle tasks for that, all is still possible.
To summarize, so far I seed no dis
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
So, apart if I missed something, technically it's OK. I believe committers need now to agree about checking out all plugins and maintaining them as
we did before. This must be documented in our policies.
We also need to better, but as simply as p
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
I have an idea for that: we create a copy of the trunk in a BuildBot special
branch, say ofbiz-framework-buildbot
This branch must never be used to commit directly (we can always revert in case)
This branch has svn:externals for plugins installe
Hi Taher,
that would be the valid process for a contributor. For me as a
committer, I'd like to directly commit a change to the repository
(either after applying a patch or after a direct change).
I'm currently not sure if I oversee all possibilities we have out of the
box. Jacques mentioned
I do that regularly when backporting same in several releases branches at once.
This could also happen when 2 plugins are related, example and exampleext for
instance, ebay plugins also IIRW. And I'm sure in more cases...
I agree on the idea of having separated projects, but I'm not sure how it
Le 13/02/2017 à 11:15, Jacopo Cappellato a écrit :
On Mon, Feb 13, 2017 at 11:06 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
So updting a plugin by hand with svn, or even several plugins at a time
with an IDE or a Svn GUI , is n
On Mon, Feb 13, 2017 at 11:06 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
>
>> So updting a plugin by hand with svn, or even several plugins at a time
>> with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
>
I don't think we should commit in several branches at once. This again
brings us back to the same problem, we are trying to treat separate
projects as one project.
On Mon, Feb 13, 2017 at 1:06 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Le 13/02/2017 à 10:56, Jacques Le Roux a éc
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
So updting a plugin by hand with svn, or even several plugins at a time with an IDE or a Svn GUI , is not be a problem, nor to commit changes, etc.
So we don't need Gradle tasks for that, all is still possible.
To summarize, so far I seed no dis
Hi Michael. If I understand your point correctly regarding ease of
contribution, would it be a problem to just go to the plugin directory and
issue a command like svn diff > plugin-fix.patch?
On Mon, Feb 13, 2017 at 12:54 PM, Michael Brohl
wrote:
> Hi Taher,
>
> inline...
>
> Am 13.02.17 um 06:3
Ah, and looking forward for a pullAllPluginsSource task
Jacques
Le 13/02/2017 à 10:56, Jacques Le Roux a écrit :
Hi,
Thanks Michael, your points are clearly explained.
I agree that using svn:externals for plugins breaks the initial purpose of
decoupling plugins from the rest.
Also providin
Hi,
Thanks Michael, your points are clearly explained.
I agree that using svn:externals for plugins breaks the initial purpose of
decoupling plugins from the rest.
Also providing a set of svn:externals files would not help because
svn:externals need to be committed in the repo to be effective
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 al
On Sun, Feb 12, 2017 at 1:32 PM, Taher Alkhateeb wrote:
> 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 repo
On Mon, Feb 13, 2017 at 6:33 AM, Taher Alkhateeb wrote:
> 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 t
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
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 embed
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 th
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 sa
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 e
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"
wrote:
In (my) Thu
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"
wrote:
> In (my) Thunderbird it was buried in the previous thread so I "created a
> clean new thread to have it more pr
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 Su
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 s
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 agree with Taher,
We have to keep both framework and plugins separately.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 6:02 PM, Taher Alkhateeb wrote:
> Let's take a look at the big picture for a moment before we decide. We have
> broken OFBiz into essentiall
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 bi
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 s
31 matches
Mail list logo
