What I fear (still not looked into it) is that Taher did it that way because he (rightly) wanted to have the same structure than before, ie the
possibility to commit a change in a plugin from the root of the project.
So I fear that another solution will impose to have as much as working copies as plugins. Then you have to commit by plugin. It's not a big deal for
one change but multiples in different plugins become a pain. I mentioned that earlier.
Jacques
Le 15/03/2017 à 06:15, Deepak Dixit a écrit :
We need to enhance pullAllPluginsSource task, after running this you will
not able to commit or run any svn command on plugins, as it do checkout of
plugins/trunk and copy its folder into plugins.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Wed, Mar 15, 2017 at 12:18 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
That would be better indeed, I did not look a it yet.
Jacques
Le 14/03/2017 à 19:04, Deepak Dixit a écrit :
I think we can improve gradle task and instead of deleting plugins it will
its delete sub-folder.
I am sure gradle should have ability to delete sub-folder. :)
If we delete README.txt then it will not be available in git as git does
not support empty folder.
Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com
On Tue, Mar 14, 2017 at 6:46 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
Hi,
I just crossed an issue while updating my ofbiz-framework working copy
after having used pullAllPluginsSource. I get an error message "Skipped
obstructing working copy".
This is because we have already a plugins folder in the
ofbiz-framework/trunk branch and when we use pullAllPluginsSource we
replace it by a new one (plugins folder) and the main .svn gets confused
(in root)
I think we can live w/o the README.txt in the plugins folder and the
folder altogether and document it another way if needed (in the main
README.MD?), it will fix this problem.
Opinions?
Jacques
