Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Le 19/04/2023 à 11:24, Jacques Le Roux a écrit :

Good idea about the badge. I'll have a look.


Hi Daniel,

It's OK for trunk build but how to cleanly differentiate ?

https://ci2.apache.org/badges/ofbizTrunkFramework.svg
from
https://ci2.apache.org/badges/ofbizTrunkFrameworkRat.svg

https://ci2.apache.org/badges/ gives nothing :/

Jacques

Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"

[Michael Brohl]

To have it even more clear, I would separate logic for events and services.

The GroovyBaseScript in the service engine package should only be used 
for services and there should be another one for events, if really 
needed. Mixing both together is bad practice IMO. There seem to be only 
7 controller entries using a groovy script as the event target.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.04.23 um 16:49 schrieb Jacques Le Roux:

Hi Daniel,

I dont think there is a knowledge about methods being both services 
and events. I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log 
content (now in Docker);
so I wonder if there are such other cases than 
CommunicationEventServices::sendEmail  (colon notation is available in 
Groovy 3)

that bots and demo uses could have generated.

I tend to agree about having GroovyBaseScript::success deprecated and 
replaced with methods GroovyBaseScript::scriptSuccess 
GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess


I'm not yet acquainted with Codernarc rules, but the changes in 
GroovyBaseScript seem straightforward.
And (hopefully) this should not be a big deal to change accordingly in 
scripts methods with the help of Codenarc, right ?


My 2 cts

Jacques

Le 19/04/2023 à 18:37, Daniel Watford a écrit :

Hello,

In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the code 
was

called.

The untyped nature of Groovy had allowed a certain degree of 
flexibility in

code that GroovyBaseScript#success could be relied upon to prepare a
response appropriate to the calling conventions of an event handler or
service implementation. However over the last decade, possibly driven by
increased use of linters/static analysers, we have seen a push back 
towards

explicit typing, particularly on public methods.

If we continue to adopt the guidance from static analysers and apply
explicit typing to public methods in our groovy code, then we need to 
avoid

the black box approach of GroovyBaseScript#success figuring out what
calling conventions (i.e. event or service) are in play and, instead, a
groovy method should be intentionally written as either a service or 
event

handler.

If we have cases where a groovy method is used to provide 
implementations
for both a service and an event handler, then we can employ a thin 
adapter
layer to convert the result type between the two calling conventions. 
Do we

know if many such cases currently exist in OFBiz?

My preference would be to see GroovyBaseScript#success deprecated and
replaced with methods along the lines of 
GroovyBaseScript#scriptSuccess and
GroovyCaseScript#eventSuccess that return a Map and 
String

respectively.

Thanks,

Dan.

On Wed, 19 Apr 2023 at 16:44, Jacques Le 
Roux

wrote:


Hi All,

At OFBIZ-12801, we had a discussion with Daniel and Gil about the
described issue (last comments there)
We are unsure of the best solution, so this thread to discuss and 
decide.


As Gil reported, Jacopo's comment of the related commit* contains

 <>

What would be your opinion about a best solution?

TIA

Jacques

*http://svn.apache.org/viewvc?view=revision=1298908

Re: [OFBIZ-12801] "Error at CommunicationEventServices.groovy:489"

[Jacques Le Roux]

Hi Daniel,

I dont think there is a knowledge about methods being both services and events. 
I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log content (now 
in Docker);
so I wonder if there are such other cases than 
CommunicationEventServices::sendEmail  (colon notation is available in Groovy 3)
that bots and demo uses could have generated.

I tend to agree about having GroovyBaseScript::success deprecated and replaced with methods GroovyBaseScript::scriptSuccess 
GroovyBaseScript::serviceSuccess and GroovyCaseScript::eventSuccess


I'm not yet acquainted with Codernarc rules, but the changes in 
GroovyBaseScript seem straightforward.
And (hopefully) this should not be a big deal to change accordingly in scripts 
methods with the help of Codenarc, right ?

My 2 cts

Jacques

Le 19/04/2023 à 18:37, Daniel Watford a écrit :

Hello,

In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the code was
called.

The untyped nature of Groovy had allowed a certain degree of flexibility in
code that GroovyBaseScript#success could be relied upon to prepare a
response appropriate to the calling conventions of an event handler or
service implementation. However over the last decade, possibly driven by
increased use of linters/static analysers, we have seen a push back towards
explicit typing, particularly on public methods.

If we continue to adopt the guidance from static analysers and apply
explicit typing to public methods in our groovy code, then we need to avoid
the black box approach of GroovyBaseScript#success figuring out what
calling conventions (i.e. event or service) are in play and, instead, a
groovy method should be intentionally written as either a service or event
handler.

If we have cases where a groovy method is used to provide implementations
for both a service and an event handler, then we can employ a thin adapter
layer to convert the result type between the two calling conventions. Do we
know if many such cases currently exist in OFBiz?

My preference would be to see GroovyBaseScript#success deprecated and
replaced with methods along the lines of GroovyBaseScript#scriptSuccess and
GroovyCaseScript#eventSuccess that return a Map and String
respectively.

Thanks,

Dan.

On Wed, 19 Apr 2023 at 16:44, Jacques Le Roux
wrote:


Hi All,

At OFBIZ-12801, we had a discussion with Daniel and Gil about the
described issue (last comments there)
We are unsure of the best solution, so this thread to discuss and decide.

As Gil reported, Jacopo's comment of the related commit* contains

 <>

What would be your opinion about a best solution?

TIA

Jacques

*http://svn.apache.org/viewvc?view=revision=1298908

Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site

[Daniel Watford]

Hi Michael,

Those changes have been applied to trunk and release22.01. You should be
able to sync your repository fork and avoid the build failures related to
pushing docker images.

On Thu, 20 Apr 2023 at 11:42, Michael Brohl 
wrote:

> Hi Dan,
>
> sound good!
>
> I would propose to name the environment variable more explicitely, e.g.
> DO_DOCKER_PUSH. DO_PUSH sounds too broad to me.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 20.04.23 um 12:25 schrieb Daniel Watford:
> > Hi Michael,
> >
> > I have just reproduced the issue you raised at
> > https://github.com/danwatford/ofbiz-framework by resyncing trunk.
> >
> > Yes, we can (and should) make the problematic steps skippable/optional.
> >
> > If you drill into the GitHub Action you will probably find the failure
> > occurred at step, 'Build and push runtime docker image'.
> >
> > If you look at the GitHub Actions definition file,
> > $ofbiz-framework/.github/workflows/docker-image.yml, for the 'Build and
> > push runtime docker image' step (lines 89-96) we use an environment
> > variable to control whether the image is pushed to ghcr.io/apache/ofbiz.
> >
> > Currently we check to see if env.ACT is unset, but perhaps we should
> change
> > this to see if an environment variable similar to 'DO_PUSH' exists. We
> > would then set that environment variable of apache/ofbiz-framework, but
> it
> > would be unset on all forks.
> >
> > I'll raise a ticket.
> >
> > Dan.
> >
> >
> > On Thu, 20 Apr 2023 at 11:02, Michael Brohl 
> > wrote:
> >
> >> Hi Dan,
> >>
> >> the build integration to build docker images seems to break forks and
> >> therefore external repositories.
> >>
> >> When synching our fork, a git actions seems to chime in:
> >>
> >> ===
> >>
> >> Build and push docker images: All jobs have failed
> >> Build and push OFBiz docker container images
> >>
> >> Build and push docker images / Build and push OFBiz docker container
> images
> >> Failed in 4 minutes and 2 seconds
> >>
> >> docker-image.yaml
> >> on: push
> >>
> >> Annotations
> >> 1 error
> >> Build and push OFBiz docker container images
> >> buildx failed with: ERROR: denied: permission_denied: The requested
> >> installation does not exist.
> >>
> >> ===
> >>
> >> Is it possible to configure this in a way that this is optional or must
> >> be triggered explicitely?
> >>
> >> Thanks,
> >>
> >> Michael Brohl
> >>
> >> ecomify GmbH - www.ecomify.de
> >>
> >>
> >> Am 06.04.23 um 21:25 schrieb Daniel Watford:
> >>> Hello,
> >>>
> >>> We recently configured the demo-trunk site (
> >>> https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers
> >>> based on images built following commits to the ofbiz-framework trunk
> >> branch
> >>> (https://issues.apache.org/jira/browse/OFBIZ-12786)
> >>>
> >>> This work brought about some improvements in how containers are
> deployed,
> >>> particularly regarding the disabling of specified plugins when a
> >> container
> >>> is started up.
> >>>
> >>> The deployment also highlighted that memory constraints applied to the
> >>> ofbiz container were too low and that there was a bug in the logic used
> >> to
> >>> set the password for the tenant database. Both of these issues were
> >> quickly
> >>> resolved.
> >>>
> >>> Through deployment of the demo-trunk site as a container, we also
> >>> demonstrated how we can alter the configuration of an OFBiz instance at
> >>> runtime through the use of scripts which 'hook' into various stages of
> >> the
> >>> initialisation process. See the scripts used for demo-trunk here -
> >>>
> >>
> https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d
> >>>
> >>> LAZY CONSENSUS
> >>>
> >>> This email thread is to establish if we have a lazy consensus to
> >>> automatically build and publish container images for commits to the
> >>> ofbiz-framework release22.01 branch similar to what is currently
> >> configured
> >>> for the trunk branch. These container images will have container tags
> >> such
> >>> as release22.01-snapshot.
> >>>
> >>> Further, GitHub actions will also build container images in response to
> >>> tags, prefixed with 'release', being pushed to the release22.01 branch.
> >>> These containers will have container tags derived from the git tag. For
> >>> example, git tag 'release22.01.02' would result in a container tag of
> >>> '22.01.02'.
> >>>
> >>> This email thread is also to establish if we have lazy consensus to
> then
> >>> use the release22.01-snapshot container images for deployment of the
> >>> demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar
> to
> >>> what is currently in place for trunk. The container tags current used
> can
> >>> be seen here -
> >>> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz
> >>>
> >>> Using a container for deployment removes the need to have any
> >> dependencies
> >>> in place on the host OS used for the demo-next site. Dependencies 

Re: Create return till ...

[Jacques Le Roux]

Hi All,

I stumbled upon this thread by chance. Has finally something being done?

TIA

Jacques

Le 11/03/2019 à 12:39, Rishi Solanki a écrit :

I agree with the approach what Pierre suggested to go with
ProductCategoryAttribute and ProductAttribute. Because for range of
products we may need different default values. Also agree with Scott on the
point there must be flexibility at CSR end to override the rule based on
the reason of return and relationship with customer. That means, we should
not stop CSR to create return if days passed, and simply can popup the
message that number of days have been passed and if she still wants to
continue then she should be able to do that.

After inputs from all, my suggestion is to go for ProductCategoryAttribute
and ProductAttribute configuration but it should not stop CSR to
place/accept return. And simply inform her that number of days has been
passed.

Best Regards,
--
Rishi Solanki
Sr Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com
www.hotwax.co


On Mon, Mar 11, 2019 at 11:49 AM Suraj Khurana 
wrote:


Hello Scott,

Thank you so much for your response. Yes, this is the exact way it is been
managed currently.

Thing is, we need to improve customer experience and reduce customer
service reps work. The current approach is working but it totally depends
on business to business. Some of them may leave it on CSR, on the other
hand, some must be looking for a date (timespan) which can be used to not
allow returns for any specific order (ex returns are not allowed in stock
clearance).

Not making current flow as totally obsolete, but I guess we should have
something to support this as well OOTB.

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
*www.hotwax.co *






On Mon, Mar 11, 2019 at 7:31 AM Scott Gray 
wrote:


The ability to create a return doesn't necessarily mean that return will

be

accepted.  IMO this is a business process where human intervention is
required in order to maintain good customer relations.

Approving/declining

RMAs depend on a number of factors including:
- the reason for return
- length of time since purchase
- value of the purchase
- COGS
- lifetime value of the customer

A hard time limit can make sense when a customer simply changes their

mind

about the purchase and wishes to return it but I don't think any other

type

of return should be constrained by the system without input from customer
service reps.

IMO a better system would be to have information critical to the RMA
process (such as the items listed above) easily accessible to the CSR so
they can quick make a decision.  Having the system prevent customers from
even creating a return request because X number of days have passed could
well be a bad user experience for the customer.

If the implementation does proceed, I don't think ProductFacility would

be

a good place to store the information.  Multiple stores with different
rules could well be fulfilling the same products out of the same

warehouse

(particularly for international distribution).

Regards
Scott

On Sat, 9 Mar 2019 at 20:50, Suraj Khurana 
wrote:


Hello,

In OFBiz, we can create a return for order without checking when that

order

is placed, it might be years long.
IMO, we should have a field something like daysToReturn at product

store

level to allow creating return till after that much days of order
completion.

I could not find anything else relevant to this and this is a very

common

e-commerce scenario for any business.

Am I missing something?
Please share your thoughts on the same.

--
Best Regards
Suraj Khurana
TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
www.hotwax.co

Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site

[Michael Brohl]

Hi Dan,

sound good!

I would propose to name the environment variable more explicitely, e.g. 
DO_DOCKER_PUSH. DO_PUSH sounds too broad to me.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.04.23 um 12:25 schrieb Daniel Watford:

Hi Michael,

I have just reproduced the issue you raised at
https://github.com/danwatford/ofbiz-framework by resyncing trunk.

Yes, we can (and should) make the problematic steps skippable/optional.

If you drill into the GitHub Action you will probably find the failure
occurred at step, 'Build and push runtime docker image'.

If you look at the GitHub Actions definition file,
$ofbiz-framework/.github/workflows/docker-image.yml, for the 'Build and
push runtime docker image' step (lines 89-96) we use an environment
variable to control whether the image is pushed to ghcr.io/apache/ofbiz.

Currently we check to see if env.ACT is unset, but perhaps we should change
this to see if an environment variable similar to 'DO_PUSH' exists. We
would then set that environment variable of apache/ofbiz-framework, but it
would be unset on all forks.

I'll raise a ticket.

Dan.


On Thu, 20 Apr 2023 at 11:02, Michael Brohl 
wrote:


Hi Dan,

the build integration to build docker images seems to break forks and
therefore external repositories.

When synching our fork, a git actions seems to chime in:

===

Build and push docker images: All jobs have failed
Build and push OFBiz docker container images

Build and push docker images / Build and push OFBiz docker container images
Failed in 4 minutes and 2 seconds

docker-image.yaml
on: push

Annotations
1 error
Build and push OFBiz docker container images
buildx failed with: ERROR: denied: permission_denied: The requested
installation does not exist.

===

Is it possible to configure this in a way that this is optional or must
be triggered explicitely?

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 06.04.23 um 21:25 schrieb Daniel Watford:

Hello,

We recently configured the demo-trunk site (
https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers
based on images built following commits to the ofbiz-framework trunk

branch

(https://issues.apache.org/jira/browse/OFBIZ-12786)

This work brought about some improvements in how containers are deployed,
particularly regarding the disabling of specified plugins when a

container

is started up.

The deployment also highlighted that memory constraints applied to the
ofbiz container were too low and that there was a bug in the logic used

to

set the password for the tenant database. Both of these issues were

quickly

resolved.

Through deployment of the demo-trunk site as a container, we also
demonstrated how we can alter the configuration of an OFBiz instance at
runtime through the use of scripts which 'hook' into various stages of

the

initialisation process. See the scripts used for demo-trunk here -


https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d


LAZY CONSENSUS

This email thread is to establish if we have a lazy consensus to
automatically build and publish container images for commits to the
ofbiz-framework release22.01 branch similar to what is currently

configured

for the trunk branch. These container images will have container tags

such

as release22.01-snapshot.

Further, GitHub actions will also build container images in response to
tags, prefixed with 'release', being pushed to the release22.01 branch.
These containers will have container tags derived from the git tag. For
example, git tag 'release22.01.02' would result in a container tag of
'22.01.02'.

This email thread is also to establish if we have lazy consensus to then
use the release22.01-snapshot container images for deployment of the
demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar to
what is currently in place for trunk. The container tags current used can
be seen here -
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz

Using a container for deployment removes the need to have any

dependencies

in place on the host OS used for the demo-next site. Dependencies are not
an issue at the moment, but may become difficult to manage if and when we
want to vary the JDK used to build and run release22.01.

Container images produced by the GitHub Actions workflow will be

published

to the GitHub Container Registry (ghcr.io). They should only be

considered

as a convenience to users who wish to use containers. Container images

are

not an official release of the Apache OFBiz project. I am not proposing

to

alter any README files to refer to the container images at this time.

Thanks,

Dan.

Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site

[Daniel Watford]

Hi Michael,

I have just reproduced the issue you raised at
https://github.com/danwatford/ofbiz-framework by resyncing trunk.

Yes, we can (and should) make the problematic steps skippable/optional.

If you drill into the GitHub Action you will probably find the failure
occurred at step, 'Build and push runtime docker image'.

If you look at the GitHub Actions definition file,
$ofbiz-framework/.github/workflows/docker-image.yml, for the 'Build and
push runtime docker image' step (lines 89-96) we use an environment
variable to control whether the image is pushed to ghcr.io/apache/ofbiz.

Currently we check to see if env.ACT is unset, but perhaps we should change
this to see if an environment variable similar to 'DO_PUSH' exists. We
would then set that environment variable of apache/ofbiz-framework, but it
would be unset on all forks.

I'll raise a ticket.

Dan.


On Thu, 20 Apr 2023 at 11:02, Michael Brohl 
wrote:

> Hi Dan,
>
> the build integration to build docker images seems to break forks and
> therefore external repositories.
>
> When synching our fork, a git actions seems to chime in:
>
> ===
>
> Build and push docker images: All jobs have failed
> Build and push OFBiz docker container images
>
> Build and push docker images / Build and push OFBiz docker container images
> Failed in 4 minutes and 2 seconds
>
> docker-image.yaml
> on: push
>
> Annotations
> 1 error
> Build and push OFBiz docker container images
> buildx failed with: ERROR: denied: permission_denied: The requested
> installation does not exist.
>
> ===
>
> Is it possible to configure this in a way that this is optional or must
> be triggered explicitely?
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 06.04.23 um 21:25 schrieb Daniel Watford:
> > Hello,
> >
> > We recently configured the demo-trunk site (
> > https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers
> > based on images built following commits to the ofbiz-framework trunk
> branch
> > (https://issues.apache.org/jira/browse/OFBIZ-12786)
> >
> > This work brought about some improvements in how containers are deployed,
> > particularly regarding the disabling of specified plugins when a
> container
> > is started up.
> >
> > The deployment also highlighted that memory constraints applied to the
> > ofbiz container were too low and that there was a bug in the logic used
> to
> > set the password for the tenant database. Both of these issues were
> quickly
> > resolved.
> >
> > Through deployment of the demo-trunk site as a container, we also
> > demonstrated how we can alter the configuration of an OFBiz instance at
> > runtime through the use of scripts which 'hook' into various stages of
> the
> > initialisation process. See the scripts used for demo-trunk here -
> >
> https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d
> >
> >
> > LAZY CONSENSUS
> >
> > This email thread is to establish if we have a lazy consensus to
> > automatically build and publish container images for commits to the
> > ofbiz-framework release22.01 branch similar to what is currently
> configured
> > for the trunk branch. These container images will have container tags
> such
> > as release22.01-snapshot.
> >
> > Further, GitHub actions will also build container images in response to
> > tags, prefixed with 'release', being pushed to the release22.01 branch.
> > These containers will have container tags derived from the git tag. For
> > example, git tag 'release22.01.02' would result in a container tag of
> > '22.01.02'.
> >
> > This email thread is also to establish if we have lazy consensus to then
> > use the release22.01-snapshot container images for deployment of the
> > demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar to
> > what is currently in place for trunk. The container tags current used can
> > be seen here -
> > https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz
> >
> > Using a container for deployment removes the need to have any
> dependencies
> > in place on the host OS used for the demo-next site. Dependencies are not
> > an issue at the moment, but may become difficult to manage if and when we
> > want to vary the JDK used to build and run release22.01.
> >
> > Container images produced by the GitHub Actions workflow will be
> published
> > to the GitHub Container Registry (ghcr.io). They should only be
> considered
> > as a convenience to users who wish to use containers. Container images
> are
> > not an official release of the Apache OFBiz project. I am not proposing
> to
> > alter any README files to refer to the container images at this time.
> >
> > Thanks,
> >
> > Dan.
> >
>


-- 
Daniel Watford

Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site

[Michael Brohl]

Hi Dan,

the build integration to build docker images seems to break forks and 
therefore external repositories.


When synching our fork, a git actions seems to chime in:

===

Build and push docker images: All jobs have failed
Build and push OFBiz docker container images

Build and push docker images / Build and push OFBiz docker container images
Failed in 4 minutes and 2 seconds

docker-image.yaml
on: push

Annotations
1 error
Build and push OFBiz docker container images
buildx failed with: ERROR: denied: permission_denied: The requested 
installation does not exist.


===

Is it possible to configure this in a way that this is optional or must 
be triggered explicitely?


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 06.04.23 um 21:25 schrieb Daniel Watford:

Hello,

We recently configured the demo-trunk site (
https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers
based on images built following commits to the ofbiz-framework trunk branch
(https://issues.apache.org/jira/browse/OFBIZ-12786)

This work brought about some improvements in how containers are deployed,
particularly regarding the disabling of specified plugins when a container
is started up.

The deployment also highlighted that memory constraints applied to the
ofbiz container were too low and that there was a bug in the logic used to
set the password for the tenant database. Both of these issues were quickly
resolved.

Through deployment of the demo-trunk site as a container, we also
demonstrated how we can alter the configuration of an OFBiz instance at
runtime through the use of scripts which 'hook' into various stages of the
initialisation process. See the scripts used for demo-trunk here -
https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d


LAZY CONSENSUS

This email thread is to establish if we have a lazy consensus to
automatically build and publish container images for commits to the
ofbiz-framework release22.01 branch similar to what is currently configured
for the trunk branch. These container images will have container tags such
as release22.01-snapshot.

Further, GitHub actions will also build container images in response to
tags, prefixed with 'release', being pushed to the release22.01 branch.
These containers will have container tags derived from the git tag. For
example, git tag 'release22.01.02' would result in a container tag of
'22.01.02'.

This email thread is also to establish if we have lazy consensus to then
use the release22.01-snapshot container images for deployment of the
demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar to
what is currently in place for trunk. The container tags current used can
be seen here -
https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz

Using a container for deployment removes the need to have any dependencies
in place on the host OS used for the demo-next site. Dependencies are not
an issue at the moment, but may become difficult to manage if and when we
want to vary the JDK used to build and run release22.01.

Container images produced by the GitHub Actions workflow will be published
to the GitHub Container Registry (ghcr.io). They should only be considered
as a convenience to users who wish to use containers. Container images are
not an official release of the Apache OFBiz project. I am not proposing to
alter any README files to refer to the container images at this time.

Thanks,

Dan.

Re: OFBiz 22.01 - Eclipse - Issues on setting up a debugging environment.

[Michael Brohl]

We have a working solution with all tests passing for release22.01 and 
trunk, I have created a Jira issue to track the effort.


https://issues.apache.org/jira/browse/OFBIZ-12808

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 19.04.23 um 15:52 schrieb Michael Brohl:

Hi everyone,

it seems that we have a solution for the Eclipse Java build and 
runtime problems we faced with JDK 17 (not speaking of the Groovy 
build problems).


We removed some (transitive) dependencies in the build file and 
updated some of them so that libraries are used from the JDK instead 
of external libaries. This avoids the compiler from finding duplicate 
classes which seem to be ignored and therefore not being found also at 
runtime.


We are checking the changes with a project now and provide a pull 
request when we are sure everything works fine.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.04.23 um 21:53 schrieb Michael Brohl:

Thanks Jacques!

for me, 
org.eclipse.jdt.core.compiler.ignoreUnnamedModuleForSplitPackage only 
works as far as the build problems get away but there are still 
packages and classes not found by Eclipse at runtime so not really 
working for debugging here.


Additionally, I realized that the settings file is (re)generated by 
the Gradle eclipse task and the property vanished during the process. 
It would be necessary to add the setting during the build.


All in all, some kind of showstopper using OFBiz with JDK 17 and 
Eclipse which has to be solved somehow.


Thanks,

Michael

Am 14.04.23 um 16:50 schrieb Jacques Le Roux:

Hi Michael,

Yes I did some. I have still this issue* pending but it does not 
prevent to debug.


It's also a long time I'm not able to make breakpoints to work for 
groovy.
I must say I did not dig much because most of the time (so far all 
cases) a printl is enough.


* https://github.com/eclipse-jdt/eclipse.jdt/issues/57

HTH

Jacques

Le 14/04/2023 à 15:31, Michael Brohl a écrit :

Hi devs,

just to pull up this topic to get more attention:

is there anyone out there who has successfully imported a JDK 17 
based Apache OFBiz project into Eclipse and debugged from there?


Thanks and regards,

Michael


Am 16.02.23 um 17:59 schrieb Jacques Le Roux:

Hi,

It's a complicated matter due to indecision in an OpenJDK.

I'm curious to know if people using Intellij are crossing the same 
issue? That could explain why it has not been reported. Most OFBiz 
committers are using Intellij, I guess.


I looked at this issue some time ago and found that Eclipse 
compiler (used by UI to build the project) is not using the same 
way than javac.
That's why, as Cheng Hu Shan said: " OFBiz actually starts and is 
operating properly thanks to the backwards compatibility of Java"


It's a "philosophy" difference. I found it well explained in this 
stackoverflow answer (and links from there): 
https://s.apache.org/8n6op


You may also read 
https://stackoverflow.com/questions/55571046/eclipse-is-confused-by-imports-accessible-from-more-than-one-module


Anyway, I need to fix that myself and will look at the best option 
when I'll get a chance. I tried some w/o success so far, . It's 
very annoying in Eclipse UI.
The best way could be to follow the point 7 at 
https://www.eclipse.org/community/eclipse_newsletter/2018/june/java9andbeyond.php 
I did not try yet, just found it :)


HTH

Jacques

Le 16/02/2023 à 17:10, Cheng Hu Shan a écrit :

Hi,

I've encounterd the same problem. I cannot offer a solution. But 
maybe a better description of this problem may help you.


The root problem seems to be how the Java Platform Modular System 
introduced in version 9 and foreign libraries interact: Since 
Java 9 one particular package may only exists once in your entire 
project system, but if you import foreign libraries, they may 
bring their own version of a that package.


If you mouse over a faulty import statement in any of the java 
classes, you may find an error similiar to "The package [name] is 
accessible from more than one module:  java.xml". The 
 module refers to all foreign libraries stuffed into the 
classpath which counts as one huge unnamed module.


I'm surprised that this issue has not been reported yet, as it 
seems to be a fundamental one. My guess would be that we need to 
somehow update the build.gradle file.


On a side note: OfBiz actually starts and is operating properly 
thanks to the backwards compatiblity of Java, but the error 
messages remain.


Best regards,

Cheng Hu Shan


Am 14.02.23 um 23:15 schrieb Carlos Navarro:

Hello Community,

Hope you're all doing well.

I'm trying to setup OFBiz 22 and Eclipse in order to get a 
debugging

environment following
https://cwiki.apache.org/confluence/display/ofbiz/eclipse+tips

OFBiz version: 22.01
JDK: 17
Eclipse: Eclipse IDE for Enterprise Java and Web Developers 
(includes

Incubating components) Version: 2022-12 (4.26.0)
OS: Windows 10

However, as far as I import an existente OFBiz 22