Hello,
To be more precise, Eclipse allow, when OFBiz is launched in debug mode
(no plugin that I remember), modifying java code on the fly, but only if :
* Not modifying signatures or adding news methods
* Not modifying code while debugging (i.e. on a breakpoint).
I used it a lot in the past
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
On 10 February 2017 at 21:50, Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com> wrote:
> It is not a bug, because the system use that value to decode the account
> id.
>
Thanks Jacopo.
I still think we have a serious problem.
I see in getGlAccountFromAccountType at line 533
http://svn.
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
Le 12/02/2017 à 14:24, Jacques Le Roux a écrit :
Le 12/02/2017 à 14:11, Jacques Le Roux a écrit :
I asked this to Infra in their Hipchat room:
[1:43 PM] Jacques Le Roux: Again about GitHub mirror, we don't see the new
branches there, normal?
[1:44 PM] Jacques Le Roux: I mean
http://svn.apache.
Le 12/02/2017 à 14:11, Jacques Le Roux a écrit :
I asked this to Infra in their Hipchat room:
[1:43 PM] Jacques Le Roux: Again about GitHub mirror, we don't see the new
branches there, normal?
[1:44 PM] Jacques Le Roux: I mean
http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk
and
http
I asked this to Infra in their Hipchat room:
[1:43 PM] Jacques Le Roux: Again about GitHub mirror, we don't see the new
branches there, normal?
[1:44 PM] Jacques Le Roux: I mean
http://svn.apache.org/repos/asf/ofbiz/ofbiz-framework/trunk
and
http://svn.apache.org/repos/asf/ofbiz/ofbiz-plugins/tr
That's a very important point with possible catastrophic consequences, thanks
Deepak! (I thought I fixed them all :/)
Jacques
Le 12/02/2017 à 12:36, dee...@apache.org a écrit :
Author: deepak
Date: Sun Feb 12 11:36:05 2017
New Revision: 1782658
URL: http://svn.apache.org/viewvc?rev=1782658&v
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
In 13.07 we totally removed all the specialpurposes component except
ecommerce.
Now here we are managing all the specialpurpose component in separate repo.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 6:24 PM, Taher Alkhateeb wrote:
> What does 13.07 have anyth
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
What does 13.07 have anything to do with this?
On Feb 12, 2017 3:49 PM, "Jacques Le Roux"
wrote:
That can be done but I think we need 1st to discuss the political
implications and everybody needs to well understand them
We must avoid the R13.07 "fiasco"
Jacques
Le 12/02/2017 à 13:15, Deepak
That can be done but I think we need 1st to discuss the political implications
and everybody needs to well understand them
We must avoid the R13.07 "fiasco"
Jacques
Le 12/02/2017 à 13:15, Deepak Dixit a écrit :
I think we can setup svn:ignore similar to hot-deploy.
Thanks & Regards
--
Deepa
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
I think we can setup svn:ignore similar to hot-deploy.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 5:31 PM, Taher Alkhateeb wrote:
> I'm not sure, but I think we should set up subversion to ignore the plugins
> directory except for the README file.
>
> On Sun,
I'm not sure, but I think we should set up subversion to ignore the plugins
directory except for the README file.
On Sun, Feb 12, 2017 at 2:30 PM, Taher Alkhateeb wrote:
> Great work Deepak! Thank you.
>
> On Sun, Feb 12, 2017 at 2:00 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
Great work Deepak! Thank you.
On Sun, Feb 12, 2017 at 2:00 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> Deepak,
>
> All sounds good to me, thanks. I know you have created a
> beforeSvnRestructuring tag as Taher suggested (we exchanged directly)
> I have asked infra for possible Gi
Deepak,
All sounds good to me, thanks. I know you have created a beforeSvnRestructuring
tag as Taher suggested (we exchanged directly)
I have asked infra for possible Github mirror best practices, here is Daniel's
answer
Daniel Gruno (Humbedooh)·11:54 AM: normally, git accounts for this in its
Thanks Jacques.
Restructuring done at r#1782651 and r#1782652
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 3:56 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
> OK, I'll start a discussion on this point ASAP
>
> Jacques
>
>
>
> Le 12/02/2017 à 11:22
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
OK, I'll start a discussion on this point ASAP
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
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,
Hi Jacques,
I think we can proceed with restructuring, as we can set/remove svn
external at later stage as well. So its not an blocker for restructuring.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 3:48 PM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:
Sure Jacques.
Let me check..
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 3:51 PM, Deepak Dixit <
deepak.di...@hotwaxsystems.com> wrote:
> Hi Jacques,
>
> I think we can proceed with restructuring, as we can set/remove svn
> external at later stage as well. So
Yes, right Deepak
Will you handle it ?
Jacques
Le 12/02/2017 à 10:33, Deepak Dixit a écrit :
Hi Jacques,
We don't need to delete plugins from trunk as svn move will move this to
destination. So first move plugins from trunk to new structure and then
move trunk to new location.
So sequence sh
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
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 we svn:external on trunk, then it will always checkout the
plugins with trunk
Thanks & Regards
--
Deepak Dixit
www.hotw
Hi Taher,
I think adding a tag is a good idea which missed in my proposition
Jacques
Le 12/02/2017 à 10:14, Taher Alkhateeb a écrit :
Hi Deepak,
Thank you for helping out! To me the challenge now is figuring out how to
do the restructure. Do we move? copy and dump? or some other strategy [1]
Hi Jacques,
We don't need to delete plugins from trunk as svn move will move this to
destination. So first move plugins from trunk to new structure and then
move trunk to new location.
So sequence should be like following:
svn move -m "Moves plugins and creates the new structure"
https://svn.apac
Hi Jacques,
I think if we svn: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:
> Hi Taher,
>
> We can directly use svn mv command
That's great thanks Deepak,
Ismail, please understand that this ML (dev ML) is used by developers to
discuss developing new stuff or improving stuff.
As suggested by Deepak, for questions regarding the usage of OFBiz please ask
them on the user ML
Thanks
Jacques
Le 12/02/2017 à 09:09, Deep
Hi Taher,
We can directly use svn mv command to restructure. It will retail svn
history. It will automatically create new directory/folder in destination
if not present.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sun, Feb 12, 2017 at 2:44 PM, Taher Alkhateeb wrote:
> Hi Deepak,
Hi,
As it was discussed, I assume ofbiz-framework contains also applications.
So I agree with the proposed structure and the move. I note that the proposed
structure is also good for next created branches for releases and such.
If we use svn move we should not lose history. This explains it: "
Hi Deepak,
Thank you for helping out! To me the challenge now is figuring out how to
do the restructure. Do we move? copy and dump? or some other strategy [1].
What happens to the subversion history? Should we add a tag that perhaps
says "before_restructuring_svn" for example? We also need to figu
Hi Taher,
I am willing to help, Please let me know how can I help in this effort?
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Sat, Feb 11, 2017 at 7:18 PM, Taher Alkhateeb wrote:
> Hello Folks,
>
> We are ready now to finally restructure our subversion repositories. This
> requir
Hi Ismail,
If Service return success then it will render view mentioned in response
name success, and if service fails and return error it will render view
mentioned in response name error.
Please refer ServiceUtil and ModelService java file for more reference.
Please use user mailing list for th
43 matches
Mail list logo
