Re: [PROPOSAL] Environment variable configuration

[Gil Portenseigne]

Hello,

Thanks for proposing your tried and tested configuration solution. The
idea of discussion the original proposal about OFBiz configuration with
environment variable stayed in my head.

In the light of your solution and with our implementation feedback (git
branching configuration + env variable), and others contributors
feedback, we might elaborate the best to ease configuration management.

Thanks and Regards.

Gil


On Sun, Feb 02, 2020 at 04:40:14PM +0100, Michael Brohl wrote:
> Hi everyone,
> 
> the recent discussions reminded me of this thread again. There were a few
> people who were curious how we do configuration management and deployment
> (now in production for about 10 years). It is working for projects based on
> releases 13, 16, 17, 18 and trunk (with either Ant or Gradle).
> 
> Although we have our ways to maintain this as not being part of the official
> OFBiz codebase, I still think it is a good approach worth contributing.
> 
> Is this interesting for the community?
> 
> If there is significant interest I would try to re-write the proposal I did
> in [1], updated to the newest Gradle mechanism and several aspects for multi
> stage projects.
> 
> Cheers,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
> [1] 
> https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> 
> 
> Am 17.11.17 um 22:18 schrieb Michael Brohl:
> > Hi Jacques,
> > 
> > it takes some effort to make an OFBiz standard compatible patch of the
> > mechanism because we have several additions to the configurations. I
> > would take the effort if the community wants to adapt it but it's too
> > much work for just giving an idea.
> > 
> > I have explained the mechanism in [1]. There it is based on Ant but we
> > already use it in projects with Gradle.
> > 
> > We were looking for other solutions during the migration to Gradle but
> > haven't found a better approach considering all pros and cons (database
> > configuration, environment variables etc.). We use it for years on our
> > test- and production environments and it makes the handling of different
> > system specific configurations very easy.
> > 
> > We are thinking about the introduction of an additional configuration
> > level so that we have the base configuration (containing all
> > properties), a project configuration level and the system specific
> > configurations. This helps us to additionally maintain projects using
> > different sets of plugins.
> > 
> > I'm happy to explain more if something is unclear.
> > 
> > Regards,
> > 
> > Michael
> > 
> > 
> > [1] 
> > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> > 
> > 
> > Am 03.11.17 um 11:39 schrieb Jacques Le Roux:
> > > That's quite interesting Michael,
> > > 
> > > Would you share in a Jira? Then we could get to merge all
> > > experiences and find a consensu.
> > > 
> > > Jacques
> > > 
> > > 
> > > Le 03/11/2017 à 10:10, Michael Brohl a écrit :
> > > > Just an update triggered by the question from Swapnil [1]: our
> > > > configuration mechanism mentioned below is now on Gradle so it
> > > > would be compatible with 16.11 and later.
> > > > 
> > > > Regards,
> > > > 
> > > > Michael
> > > > 
> > > > [1] 
> > > > https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E
> > > > 
> > > > 
> > > > Am 05.07.17 um 17:56 schrieb Michael Brohl:
> > > > > Hi Gil,
> > > > > 
> > > > > we have similar challenges and modified OFBiz to deal with
> > > > > it easily. We offered to contribute this long time ago
> > > > > (2008) but it was decided against [1]. It was suggested to
> > > > > use patches instead but I think it's too complicated to
> > > > > manage several patch sets for different environments.
> > > > > 
> > > > > We now use a staged configure mechanism which uses a base
> > > > > build file, auto detected machine name and provided
> > > > > parameters to decide which configurations should be pulled
> > > > > for the environment. It's currently Ant based and therefore
> > > > > does not fit into the current build mechanism (on the todo
> > > > > list).
> > > > > 
> > > > > I like your approach also and I think it should be evaluated
> > > > > and discussed.
> > > > > 
> > > > > Best regards,
> > > > > 
> > > > > Michael Brohl
> > > > > ecomify GmbH
> > > > > www.ecomify.de
> > > > > 
> > > > > [1] 
> > > > > https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E
> > > > > 
> > > > > 
> > > > > 
> > > > > Am 05.07.17 um 17:36 schrieb gil portenseigne:
> > > > > > Hello all,
> > > > > > 
> > > > > > Working with different hosting companies, we used to
> > > > > > have issues when deploying OFBiz concerning technical
> > > > > > configuration of the different environments.
> > > > > > We are writ

Re: Removing “base/config/component-load.xml”

[Gil Portenseigne]

I agree with Jacques, i tried several times to participate in the
discussion but i am confused about the situation.

About this situation, Michael, we get your point about the process of
discuss things before modifying not trivial code and I do agree with
that. But there can always be mistakes.

I'm pretty sure that Mathieu's intentions are well guided, and reading
this last email about the bad process of Mathieu contribution make me
feel bad for him.

I hope we can get past this, now that it is clear, and work together
about the technical aspects, which will make it easier for people to
intervene.

Thanks and best regards.

Gil



On Fri, Jan 31, 2020 at 04:47:41PM +0100, Jacques Le Roux wrote:
> This is exactly the reason why I would prefer to start a new. Things get 
> confusing.
> 
> I'd finally prefer a new clean thread with the pro and cons for everybody to
> make an opinion which would allow to start a vote, since a consensus can't
> be reached
> 
> I hope Mathieu could write the pro...
> 
> If we agree on that one of us can star the new clean thread and we can focus 
> on the underneath of the problem w/o digressing
> 
> I know it's another effort for you and Mathieu, but I can't see a better way 
> to avoid drowning less concerned people in details.
> 
> We really need to focus, thanks
> 
> Jacques
> 
> Le 31/01/2020 à 16:11, Michael Brohl a écrit :
> > Pleas see my previous email, the discussion thread link is there (citating 
> > your own statement...)
> > 
> > Thanks,
> > 
> > Michael
> > 
> > 
> > Am 31.01.20 um 15:34 schrieb Jacques Le Roux:
> > > Le 31/01/2020 à 15:04, Michael Brohl a écrit :
> > > > Hi Jacques,
> > > > 
> > > > inline...
> > > > > 
> > > > > Maybe better to create a new thread?
> > > > 
> > > > We already have a thread for it, started on 22. August 2019. I
> > > > would very much appreciate if experienced users/developers would
> > > > join this discussion (which I have missed being on vacation at
> > > > the time and, having not much response, did not get my attention
> > > > until now).
> > > 
> > > Could you please send a link to this thread or its title? I could not 
> > > find it easily
> > > 
> > > Thanks
> > > 
> > > Jacques
> > > 
> > 


signature.asc
Description: PGP signature

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Pierre Smits]

Requests for feature branches in the OFBiz repositories received a lot of
push-back from PMC-members and committers in the past due to perceived high
maintenance burdens (ensuring the branch stayed in sync with where they
were derived from) placed on those willing to do that. I guess, the number
of those branches in svn (and restrictions thereon) led to this. I also
guess those complaining were the ones not often willing to participate in
those efforts.

With the implementation of Git as our prime version control solution, any
community member can start the feature branch and share it - for
collaboration and/or review purposes - via their public Github fork. With
this approach, the burden is placed on the member (not necessarily a PMC
Member or committer) willing to act as lead to keep the branch up to date.
And when the maintainer (as the driving party) feels confident it is ready
to be included in the OFBiz repository it can be introduced in the form of
a pull request. Updates to the community of progress can - as always - take
place via ticket comments and/or postings to the mailing list(s).

IMO, this path should be followed by every community member considering to
introduce new plugins or considering a large number of improvements on one
or more components.

However, there is also a drawback to this. This approach can lead to a big
contribution (in the form of a lot of changes to a lot of files) that won't
get the attention of fellow community members that the initiative deserves.
Over the years committers have rejected such from non-privileged
contributors because of the effort involved regarding review. And postings
on the ml hadn't helped the community. One could even argue that perception
regarding this has led to the floundering of many of the feature (and wish)
tickets in our JIRA (see [1]), and maybe even loss of contributors.

How will this be prevented?


[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20issuetype%20in%20(%22New%20Feature%22%2C%20Wish)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Sun, Feb 2, 2020 at 5:01 PM Michael Brohl 
wrote:

> +1, with a remark
>
> We should do the development on a feature branch based on trunk (instead
> of a release branch) and constantly merge trunk into it. This would
> allow to develop very near to the ongoing developments in other areas
> and merge back easily once the feature branch gets accepted. It would
> also allow field tests using the feature branch with the latest feature
> set.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 02.02.20 um 16:21 schrieb Pierre Smits:
> > Hi All,
> >
> > Given that this is yet another major refactoring endeavour and can, when
> we
> > do this on trunk, be dragged on for years given the limited number of
> > contributors. Like is happening right now with those other refactoring
> > efforts, such as the move from xml-services to script services or the
> > migrate-documentation effort.
> >
> > If we do this on trunk, there is the risk that we confront our adopters
> > (meaning their developers) with scripts in inconsistent locations. This
> > will surely hinder the appeal of OFBiz.
> >
> > Michael stated:
> >
> > Of course there will be perfomance metrics only if we would implement the
> > two patterns and compare runtime in a relevant load scenario which is not
> > achievable.
> >
> > When done on trunk, Michael is correct: we can't measure and compare
> impact
> > between the two scenarios.
> > But we can measure and compare when we don't do this on trunk, but
> instead
> > in a separate development branch based on one of the releases. Then we
> can
> > have a CI perform the necessary tests on both, and we get insight in the
> > performance gains/penalties.
> >
> > And when there are significant performance gains, we can work to merge
> the
> > changes back into trunk.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion , Vice President*
> > *Apache Directory , PMC Member*
> > Apache Incubator , committer
> > *Apache OFBiz , contributor (without
> privileges)
> > since 2008*
> > Apache Steve , committer
> >
> >
> > On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl 
> > wrote:
> >
> >> Hi Jacques,
> >>
> >> just stumbled upon this topic again, inline...
> >>
> >> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> >>> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> >>> OFBIZ-10205 and this thread, ie

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Michael Brohl]

+1, with a remark

We should do the development on a feature branch based on trunk (instead 
of a release branch) and constantly merge trunk into it. This would 
allow to develop very near to the ongoing developments in other areas 
and merge back easily once the feature branch gets accepted. It would 
also allow field tests using the feature branch with the latest feature set.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 02.02.20 um 16:21 schrieb Pierre Smits:

Hi All,

Given that this is yet another major refactoring endeavour and can, when we
do this on trunk, be dragged on for years given the limited number of
contributors. Like is happening right now with those other refactoring
efforts, such as the move from xml-services to script services or the
migrate-documentation effort.

If we do this on trunk, there is the risk that we confront our adopters
(meaning their developers) with scripts in inconsistent locations. This
will surely hinder the appeal of OFBiz.

Michael stated:

Of course there will be perfomance metrics only if we would implement the
two patterns and compare runtime in a relevant load scenario which is not
achievable.

When done on trunk, Michael is correct: we can't measure and compare impact
between the two scenarios.
But we can measure and compare when we don't do this on trunk, but instead
in a separate development branch based on one of the releases. Then we can
have a CI perform the necessary tests on both, and we get insight in the
performance gains/penalties.

And when there are significant performance gains, we can work to merge the
changes back into trunk.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl 
wrote:


Hi Jacques,

just stumbled upon this topic again, inline...

Am 20.09.19 um 17:39 schrieb Jacques Le Roux:

In a 1st time I intend to do only what I wrote in OFBIZ-10226,
OFBIZ-10205 and this thread, ie indeed mostly "move them to
src/main/groovy". That's enough for my need.

Using @CompileStatic is out of my scope because I want to keep Groovy
scripts dynamic.

I'd like to bring up this thead again and encourage everyone to read the
mentioned article by David E. Jones:

https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E

We should be careful and act responsible when deciding certain
principles and patterns. While it is of course more simple for
developers to have it dynamic it might be a nightmare in real world
projects with huge traffic. We have our experiences with this.

We had this discussion in the aforementioned thread. One argument
against is "premature optimization" which is a killer argument to end
such discussions. Of course there will be perfomance metrics only if we
would implement the two patterns and compare runtime in a relevant load
scenario which is not achievable.

One can very well rely on the experiences of others and make use of
patterns to avoid problems in the later run. It would be real bad for
the project if we do mass changes and ignore these experiences just to
end up with users having serious production problems.

So I ask everyone involved to act responsible and take these
informations into account when changing the code base.

Thanks,

Michael








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] Environment variable configuration

[Michael Brohl]

Hi everyone,

the recent discussions reminded me of this thread again. There were a 
few people who were curious how we do configuration management and 
deployment (now in production for about 10 years). It is working for 
projects based on releases 13, 16, 17, 18 and trunk (with either Ant or 
Gradle).


Although we have our ways to maintain this as not being part of the 
official OFBiz codebase, I still think it is a good approach worth 
contributing.


Is this interesting for the community?

If there is significant interest I would try to re-write the proposal I 
did in [1], updated to the newest Gradle mechanism and several aspects 
for multi stage projects.


Cheers,

Michael Brohl

ecomify GmbH - www.ecomify.de


[1] 
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E



Am 17.11.17 um 22:18 schrieb Michael Brohl:

Hi Jacques,

it takes some effort to make an OFBiz standard compatible patch of the 
mechanism because we have several additions to the configurations. I 
would take the effort if the community wants to adapt it but it's too 
much work for just giving an idea.


I have explained the mechanism in [1]. There it is based on Ant but we 
already use it in projects with Gradle.


We were looking for other solutions during the migration to Gradle but 
haven't found a better approach considering all pros and cons 
(database configuration, environment variables etc.). We use it for 
years on our test- and production environments and it makes the 
handling of different system specific configurations very easy.


We are thinking about the introduction of an additional configuration 
level so that we have the base configuration (containing all 
properties), a project configuration level and the system specific 
configurations. This helps us to additionally maintain projects using 
different sets of plugins.


I'm happy to explain more if something is unclear.

Regards,

Michael


[1] 
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E



Am 03.11.17 um 11:39 schrieb Jacques Le Roux:

That's quite interesting Michael,

Would you share in a Jira? Then we could get to merge all experiences 
and find a consensu.


Jacques


Le 03/11/2017 à 10:10, Michael Brohl a écrit :
Just an update triggered by the question from Swapnil [1]: our 
configuration mechanism mentioned below is now on Gradle so it would 
be compatible with 16.11 and later.


Regards,

Michael

[1] 
https://lists.apache.org/thread.html/703f3e615a93a2a83fb92b122eb8275fb05aa27537d95342815dd043@%3Cdev.ofbiz.apache.org%3E



Am 05.07.17 um 17:56 schrieb Michael Brohl:

Hi Gil,

we have similar challenges and modified OFBiz to deal with it 
easily. We offered to contribute this long time ago (2008) but it 
was decided against [1]. It was suggested to use patches instead 
but I think it's too complicated to manage several patch sets for 
different environments.


We now use a staged configure mechanism which uses a base build 
file, auto detected machine name and provided parameters to decide 
which configurations should be pulled for the environment. It's 
currently Ant based and therefore does not fit into the current 
build mechanism (on the todo list).


I like your approach also and I think it should be evaluated and 
discussed.


Best regards,

Michael Brohl
ecomify GmbH
www.ecomify.de

[1] 
https://lists.apache.org/thread.html/b95e239250880d9a5b34268b3b711f0f8f7f0540a26bb41c5ced493a@1213087551@%3Cdev.ofbiz.apache.org%3E




Am 05.07.17 um 17:36 schrieb gil portenseigne:

Hello all,

Working with different hosting companies, we used to have issues 
when deploying OFBiz concerning technical configuration of the 
different environments.
We are writing this mail to get feedback from the community and 
eventually propose to improve OFBiz on this matter.


For a customer, we are working with 4 instances of a release 13.07 
OFBiz, and are currently using a set of patches (with 
addonmanager...) to manage environment specific configurations.
During each production deployment, the hosting company receive 
from our jenkins a precompiled archive containing OFBiz codebase, 
and then apply the set of patches to configure it to the 
environment needs, recompile and relaunch...


This way of doing can cause issue when patch could not apply, 
after a codebase modification (pretty rare but it happens).


We are not satisfied with this way of doing, we are currently 
thinking about using environment variables to configure technical 
environment properties (those are on the hosting company 
responsibility), and to keep functional specifics into the code base.
If you have some experience or advice in this matter, you are 
welcome.


For our case, we currently have enhanced OFBiz to be able to get 
environment variable from the operating system within property 
file and some other configuration files (

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Pierre Smits]

Hi All,

Given that this is yet another major refactoring endeavour and can, when we
do this on trunk, be dragged on for years given the limited number of
contributors. Like is happening right now with those other refactoring
efforts, such as the move from xml-services to script services or the
migrate-documentation effort.

If we do this on trunk, there is the risk that we confront our adopters
(meaning their developers) with scripts in inconsistent locations. This
will surely hinder the appeal of OFBiz.

Michael stated:

Of course there will be perfomance metrics only if we would implement the
two patterns and compare runtime in a relevant load scenario which is not
achievable.

When done on trunk, Michael is correct: we can't measure and compare impact
between the two scenarios.
But we can measure and compare when we don't do this on trunk, but instead
in a separate development branch based on one of the releases. Then we can
have a CI perform the necessary tests on both, and we get insight in the
performance gains/penalties.

And when there are significant performance gains, we can work to merge the
changes back into trunk.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer


On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl 
wrote:

> Hi Jacques,
>
> just stumbled upon this topic again, inline...
>
> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> > In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> > OFBIZ-10205 and this thread, ie indeed mostly "move them to
> > src/main/groovy". That's enough for my need.
> >
> > Using @CompileStatic is out of my scope because I want to keep Groovy
> > scripts dynamic.
>
> I'd like to bring up this thead again and encourage everyone to read the
> mentioned article by David E. Jones:
>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
>
> We should be careful and act responsible when deciding certain
> principles and patterns. While it is of course more simple for
> developers to have it dynamic it might be a nightmare in real world
> projects with huge traffic. We have our experiences with this.
>
> We had this discussion in the aforementioned thread. One argument
> against is "premature optimization" which is a killer argument to end
> such discussions. Of course there will be perfomance metrics only if we
> would implement the two patterns and compare runtime in a relevant load
> scenario which is not achievable.
>
> One can very well rely on the experiences of others and make use of
> patterns to avoid problems in the later run. It would be real bad for
> the project if we do mass changes and ignore these experiences just to
> end up with users having serious production problems.
>
> So I ask everyone involved to act responsible and take these
> informations into account when changing the code base.
>
> Thanks,
>
> Michael
>
>
>
>

Re: Test issue

[Nicolas Malin]

Thanks jacques, I will take care

Nicolas

On 02/02/2020 11:41, Jacques Le Roux wrote:
> About Javadoc and Infra
>
> https://issues.apache.org/jira/browse/INFRA-19807
>
> Le 02/02/2020 à 11:23, Jacques Le Roux a écrit :
>> Hi Pawan, Nicolas,
>>
>> Pawan, we have a test issue reported by Buildbot for R17 and R18
>> branch with plugins
>>
>> R17
>>
>>    https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins
>>    1st case:
>> https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/440
>>    failures:
>> https://ci.apache.org/projects/ofbiz/logs/17.12/plugins/html/
>>
>> R18
>>
>> https://ci.apache.org/builders/ofbizBranch18FrameworkPlugins
>> 1st case:
>> https://ci.apache.org/builders/ofbizBranch18FrameworkPlugins/builds/271
>> failures: https://ci.apache.org/projects/ofbiz/logs/18.12/plugins/html/
>>
>> So it's the same case.
>>
>> Nicolas, we have a test issue reported by Buildbot for the trunk with
>> plugins
>>
>> https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=30
>> 1st case:
>> https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1108
>> failures: we have another issue with access to URLs for Javadoc from
>> Buildbot. They work locally so I'll open an Infra Jira for that. But
>> I reproduce the same 8 failures than in R17/R18 locally
>>
>> It seems the oldest failures are on Nicolas side. But could you
>> please both have a look at it?
>>
>> Thanks
>>
>> Jacques
>>
>


pEpkey.asc
Description: application/pgp-keys

Re: Test issue

[Jacques Le Roux]

About Javadoc and Infra

https://issues.apache.org/jira/browse/INFRA-19807

Le 02/02/2020 à 11:23, Jacques Le Roux a écrit :

Hi Pawan, Nicolas,

Pawan, we have a test issue reported by Buildbot for R17 and R18 branch with 
plugins

R17

   https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins
   1st case: 
https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/440
   failures: https://ci.apache.org/projects/ofbiz/logs/17.12/plugins/html/

R18

https://ci.apache.org/builders/ofbizBranch18FrameworkPlugins
1st case: 
https://ci.apache.org/builders/ofbizBranch18FrameworkPlugins/builds/271
failures: https://ci.apache.org/projects/ofbiz/logs/18.12/plugins/html/

So it's the same case.

Nicolas, we have a test issue reported by Buildbot for the trunk with plugins

https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=30
1st case: https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1108
failures: we have another issue with access to URLs for Javadoc from Buildbot. They work locally so I'll open an Infra Jira for that. But I 
reproduce the same 8 failures than in R17/R18 locally


It seems the oldest failures are on Nicolas side. But could you please both 
have a look at it?

Thanks

Jacques

Test issue

[Jacques Le Roux]

Hi Pawan, Nicolas,

Pawan, we have a test issue reported by Buildbot for R17 and R18 branch with 
plugins

R17

   https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins
   1st case: 
https://ci.apache.org/builders/ofbizBranch17FrameworkPlugins/builds/440
   failures: https://ci.apache.org/projects/ofbiz/logs/17.12/plugins/html/

R18

https://ci.apache.org/builders/ofbizBranch18FrameworkPlugins
1st case: 
https://ci.apache.org/builders/ofbizBranch18FrameworkPlugins/builds/271
failures: https://ci.apache.org/projects/ofbiz/logs/18.12/plugins/html/

So it's the same case.

Nicolas, we have a test issue reported by Buildbot for the trunk with plugins

https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins?numbuilds=30
1st case: https://ci.apache.org/builders/ofbizTrunkFrameworkPlugins/builds/1108
failures: we have another issue with access to URLs for Javadoc from Buildbot. They work locally so I'll open an Infra Jira for that. But I reproduce 
the same 8 failures than in R17/R18 locally


It seems the oldest failures are on Nicolas side. But could you please both 
have a look at it?

Thanks

Jacques