[discussion] With plugins, is hot-deploy necessary?

[Wai]

This discussion is in reference to...
https://issues.apache.org/jira/browse/OFBIZ-9244
http://ofbiz.135035.n4.nabble.com/plugin-and-hotdeploy-td4702922.html

Now that plugins has been implemented, would hot-deploy be necessary?

As I've mentions in OFBIZ-9244, I think keeping hot-deploy would be useful
for those that are prototyping new components that might or might not be
open sourced later. My view is that the plugins directory are for open
sourced or commercial components that could be downloaded from known
repositories.  Whereas, the hot-deploy directory is for local
developments/prototypings.  From an in-house developer's view point with
multiple proprietary components in development, I find that mixing in-house
and downloadable components confusing. I.e. difficult to locate my own
components in the midst of all the available downloaded components (there
are 12 of them).

On the other hand, Jacques Le Roux takes the position that all plugins (open
sourced, commercial, in-house prototypes) should all be located in one
place.

You opinions are greatly appreciated.

Kind regards,
Wai



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/discussion-With-plugins-is-hot-deploy-necessary-tp4702976.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: port mapping 8080 to 8443 is broken

[Taher Alkhateeb]

Okay so it seems this issue was introduced by your work based on what I
read in jira. I don't think you should apply code changes that cause
regressions like this one.

On Mar 3, 2017 4:40 PM, "Jacques Le Roux" 
wrote:

> Le 02/03/2017 à 17:12, Jacques Le Roux a écrit :
>
>> Le 02/03/2017 à 15:52, Taher Alkhateeb a écrit :
>>
>>> I'm not sure who committed what, but now the automatic redirection from
>>> 8080 to 8443 ssl is broken. Jacques is this related to your work on port
>>> offset stuff?
>>>
>>> This is only with localhost, right?
>> If it's the case, I guess it's related to OFBIZ-9206 but I have no time
>> to look at it right now
>>
>> Jacques
>>
>>
>> See my comments at OFBIZ-9242
>
> Jacques
>
>

Re: Should be keep the multitenant feature even if broken?

[Taher Alkhateeb]

All good points Michael. Replacing is neither short term nor easy as many
places in the code base depend on this feature, not to mention the need for
community approval too. I just mentioned this as an alternative solution
from a technical standpoint.

So our best bet is to fix the issue mentioned by Jacques.

On Mar 3, 2017 9:16 PM, "Michael Brohl"  wrote:

> Hi Taher,
>
> I don't think that this is a valid short-term approach.
>
> As far as I know, there are users and also service providers relying on
> the multi-tenant feature and we should have a mid- to long-term roadmap for
> a migration to other solutions.
>
> It would be really helpful to have some opinions by users of the
> multi-tenancy feature.
>
> Best regards,
>
> Michael
>
>
> Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:
>
>> In my opinion, the multi-tenancy feature can be reasonably replaced with
>> non-java databases like mysql and postgres combined with docker. Both
>> instances share the same code base but with two different runtime volumes
>> and two databases. This would actually reduce the complexity of the code
>> base, especially the entity engine.
>>
>> On Mar 3, 2017 10:39 AM, "Jacques Le Roux" 
>> wrote:
>>
>> Hi,
>>>
>>> After my analysis at https://s.apache.org/hvR9 if we don't fix the
>>> issues
>>> reported there I wonder if we don't need to remove the multitenant
>>> feature,
>>> better not to propose a broken solution!
>>>
>>> Jacques
>>>
>>>
>>>
>
>

Re: Should be keep the multitenant feature even if broken?

[Michael Brohl]

Hi Taher,

I don't think that this is a valid short-term approach.

As far as I know, there are users and also service providers relying on 
the multi-tenant feature and we should have a mid- to long-term roadmap 
for a migration to other solutions.


It would be really helpful to have some opinions by users of the 
multi-tenancy feature.


Best regards,

Michael


Am 03.03.17 um 13:22 schrieb Taher Alkhateeb:

In my opinion, the multi-tenancy feature can be reasonably replaced with
non-java databases like mysql and postgres combined with docker. Both
instances share the same code base but with two different runtime volumes
and two databases. This would actually reduce the complexity of the code
base, especially the entity engine.

On Mar 3, 2017 10:39 AM, "Jacques Le Roux" 
wrote:


Hi,

After my analysis at https://s.apache.org/hvR9 if we don't fix the issues
reported there I wonder if we don't need to remove the multitenant feature,
better not to propose a broken solution!

Jacques







smime.p7s
Description: S/MIME Cryptographic Signature

Re: Should be keep the multitenant feature even if broken?

[Jacques Le Roux]

Thanks Taher,

IMO if we do that we should document clearly how to do it, before dropping and 
cleaning the multi-tenancy feature.

Of course solving the 2 issues reported in OFBIZ-9230 (checkRhsType and getSystemPropertyValue) should be tried before. I'll not create Jiras for that 
before we get to a consensus


Jacques


Le 03/03/2017 à 13:22, Taher Alkhateeb a écrit :

In my opinion, the multi-tenancy feature can be reasonably replaced with
non-java databases like mysql and postgres combined with docker. Both
instances share the same code base but with two different runtime volumes
and two databases. This would actually reduce the complexity of the code
base, especially the entity engine.

On Mar 3, 2017 10:39 AM, "Jacques Le Roux" 
wrote:


Hi,

After my analysis at https://s.apache.org/hvR9 if we don't fix the issues
reported there I wonder if we don't need to remove the multitenant feature,
better not to propose a broken solution!

Jacques

Re: port mapping 8080 to 8443 is broken

[Jacques Le Roux]

Le 02/03/2017 à 17:12, Jacques Le Roux a écrit :

Le 02/03/2017 à 15:52, Taher Alkhateeb a écrit :

I'm not sure who committed what, but now the automatic redirection from
8080 to 8443 ssl is broken. Jacques is this related to your work on port
offset stuff?


This is only with localhost, right?
If it's the case, I guess it's related to OFBIZ-9206 but I have no time to look 
at it right now

Jacques



See my comments at OFBIZ-9242

Jacques

Re: Should be keep the multitenant feature even if broken?

[Taher Alkhateeb]

In my opinion, the multi-tenancy feature can be reasonably replaced with
non-java databases like mysql and postgres combined with docker. Both
instances share the same code base but with two different runtime volumes
and two databases. This would actually reduce the complexity of the code
base, especially the entity engine.

On Mar 3, 2017 10:39 AM, "Jacques Le Roux" 
wrote:

> Hi,
>
> After my analysis at https://s.apache.org/hvR9 if we don't fix the issues
> reported there I wonder if we don't need to remove the multitenant feature,
> better not to propose a broken solution!
>
> Jacques
>
>

Re: About https://github.com/apache/ofbiz

[Nicolas Malin]

:)


Le 03/03/2017 à 10:48, Jacques Le Roux a écrit :

Ah you did , cool!

I guess I reopened an old tab due to my crazy, but working, FF config :D

Jacques

Re: About https://github.com/apache/ofbiz

[Jacques Le Roux]

Ah you did , cool!

I guess I reopened an old tab due to my crazy, but working, FF config :D

Jacques


Le 03/03/2017 à 10:46, Jacques Le Roux a écrit :

Yes, thanks Nicolas,

They actually (@Pono on Hipchat infra at least) know it already.

It would be good if you pushed them a bit at INFRA-13557 :)

Jacques


Le 03/03/2017 à 10:30, Nicolas Malin a écrit :

Thnaks Jacques,

I complete your issue because the I found the repository 
git://git.apache.org/ofbiz-framework.git but unusable.

Now we need to wait the infra to understand why the Git is break :|

Nicolas


Le 21/02/2017 à 16:58, Jacques Le Roux a écrit :

OK, again :/

I closed INFRA-13497 and to "Update OFBiz Github" created INFRA-13557 which is 
more clear

But infra said there is an issue updating OFBiz Github, let's see...

Jacques


Le 21/02/2017 à 16:23, Jacques Le Roux a écrit :

Done, I closed INFRA-13497 to "Update OFBiz Github" and created INFRA-1355, 
that's more clear

Jacques


Le 19/02/2017 à 10:31, Jacques Le Roux a écrit :
I have made the list and comments at https://issues.apache.org/jira/browse/OFBIZ-9219 please check before I delete the branches, say tomorrow or 
Tuesday...


Thanks

Jacques


Le 17/02/2017 à 14:21, Jacques Le Roux a écrit :

Hi,

I made a request to update it through INFRA-13497 because it does not contain 
the 2 new ofbiz-framework/trunk and ofbiz-plugins/trunk branches.

I think we should remove a lot of useless and old confusing branches in svn and document the fact in GitHub that the ofbiz-framework/trunk is 
the new trunk. But how I'm still unsure, I guess at top of the README.MD ?


I'll make a list of branches to remove...

Jacques

Re: About https://github.com/apache/ofbiz

[Jacques Le Roux]

Yes, thanks Nicolas,

They actually (@Pono on Hipchat infra at least) know it already.

It would be good if you pushed them a bit at INFRA-13557 :)

Jacques


Le 03/03/2017 à 10:30, Nicolas Malin a écrit :

Thnaks Jacques,

I complete your issue because the I found the repository 
git://git.apache.org/ofbiz-framework.git but unusable.

Now we need to wait the infra to understand why the Git is break :|

Nicolas


Le 21/02/2017 à 16:58, Jacques Le Roux a écrit :

OK, again :/

I closed INFRA-13497 and to "Update OFBiz Github" created INFRA-13557 which is 
more clear

But infra said there is an issue updating OFBiz Github, let's see...

Jacques


Le 21/02/2017 à 16:23, Jacques Le Roux a écrit :

Done, I closed INFRA-13497 to "Update OFBiz Github" and created INFRA-1355, 
that's more clear

Jacques


Le 19/02/2017 à 10:31, Jacques Le Roux a écrit :
I have made the list and comments at https://issues.apache.org/jira/browse/OFBIZ-9219 please check before I delete the branches, say tomorrow or 
Tuesday...


Thanks

Jacques


Le 17/02/2017 à 14:21, Jacques Le Roux a écrit :

Hi,

I made a request to update it through INFRA-13497 because it does not contain 
the 2 new ofbiz-framework/trunk and ofbiz-plugins/trunk branches.

I think we should remove a lot of useless and old confusing branches in svn and document the fact in GitHub that the ofbiz-framework/trunk is 
the new trunk. But how I'm still unsure, I guess at top of the README.MD ?


I'll make a list of branches to remove...

Jacques

Re: buildbot failure in on ofbiz-trunk-framework

[Jacques Le Roux]

Le 03/03/2017 à 09:01, build...@apache.org a écrit :

The Buildbot has detected a new failure on builder ofbiz-trunk-framework while 
building . Full details are available at:
 https://ci.apache.org/builders/ofbiz-trunk-framework/builds/5

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: forced: by IRC user  (privmsg): forces manual build. I 
need to check svn update in Buildbot
Build Source Stamp: HEAD
Blamelist:

BUILD FAILED: failed shell_2

Sincerely,
  -The Buildbot





This is only due to pending INFRA-13573

Jacques

Re: About https://github.com/apache/ofbiz

[Nicolas Malin]

Thnaks Jacques,

I complete your issue because the I found the repository 
git://git.apache.org/ofbiz-framework.git but unusable.


Now we need to wait the infra to understand why the Git is break :|

Nicolas


Le 21/02/2017 à 16:58, Jacques Le Roux a écrit :

OK, again :/

I closed INFRA-13497 and to "Update OFBiz Github" created INFRA-13557 
which is more clear


But infra said there is an issue updating OFBiz Github, let's see...

Jacques


Le 21/02/2017 à 16:23, Jacques Le Roux a écrit :
Done, I closed INFRA-13497 to "Update OFBiz Github" and created 
INFRA-1355, that's more clear


Jacques


Le 19/02/2017 à 10:31, Jacques Le Roux a écrit :
I have made the list and comments at 
https://issues.apache.org/jira/browse/OFBIZ-9219 please check before 
I delete the branches, say tomorrow or Tuesday...


Thanks

Jacques


Le 17/02/2017 à 14:21, Jacques Le Roux a écrit :

Hi,

I made a request to update it through INFRA-13497 because it does 
not contain the 2 new ofbiz-framework/trunk and ofbiz-plugins/trunk 
branches.


I think we should remove a lot of useless and old confusing 
branches in svn and document the fact in GitHub that the 
ofbiz-framework/trunk is the new trunk. But how I'm still unsure, I 
guess at top of the README.MD ?


I'll make a list of branches to remove...

Jacques

buildbot failure in on ofbiz-trunk-framework

[buildbot]

The Buildbot has detected a new failure on builder ofbiz-trunk-framework while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk-framework/builds/5

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: forced: by IRC user  (privmsg): forces manual build. I 
need to check svn update in Buildbot
Build Source Stamp: HEAD
Blamelist: 

BUILD FAILED: failed shell_2

Sincerely,
 -The Buildbot