Re: thank you OFBiz PMC and my goals for the project

[Michael Brohl]

Hi Eugen,

first of all, welcome on board!

Personally, I've voted you in as a committer because I see value in more 
people working on making OFBiz better, be it on the framework level or 
business logic / functionality. You have showed motivation and good 
thoughts about your plans for refactoring.


As I wrote before, I am in favour of having a proper process to work on 
the framwork refactorings and it definetely helps splitting the work in 
smaller chunks. We should also give us enough time to discuss and 
approve those PR's before they go into the codebase.


What's very important: there are many projects out there relying on 
OFBiz as a base for really complex projects with custom plugins using 
the framework as well. Breaking changes should be well documented and we 
should provide a migration guide for them from the beginning. I have 
made several vendor imports for those projects over the years and lack 
of documentation makes this process difficult, even if you closely 
follow what's going on in the community.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 26.09.24 um 23:56 schrieb Eugen Stan:

Hello,

I was recently offered to become a committer for OFBiz and I accepted.

I believe this was either because you enjoy my long emails or you dred 
them and decided to let me push my changes without bothering you :).


Whatever the motive, you have my gratitude.

Now onto OFBiz-niss :

I plan to do ~ 1 commit / month to OFBiz.
I have a todler and enjoy his company very much but that comes with 
limitted time for other things so this is what I can do for now.


My goals have not changed and I would like to start contributing to 
that direction.


I will strive to make a small PR / month ask it for review and then 
merge it.


I saw 24.09 was branched as stable and I guess trunk is up for merges 
(grabs).


My long term goal:
I will work to improve OFBiz project structure and split it into 
libraries that compound to an application so I and others can host and 
extend it with ease.


On the way I hope so improve/fix some/all of the issues bellow, and 
others (random order):


- https://issues.apache.org/jira/browse/OFBIZ-12308
- https://issues.apache.org/jira/browse/OFBIZ-12263
- https://issues.apache.org/jira/browse/OFBIZ-12401
- https://issues.apache.org/jira/browse/OFBIZ-9498
- https://issues.apache.org/jira/browse/OFBIZ-10407


For the short term goal, I will break the large PR in smaller pieces 
so they are easier to review 
https://github.com/apache/ofbiz-framework/pull/678 .


I believe I managed to get 3 libraries, so I expect to have ~ the same 
in the end.

- base/crypto
- base/util
- components/datafile

The libraries should probably be published so they can be used in 
external projects and OFBiz plugins.


After that the project will extensive changes to break the cyclic 
dependencies.


Thank you for your confidence.
I hope we can make OFBiz great for everyone.

Regards,
Eugen

Re: breaking ofbiz piece by piece - expose parts to outside

[Michael Brohl]

Hi Eugen,

I was still not able to review your efforts in-depth and I am most 
likely not able to do it in due time.


So here are some general thoughts.

Regarding the scope:

1. I am in favour of doing refactorings which are for the good of the 
Apache OFBiz project itself, e.g. removing circular dependencies and 
other flaws in the general architecture. To decide on those work items, 
we have to split them in working packages, describe the goals and 
implementation plan and discuss / decide if we want to do it in the project.


2. I am strongly against doing more refactorings which do not bring an 
advantage for the project and its users itself. For example, I do not 
see an advantage to make the entity engine a library which can be used 
in other projects/eco systems.


Those are massive changes, a lot of work and it likely will bring up new 
users who have no interest in Apache OFBiz itself but in the entity 
engine part. And they will ask for features which are not beneficial for 
Apache OFBiz. We already know that we are short on volunteers to 
maintain the project,  let alone additional libraries. We also have had 
experience with volunteers trying to change everything at once and who 
suddenly vanished from the project, leaving the effort in an unfinished 
state. That's a risk we have to put into account.


On the other hand, Apache OFBiz users are looking for features, 
stability and security, their benefit from those changes seems very 
small for me.


In our project, we should focus on the project to make it better with 
architecture, functionality and security etc. and deliver new releases 
for the users base in a more plannable way, but I strongly advise not to 
put too much burden on our shoulders with side projects.


To stick to the example: if someone wants to have a capsulated entity 
engine library to drop in into any other project, this should be a 
separate project.


Regarding the development approach:

1. we should definetely do massive code changes in the core architecture 
in feature branches and not in trunk. We are heading towards a more 
stable release roadmap with new release branches every year and if 
development on those changes is stale we will have a problem. So I am 
not seeing a massive PR merged into the codebase at once.


2. if we can focus on more tiny bits of change which can be delivered in 
a overseeable time and risk, we could decide to do them in trunk.


3. those changes should only be merged into trunk after extensive testing.

4. we should focus at one bigger code change at a time and not do more 
in parallel so that we have enough ressources to review / test them and 
focus on the general project / roadmap also.


To sum up: I appreciate your efforts on doing Apache OFBiz better and 
support those efforts if we can agree on a doable approach. However, I 
am in favor of a clear demarcation from changes that do not benefit the 
project itself.


I hope I have explained my thoughts well enough,

best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 06.09.24 um 17:46 schrieb Eugen Stan:

Hello,

It's been some time :) .
I saw the new release is about to happen and I was wondering if there 
is interest in moving forward with making OFBiz modular.


I am willing to split the big, scary PR in smaller bits that can be 
adopted / followed more easily. 
https://github.com/apache/ofbiz-framework/pull/678


But I am looking for a sponsor/champion to work with me and get them 
merged in OFBiz.
I don't want to work that is wasted - otherwise I would spend my time 
and energy elsewhere.


The plan would be:
- introduce empty gradle projects, one at a time
- move classes in smaller batches to these projects while keeping 
tests runnig


In the end we should have a few ofbiz libraries there that can be used 
from outside: like org.apache.ofbiz/component-datafile/18.12.10


Once this is done, we can re-evaluate the road ahead.
IMO the next milestone is to split entity-engine as a library so apps 
could read OFBiz data straight from DB - this should take OFBiz 
integration to a next level.


After that go for service-engine and after that for the applications 
themselves - but it's too far from today to know how things will look 
like.


So, who is willing to move ahead with this spend some time and review 
some PR's and merge them ?


I did see interest in the past from Jaques, Nicolas and Daniel :) .

Regards,
Eugen

La 22.03.2024 20:03, Eugen Stan a scris:

Hi Nicolas,

Thanks for the support. I do hope we get the ball roling at one point.

I won't be attending ApacheCon this year.
I think it's been 13 years since my last ApacheCon :).
Feel free to start merging changes.

Regards,
Eugen

La 22.03.2024 18:23, Nicolas Malin a scris:

Thanks both for your work and analyze !

I agree on the first point, we need to move forward to release the 
next OFBiz version and after we can breaking the wall :D


If the person are present a

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Michael Brohl]

+1

Thanks Nicolas,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 03.09.24 um 15:21 schrieb Nicolas Malin:

Hello,

After going through this thread [1], I propose to go ahead with the 
creation of the `release24` branch in a few weeks, and the release of 
the next official version 2 or 3 weeks later.


Why:
 * We've decided to leave release22.01 unpublished.
 * The trunk has been stable for a long time (integration tests are 
working well).

 * The current version is over 6 years old
 * If we wait another year for stabilization, there's a chance that a 
lot of work-in-progress will be added, and as with release 22, we'll 
probably miss the release stage.

 * We have a lot of work to do on the trunk :D

If there are no major objection, I'll put the release24 branch 
creation to the vote in a few days.


Nicolas

[1] https://lists.apache.org/thread/k903dobd1z0hm9qxo3prn8gzc71jrnx1

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.16 - Second attempt

[Michael Brohl]

+1

../ofbiz-tools/verify-ofbiz-release.sh -a apache-ofbiz-18.12.16 2>&1 | 
tee verify.log


Everything ok and build successful.

Tested on Mac OS 14.6.1 with Temurin-11.0.24+8 (build 11.0.24+8)

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 31.08.24 um 08:46 schrieb Jacopo Cappellato:

This is the second vote thread to publish "Apache OFBiz 18.12.16", the 16th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.16.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.16.zip.asc: the detached signature file
* apache-ofbiz-18.12.16.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.16
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.16

[Michael Brohl]

+1

../ofbiz-tools/verify-ofbiz-release.sh -a apache-ofbiz-18.12.16 2>&1 | 
tee verify.log


Everything ok and build successful.

Tested on Mac OS 14.6.1 with Temurin-11.0.24+8 (build 11.0.24+8)

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 28.08.24 um 12:35 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.16", the 16th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.16.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.16.zip.asc: the detached signature file
* apache-ofbiz-18.12.16.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.16
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - third attempt

[Michael Brohl]

+1

Verification and build on Mac OS 14.3.1 with JDK 11 works.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 19.07.24 um 15:31 schrieb Jacopo Cappellato:

This is the third vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Michael Brohl]

-1

I'm revoking my former vote, see security mailing list discussions.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 14.07.24 um 18:06 schrieb Michael Brohl:

+1

Verification on Mac OS 14.3.1 with JDK 11 works.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 11.07.24 um 10:52 schrieb Jacopo Cappellato:
This is the second vote thread to publish "Apache OFBiz 18.12.15", 
the 15th

release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.15 - second attempt

[Michael Brohl]

+1

Verification on Mac OS 14.3.1 with JDK 11 works.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 11.07.24 um 10:52 schrieb Jacopo Cappellato:

This is the second vote thread to publish "Apache OFBiz 18.12.15", the 15th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.15.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.15.zip.asc: the detached signature file
* apache-ofbiz-18.12.15.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.15
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Do we need both a menu and a button for same action?

[Michael Brohl]

For my point of view, see https://issues.apache.org/jira/browse/OFBIZ-13101

My main point is that we should handle permissions in the screens 
properly instead of just removing the functionality and only have them 
in the menu. To provide functionality within the context is important 
for usability.


Best regards,

Michael


Am 28.05.24 um 16:06 schrieb Jacques Le Roux:

Hi,

Mostly for a creating action, do we need both a menu and a button for 
same action? And if so why?


This has recently appeared at OFBIZ-13101, but IIRW some other cases 
where handled the same.


If we do so (both) we then need to handle the permissions correctly. 
For instance, a person with only the VIEW permission should not see 
these menu and button.
For now in some places if they click they see a message saying they 
are not authorised, better hide the possible click.


I guess we have much cases like that.

TIA

Jacques

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.14

[Michael Brohl]

+1

Everything is working fine on Mac OS Sonoma and JDK17

Thanks and regards,

Michael


Am 24.05.24 um 11:31 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.14", the 14th
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.14.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.14.zip.asc: the detached signature file
* apache-ofbiz-18.12.14.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.14
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Michael Brohl]

Hi everyone,

my main point for having a roadmap and (if necessary) freezing trunk 
(for a short time) before creating a release branch in the future was to 
avoid the situation we have now:


1. we agreed to create a new release branch some time ago

2. there were some open tasks which blocked 1., mainly brought up by 
Jacques if I remember correctly


3. suddenly there was a mass of new PR's which were merged in a hurry 
unneccesarily (my personal point of view), with some corrections soon after


4. 3. blocks 1. even further now because those changes are not 
complete/not rolled out for every component.


Instead of 3. we should have delayed merging those new features and 
worked on the blocking issues of 2. to be able to create a release from 
an almost stable trunk.


If we had a roadmap, I think we would have discussed 3. before it was 
happening and decided to wait merging those new features in favor of 
working on the creation of the new branch.


My approach is simply about some structure, coordination and 
collaboration to reach goals the project has defined instead of going 
with the flow of incoming pull requests.


I hope I was more clear now.

Thanks and regards,

Michael


Am 07.05.24 um 17:19 schrieb Pranay Pandey:

Hi Daniel,

I am in favor of creating a new release.

After we create a new release, IMO we shouldn't be committing any new
features there.

This is critical that we limit the scope of release with ongoing
development in the trunk.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 20:31, Daniel Watford  wrote:


Hi Jacques,

I'm sorry, but I can't quite parse your question, 'What is the
difference...'.   Could you restate it another way?

Are you asking what the difference is between enforcing a feature-freeze on
trunk versus continuing to allow all changes to trunk whilst having a
feature-freeze on a release branch (e.g. release-24.x)?

I think it will be very difficult to define a prescriptive policy on what
sort of fixes might be permitted on a release branch (e.g. release-24.x),
but the availability of committers to do the work of applying patches to
the branch might help us reach a de facto policy.

I personally would want to avoid backporting changes from trunk to a
release branch without good reason since I view this as duplicate work.
Therefore I would only want to backport fixes from trunk to release where
we have a defect that impacts users or if we felt that some new feature was
very very very important to OFBiz that it couldn't wait for the future
release branch.

If it helps, the project has used the phrase 'This series has been
stabilized with bug fixes since' on the Release History page:
https://downloads.apache.org/ofbiz/. I would interpret this as the release
branch was used to *stabilise* the features that were in trunk at the time
the release branch was created.

I fear that we all might be roughly in agreement but getting lost in the
weeds of discussion.

Should we go ahead and create a release-24.05 branch from trunk soon for
the purpose of stabilising a future release? Or are there any important
features that OFBiz developers want to see in trunk first?

As far as which commits are later applied to the release-24.05 branch,
shall we leave that up to the committers at the time, but with a reminder
that adding new features on the release-24.05 branch will increase the test
burden before a public release can be made?

Thanks,

Dan.

On Tue, 7 May 2024 at 15:20, Jacques Le Roux 
What is the difference between freezing the trunk in a release-24.xx

where

the rule is no improvements but if a consensus agrees with? In other

words,

apart exceptions only bugs and not only blockers,as we did so far and the
"new" proposition? Do we really wants to backport only blockerbugs? And
then
what is a blocker bug, only security?

Somehow related, I also remember we freezed the trunk in few branches

that

we never released. 14.12 and 15.12 come to mind:
https://ofbiz.apache.org/download.html

HTH

Jacques

Le 07/05/2024 à 15:11, Pranay Pandey a écrit :

Dear Daniel,

Thank you for outlining the proposed release strategy for OFBiz. I

liked

the idea of creating a new branch from trunk named 'release-24.05' to
address blockers for the upcoming release.

I agree with Michael's proposal that targeting a release while working

on

the trunk is worth considering. Maintaining a consistent flow of new
releases is crucial for project success. New releases with smaller

changes

are not only easier to adopt but also facilitate a smoother migration

for

existing ERP implementations, especially if users find value in the new
features introduced.

I believe this approach aligns well with the project's goals and will

help

in ensuring a structured and efficient release process. Let's continue

the

discussion on how we can further enhance this strategy to benefit the

OFBiz

development community.

Thank you for your efforts in driving this conversation forward.

Best regards,

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.13

[Michael Brohl]

+1

../ofbiz-tools/verify-ofbiz-release.sh -a apache-ofbiz-18.12.13 2>&1 | 
tee verify.log


-> Everything OK

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 30.04.24 um 17:06 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.13", the thirteenth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.13.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.13.zip.asc: the detached signature file
* apache-ofbiz-18.12.13.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.13
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

[PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Michael Brohl]

Hi everyone,

we agreed to work towards a stabilizing trunk to be able to create a 
24.x release branch, which means we have to thoroughly decide which 
changes should go into trunk. There are currently lots of changes going 
into trunk with PR's created and rapidly be merged into the codebase. 
This causes potential for errors being introduced in trunk, potentially 
leading to delay the creation of the next release branch even more.


In my opinion, this is contraproductive to the goal of creating a stable 
release branch 24.x in due time.


I propose to make a decision to have a code freeze for new features and 
improvements and focus on bug fixes until we have created a 24.x branch.


I also propose that we start organizing a roadmap to give the community 
some guidelines where to focus and which main features can be expected 
in the next release branches. It might also give developers some goals 
to provide the features according to planned releases and maybe work 
together to reach those project goals.


For example, there are some initiatives for Tomcat migration, 
introducing REST functionality in the framework and others which we can 
assign to future release branches. Maybe we can have a plan for a 25.x 
release branch which introduces those features.


I do not intend to make this an unflexible roadmap, means there can 
always be more planned/unplanned features be added to the roadmap and be 
discussed. We should have some deadlines for new features though, just 
to be able to create the next feature branch in the planned time periods.


What do you think?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Re: Discussion on OFBiz Tomcat upgrade

[Michael Brohl]

Hi,

as I said before, I would also favour creating a 24.x branch before we 
migrate to Tomcat 10.


I don't think 24.x must necessarily be released before we begin the 
migration (if that's what you meant with "released").


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 11.04.24 um 08:52 schrieb Daniel Watford:

Hello,

Checking the End-of-life announcements linked from
https://tomcat.apache.org/whichversion.html it looks like we should have
plenty of time before Tomcat 9 goes end-of-life.

We have quite a few changes/fixes we are trying to complete that are
blocking us from making a new release, so I am reluctant to pursue an
upgrade to Tomcat 10 until after 24.x is released.

My preference is to delay the Tomcat 10 upgrade until after OFBiz 24 is
released.

Thanks,

Dan.

On Thu, 11 Apr 2024 at 07:35, Nicolas Malin 
wrote:


Hi,

Thanks Gaetan to push this subject.

If we want keep OFBiz up to date, hence we need to realize this big step.

My preference go to freeze this migration, focus to release the next
stable branch (24.xx) and restart it after.

Nicolas

Le 10/04/2024 à 14:27, Gaetan a écrit :

Hi all. I'm opening a new thread to discuss the upgrade of the Tomcat
version used by OFBiz.

First, i pushed the task a bit hard without consulting the community
first, and i apologize for it. I got carried away.
The initial task came from a Prometheus plugin idea. [1]

There is a documentation provided by tomcat on how to do the basic
migration operations. [2]

My opinion is that it will have to be done at some point.
I don't have enough experience on OFBiz to know the full implications
of a Tomcat migration.
This one would be bigger even, because it would imply migrating from
javax package to jakarta package.

javax to jakarta change breaks some other things, such as JUEL
dependency.
Migration would be a lot of work and testing.

The advantages i see in migrating as soon as possible would be that we
could put it behind us.

Any thougts ? The ticket has been created some days ago [3]

[1] https://lists.apache.org/thread/jy7y96nmdr0rl43bss3sjm0jkcf2s2gz
[2] https://tomcat.apache.org/migration-10.html
[3] https://issues.apache.org/jira/browse/OFBIZ-12989

Re: Tomcat 10 Migration

[Michael Brohl]

Hi Gaetan,

in general, it seems to be a good idea to make this change (although I 
did not dig deeper into the breaking change/API change documentation).


In addition, I think we should first create a new release branch out of 
current trunk an try to put out a 24.x release this year. This would be 
the last Tomcat 9 based release series then.


Work on the Tomcat 10 migration could be made in a feature branch 
starting any time and be merged to trunk after creating the release 24.x 
branch, so that there would be no delay if you want to work on it soon.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 22.03.24 um 10:55 schrieb Gaetan:

Hello community,
We are thinking of building a Prometheus plugin the OFBiz. are 
thinking of using this library [1]
We already made a small POC. The problem is that we had to create a 
second HTTP server for this puspose only.
We thought about using the already existing Tomcat structure, but the 
library uses Tomcat 10, and OFBiz is Tomcat 9.
The migration will have to be made at some point, and this is the 
occasion for us to do it. There is a documentation that can be 
followed [2].


Is there any opposition ?

Gaetan and Nicolas.

[1] https://prometheus.github.io/client_java/

[2] https://tomcat.apache.org/migration-10.html 
<https://tomcat.apache.org/migration-10.html>

Re: Proposal: Merge ofbiz-plugins trunk HEAD into ofbiz-framework

[Michael Brohl]

Hi Dan,

just a short reply for now: you can easily integrate the plugins using a 
symlink to the plugins repository to check if changes in the framework 
are compatible with the plugins.


The plugins do not get as much support as the core framework and 
applications, I even would call some of them experimental. Some were 
also be switched off because of problems/security issues. They are 
optional enhancements and I think it is the right way to leave them in 
their own repository with one exception.


IMO, the rest-api Plugin should be merged into the framework as a core 
functionality after we have provided the enhancements we have developed 
over the last 2 years (still waiting for me to find time to provide a PR).


For the historical view, I would need more time to dig into the past 
discussions...


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 05.03.24 um 09:42 schrieb Daniel Watford:

Hello OFBiz developers,

I imagine this topic might be revisiting discussions that pre-date my
involvement with OFBiz so I would appreciate it if anyone can offer any
historical perspective on the separation of the ofbiz-framework and
ofbiz-plugins repository.

This is a proposal to merge the HEAD of the trunk branch of the
ofbiz-plugins repository into a directory within the ofbiz-framework
repository. We would then use build-time configuration to include or
exclude plugins from the build.

Currently the ofbiz-plugins repository is maintained by the main OFBiz
framework project's developers. As we make changes to a branch in
ofbiz-framework, we need to check that plugins continue to build in the
corresponding branch of the ofbiz-plugins repository. Having plugins in a
separate repository complicates this process and I'm sure it is often
overlooked by contributors to the project.

Further, our continuous integration processes need to checkout the relevant
branch from ofbiz-plugins when building ofbiz-framework. We have some
platform-specific scripts that carry out this process for us, but they are
not able to handle CI builds triggered by applying tags to ofbiz-framework.

Lastly, should an integrator wish to use one or more plugins from the
ofbiz-plugins repository in addition to their own plugins, there is some
confusion about how they arrange their own code alongside the ofbiz-plugins
repository.

Proposed changes:
- Copy repository content from the HEAD of the trunk branch from
ofbiz-plugins to a suitable directory in ofbiz-framework. Perhaps this
directory should be named ofbiz-plugins to help identify the contents as
being maintained by the project.
- Modify the build process to exclude the ofbiz-plugins directory from the
build by default. The ofbiz-plugins directory can be added to the build
through a gradle command line argument or setting.
- Set code checking thresholds (e.g. checkstyle) to levels that allow
inclusion of the new code.

Expected benefits:
- Contributors can more easily check their changes do not impact on the
building of ofbiz-plugins.
- The continuous integration builds do not need to run platform-specific
scripts to fetch plugin sources since the sources are already part of the
default checkout.
- Determining which branch/tag from the ofbiz-plugins repository
corresponds to the ofbiz-framework branch/tag being built by CI is no
longer an issue.
- We have one less repository to manage access/issues/PRs for.
- The set of ofbiz-plugins will have more visibility among OFBiz developers
- perhaps helping us decide which plugins the project no longer wishes to
be responsible for and should be removed from ofbiz-framework. These
plugins can be spun off into their own repository by any interested
maintainers.

Possible negatives:
- The ofbiz-framework repository size will increase due to additional code.
I'm not sure this is a major issue, particularly since the number of
contributions to ofbiz-plugins is low these days.
- The build process is more complicated for users wishing to include
plugins. We can mitigate this by documenting the (hopefully) single
modification needed to include ofbiz-plugins into the build.
- We undo whatever benefit was achieved by having a separate ofbiz-plugins
repository in the first place.

I'm sure there will be other benefits and negatives to consider. Please let
me know what you think.

Thanks,

Dan.

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.12 - third attempt

[Michael Brohl]

Hi Jacopo,

I think this is a false error message. If you compare the sha sums 
manually, there is no mismatch.


I have to check why the script shows an error but I think it should be 
no issue to prevent a release.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 25.02.24 um 19:11 schrieb Jacopo Cappellato:

apache-ofbiz-18.12.12.zip: 67AA5932 53FFF35F 3AA89DC9 73951B33 8396F95D
ECF26EBD 1DB58C66 50EE37E5 D053CD02 C9CB3FC4 B06D8CCC 747FAAA1 45B251CA
5F95A606 B1CC6C1A A8CBC42C
apache-ofbiz-18.12.12.zip: 67AA5932 53FFF35F 3AA89DC9 73951B33 8396F95D
ECF26EBD 1DB58C66 50EE37E5 D053CD02 C9CB3FC4 B06D8CCC 747FAAA1 45B251CA
5F95A606 B1CC6C1A A8CBC42C

Re: [VOTE] [RELEASE] Apache OFBiz 18.12.12 - second attempt

[Michael Brohl]

+1

../ofbiz-tools/verify-ofbiz-release.sh -a apache-ofbiz-18.12.12

Everything is OK

OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08)

Mac OS Sonoma 14.2.1


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 08.02.24 um 14:29 schrieb Jacopo Cappellato:

This is the vote thread, second attempt, to publish "Apache OFBiz
18.12.12", twelfth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.12.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.12.zip.asc: the detached signature file
* apache-ofbiz-18.12.12.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.12
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [GH] (ofbiz-framework): Workflow run "Java CI with Gradle" failed!

[Michael Brohl]

I see the problem: I have not had the plugins embedded during the test 
so the setMaxPriority3Violations were not exceeded.


Thanks,

Michael

Am 05.02.24 um 12:55 schrieb Jacques Le Roux:
If you compare the last in nightlies: 
https://nightlies.apache.org/ofbiz/trunk/codenarc.html
with the last locally, it's 3 priorities 3 (SpaceAfterOpeningBrace) in 
fixedasset package at line 144 of FixedAssetServices.groovy


So we pass from setMaxPriority3Violations(3979) in Gradle to 3982 with 
this commit.


At the moment BB is blocked because of 
https://issues.apache.org/jira/browse/INFRA-25465


HTH

Jacques

Le 05/02/2024 à 12:29, Michael Brohl a écrit :
The build says that there are CodeNarc rule violations found but when 
I locally run


./gradlew codenarcMain codenarcTest I got no errors.

Is there a way to view the check results in buildbot?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 05.02.24 um 10:21 schrieb GitBox:
The GitHub Actions job "Java CI with Gradle" on ofbiz-framework.git 
has failed.

Run started by GitHub user asfgit (triggered by asfgit).

Head commit for run:
c156ab44141ff166f6620e754ac01df00d5e8a1f / Michael Brohl 


Fixed: Missing package and syntax error in FixedAssetServices.groovy
(OFBIZ-12890)

Report URL: 
https://github.com/apache/ofbiz-framework/actions/runs/7782161538


With regards,
GitHub Actions via GitBox

Re: [GH] (ofbiz-framework): Workflow run "Java CI with Gradle" failed!

[Michael Brohl]

The build says that there are CodeNarc rule violations found but when I 
locally run


./gradlew codenarcMain codenarcTest I got no errors.

Is there a way to view the check results in buildbot?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 05.02.24 um 10:21 schrieb GitBox:

The GitHub Actions job "Java CI with Gradle" on ofbiz-framework.git has failed.
Run started by GitHub user asfgit (triggered by asfgit).

Head commit for run:
c156ab44141ff166f6620e754ac01df00d5e8a1f / Michael Brohl 
Fixed: Missing package and syntax error in FixedAssetServices.groovy
(OFBIZ-12890)

Report URL: https://github.com/apache/ofbiz-framework/actions/runs/7782161538

With regards,
GitHub Actions via GitBox

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Michael Brohl]

See https://issues.apache.org/jira/browse/OFBIZ-12888 and 
https://github.com/apache/ofbiz-framework/pull/687


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 04.02.24 um 11:43 schrieb Michael Brohl:


Hi,

I'm currently working on a solution for this.

Maybe someone can explain why we use the GroovyScripts source set for 
the codenarc checks in the pre-push hook:


gitHooks {

hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']

}

That target seems to be automatically defined through the source set 
definition for groovyScripts.


If I remove that source set and the following task configuration:

tasks.named('compileGroovyScriptsGroovy') {

// We don't want to build groovyScripts as they should be considered 
as standalone elements executed in


// isolation by ofbiz. Building them will result in numerous error due 
to duplicated classes.


enabled = false

}

And change the git hooks to

}

gitHooks {

hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']

}

(which is accoring to the pre-push hook definition in 
.git/hooks/pre-push)


everything seems to work fine, tests are working and the codenarc Main 
and Test reports are build.


I provide a PR for it.

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 04.02.24 um 08:25 schrieb Jacques Le Roux:

Hi Michael,

OK thanks, I'll have a look when I'll get a chance.

It's also weird that it works locally on both Ubuntu 20.04 and Win7 
and that BB fails. Anyway, so far BB is our guardian.


Jacques

Le 03/02/2024 à 23:36, Michael Brohl a écrit :

Hi Jacques,

the commit fixes an issue with the classpath generation of the 
"eclipse" gradle task which produces double entries for the 
"src/main/groovy" path.


The initial issue is caused by the "src/main/groovy" path set twice 
in build gradle, for the "main" and for the "groovyScripts" source 
sets. The second source set entry was removed and the build works as 
expected.


Instead of reverting the commit, the buildbot process should be 
checked and repaired. I guess that there is a configuration 
somewhere which relies on the path being present at a stage where it 
is not after the change. It looks like it has something to do with 
the codenarc tasks.


I am not familiar enough with the codenarc task to help with that, 
any help from others to have both issues fixed is appreciated.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 03.02.24 um 11:01 schrieb Jacques Le Roux:



Sorry, to allow BB to build, I had to revert this commit:
https://github.com/apache/ofbiz-framework/commit/a2f3ec88309f8440fe65b227ff3fc2df279dde24 



Please refer to INFRA-25456 for more information. I still don't 
understand why it works locally though, any idea?


Jacques

Le 02/02/2024 à 17:57, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/INFRA-25456 
for that


Jacques

Le 02/02/2024 à 14:14, build...@apache.org a écrit :

Build status: BUILD FAILED: failed Codenarc copied. (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/635
Blamelist: Michael Brohl , Michael Brohl 


Build Text: failed Codenarc copied. (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] 
625b80dbc626db35dddbaa62057e34b20ae7c38c



Steps:

   worker_preparation: 0

   git: 0

   pullAllPluginsSource: 0

   build: 0

   check: 0

   Copy checkstyle to destination directory structure: 0

   Copy codenarc to destination directory structure: 2

   clean things: 0


-- ASF Buildbot

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Michael Brohl]

Hi,

I'm currently working on a solution for this.

Maybe someone can explain why we use the GroovyScripts source set for 
the codenarc checks in the pre-push hook:


gitHooks {

hooks = ['pre-push': 'checkstyleMain codenarcGroovyScripts']

}

That target seems to be automatically defined through the source set 
definition for groovyScripts.


If I remove that source set and the following task configuration:

tasks.named('compileGroovyScriptsGroovy') {

// We don't want to build groovyScripts as they should be considered as 
standalone elements executed in


// isolation by ofbiz. Building them will result in numerous error due 
to duplicated classes.


enabled = false

}

And change the git hooks to

}

gitHooks {

hooks = ['pre-push': 'checkstyleMain codenarcMain codenarcTest']

}

(which is accoring to the pre-push hook definition in .git/hooks/pre-push)

everything seems to work fine, tests are working and the codenarc Main 
and Test reports are build.


I provide a PR for it.

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 04.02.24 um 08:25 schrieb Jacques Le Roux:

Hi Michael,

OK thanks, I'll have a look when I'll get a chance.

It's also weird that it works locally on both Ubuntu 20.04 and Win7 
and that BB fails. Anyway, so far BB is our guardian.


Jacques

Le 03/02/2024 à 23:36, Michael Brohl a écrit :

Hi Jacques,

the commit fixes an issue with the classpath generation of the 
"eclipse" gradle task which produces double entries for the 
"src/main/groovy" path.


The initial issue is caused by the "src/main/groovy" path set twice 
in build gradle, for the "main" and for the "groovyScripts" source 
sets. The second source set entry was removed and the build works as 
expected.


Instead of reverting the commit, the buildbot process should be 
checked and repaired. I guess that there is a configuration somewhere 
which relies on the path being present at a stage where it is not 
after the change. It looks like it has something to do with the 
codenarc tasks.


I am not familiar enough with the codenarc task to help with that, 
any help from others to have both issues fixed is appreciated.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 03.02.24 um 11:01 schrieb Jacques Le Roux:



Sorry, to allow BB to build, I had to revert this commit:
https://github.com/apache/ofbiz-framework/commit/a2f3ec88309f8440fe65b227ff3fc2df279dde24 



Please refer to INFRA-25456 for more information. I still don't 
understand why it works locally though, any idea?


Jacques

Le 02/02/2024 à 17:57, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/INFRA-25456 
for that


Jacques

Le 02/02/2024 à 14:14, build...@apache.org a écrit :

Build status: BUILD FAILED: failed Codenarc copied. (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/635
Blamelist: Michael Brohl , Michael Brohl 


Build Text: failed Codenarc copied. (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] 
625b80dbc626db35dddbaa62057e34b20ae7c38c



Steps:

   worker_preparation: 0

   git: 0

   pullAllPluginsSource: 0

   build: 0

   check: 0

   Copy checkstyle to destination directory structure: 0

   Copy codenarc to destination directory structure: 2

   clean things: 0


-- ASF Buildbot

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Michael Brohl]

Hi Jacques,

I'm currently working on a solution.

Michael


Am 04.02.24 um 08:25 schrieb Jacques Le Roux:

Hi Michael,

OK thanks, I'll have a look when I'll get a chance.

It's also weird that it works locally on both Ubuntu 20.04 and Win7 
and that BB fails. Anyway, so far BB is our guardian.


Jacques

Le 03/02/2024 à 23:36, Michael Brohl a écrit :

Hi Jacques,

the commit fixes an issue with the classpath generation of the 
"eclipse" gradle task which produces double entries for the 
"src/main/groovy" path.


The initial issue is caused by the "src/main/groovy" path set twice 
in build gradle, for the "main" and for the "groovyScripts" source 
sets. The second source set entry was removed and the build works as 
expected.


Instead of reverting the commit, the buildbot process should be 
checked and repaired. I guess that there is a configuration somewhere 
which relies on the path being present at a stage where it is not 
after the change. It looks like it has something to do with the 
codenarc tasks.


I am not familiar enough with the codenarc task to help with that, 
any help from others to have both issues fixed is appreciated.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 03.02.24 um 11:01 schrieb Jacques Le Roux:



Sorry, to allow BB to build, I had to revert this commit:
https://github.com/apache/ofbiz-framework/commit/a2f3ec88309f8440fe65b227ff3fc2df279dde24 



Please refer to INFRA-25456 for more information. I still don't 
understand why it works locally though, any idea?


Jacques

Le 02/02/2024 à 17:57, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/INFRA-25456 
for that


Jacques

Le 02/02/2024 à 14:14, build...@apache.org a écrit :

Build status: BUILD FAILED: failed Codenarc copied. (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/635
Blamelist: Michael Brohl , Michael Brohl 


Build Text: failed Codenarc copied. (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] 
625b80dbc626db35dddbaa62057e34b20ae7c38c



Steps:

   worker_preparation: 0

   git: 0

   pullAllPluginsSource: 0

   build: 0

   check: 0

   Copy checkstyle to destination directory structure: 0

   Copy codenarc to destination directory structure: 2

   clean things: 0


-- ASF Buildbot

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Michael Brohl]

Hi Jacques,

the commit fixes an issue with the classpath generation of the "eclipse" 
gradle task which produces double entries for the "src/main/groovy" path.


The initial issue is caused by the "src/main/groovy" path set twice in 
build gradle, for the "main" and for the "groovyScripts" source sets. 
The second source set entry was removed and the build works as expected.


Instead of reverting the commit, the buildbot process should be checked 
and repaired. I guess that there is a configuration somewhere which 
relies on the path being present at a stage where it is not after the 
change. It looks like it has something to do with the codenarc tasks.


I am not familiar enough with the codenarc task to help with that, any 
help from others to have both issues fixed is appreciated.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 03.02.24 um 11:01 schrieb Jacques Le Roux:

Hi Michael,

Sorry, to allow BB to build, I had to revert this commit:
https://github.com/apache/ofbiz-framework/commit/a2f3ec88309f8440fe65b227ff3fc2df279dde24 



Please refer to INFRA-25456 for more information. I still don't 
understand why it works locally though, any idea?


Jacques

Le 02/02/2024 à 17:57, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/INFRA-25456 for 
that


Jacques

Le 02/02/2024 à 14:14, build...@apache.org a écrit :

Build status: BUILD FAILED: failed Codenarc copied. (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/635
Blamelist: Michael Brohl , Michael Brohl 


Build Text: failed Codenarc copied. (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] 
625b80dbc626db35dddbaa62057e34b20ae7c38c



Steps:

   worker_preparation: 0

   git: 0

   pullAllPluginsSource: 0

   build: 0

   check: 0

   Copy checkstyle to destination directory structure: 0

   Copy codenarc to destination directory structure: 2

   clean things: 0


-- ASF Buildbot

Re: [VOTE] Release Apache OFBiz 18.12.12

[Michael Brohl]

+1

../ofbiz-tools/verify-ofbiz-release.sh -a apache-ofbiz-18.12.12

Everything is OK

OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08)

Mac OS Sonoma 14.2.1


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 13.01.24 um 20:17 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.12", twelfth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.12.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.12.zip.asc: the detached signature file
* apache-ofbiz-18.12.12.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.12
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] Release Apache OFBiz 18.12.11

[Michael Brohl]

+1

../ofbiz-tools/verify-ofbiz-release.sh  -a apache-ofbiz-18.12.11

Everything is OK

OpenJDK Runtime Environment (Temurin)(build 1.8.0_352-b08)

Mac OS Sonoma 14.12


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 16.12.23 um 11:02 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.11", eleventh
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.11.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.11.zip.asc: the detached signature file
* apache-ofbiz-18.12.11.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.11
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Time for the OFBiz 22.01.01 ?

[Michael Brohl]

Hi Nicolas,

given the time gone by I am thinking about if we should do an early 24.x 
release instead of 22.01. 22.01 sounds quite old with the year 2024 just 
a few days ahead.


But yes, it would be great to have a new stable release out soon.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 08.12.23 um 16:10 schrieb Nicolas Malin:

Hello all,

I know that I go out from my cave :D, there was a lot of work on the 
OFBiz improvement quality this year on groovy and deployment process.


I saw two issues [1][2] to solve before run a release process. Do you 
saw other element before try to release the 22.01.01 ?


Cheers,

Nicolas

[1] https://issues.apache.org/jira/browse/OFBIZ-12726
[2] https://issues.apache.org/jira/browse/OFBIZ-12868

Re: breaking ofbiz piece by piece - expose parts to outside

[Michael Brohl]

Hi Eugen,

can you give us some explanations/examples why this is a useful change?

What are the downsides?

I see a lot of changes in the base API like UtilValidate, UtilProperties 
etc. which will brake almost every custom project out there.


The changes also need explanation. For example: why the split of 
UtilValidate to UtilValidateEmpty etc.


I think we need to have very strong advantages to make those changes and 
currently I do not see them.


Thanks.

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 06.12.23 um 00:15 schrieb Eugen Stan:

Hello OFBiz devs,

I had some time to check out OFBiz again and I would like to propose 
some improvements to OFBiz.


The purpose is to split some independent parts from ofbiz so they can 
be used by other projects that wish to interact with OFBiz.


The main beneficiaries will be ofbiz related tooling IMO.

I believe I have identified two initial candidates for splitting:

- datafile component = "framework/datafile" - split as a project / 
library - usefull for tooling
- base/crypto - 
framework/base/src/main/java/org/apache/ofbiz/base/crypto - to do 
crypto in tooling compatible with ofbiz
- base/util - framework/base/src/main/java/org/apache/ofbiz/base/util 
- this is used across both of the above stuff


== How the split should happen and how it will look like:


Use gradle subprojects feature to define 3 subprojects in the 
ofbiz-framework git repo:

- base/utils
- base/crypto
- components/datafile

The projects will be standalone gradle projects that can be built 
individually and have dependencies.
https://docs.gradle.org/current/userguide/declaring_dependencies_between_subprojects.html 



Since these projects can build jar files, they can be published to 
maven to be consumed by other apps.
Since they are projects part of ofbiz-framework, they will participate 
as dependencies in the build.


I hope this can open the door to further refactoring and making OFBiz 
play nicer with outside developers.



After the change, the code should function the same with regards to 
normal OFBIz operations




It is somewhat related to 
https://issues.apache.org/jira/browse/OFBIZ-3500

Re: [VOTE] Apache OFBiz 18.12.09

[Michael Brohl]

Hi Jacopo,

my tests still fail. Might be a local issue but I do not have the time 
to dig in further.


I don't want to hinder the process so I withdraw my vote.

Thanks and regards,

Michael

Am 02.11.23 um 11:18 schrieb Jacopo Cappellato:

Hello Michael,

Yes, the plugins are included in all the releases of 18.12; for newer
release branches we can definitely revisit this decision (in fact I
think it would be nice to have framework only distributions).
As regards the build issues you have experimented, could you please
double check if they are consistent? If it is the case then we should
address them, otherwise I'd like to proceed with this release.

Thank you,

Jacopo

On Mon, Oct 30, 2023 at 2:42 PM Michael Brohl  wrote:

-1

The build fails with some exceptions for converters, solr-server and
others (see attached log).

I'm not completely sure but I do not expect the plugins to be shipped in
the framework distribution?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 29.10.23 um 13:16 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.09", ninth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.09.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.09.zip.asc: the detached signature file
* apache-ofbiz-18.12.09.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.09
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [VOTE] Apache OFBiz 18.12.09

[Michael Brohl]

-1

The build fails with some exceptions for converters, solr-server and 
others (see attached log).


I'm not completely sure but I do not expect the plugins to be shipped in 
the framework distribution?


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 29.10.23 um 13:16 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.09", ninth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.09.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.09.zip.asc: the detached signature file
* apache-ofbiz-18.12.09.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.09
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Issue with OFBiz Job Scheduler and Daylight Saving Time

[Michael Brohl]

+1

Thanks Deepak,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 30.10.23 um 14:03 schrieb Deepak Dixit:

The issue occurs when DST changes, and OFBiz fails to schedule recurring
jobs properly.
This is due to a condition in the PersistedServiceJob.createRecurrence
method where it compares the next scheduled time (next) with the start time
(startTime) for the job.


*Proposed Solution:*To address the issue, adding a new field named
JobSandbox.runTimeEpoch. This field would store the UTC epoch milliseconds
of the runtime date.
When scheduling or rescheduling recurring jobs, the system would use the
UTC epoch stored in JobSandbox.runTimeEpoch for recurring job comparison.

This solution ensures that the system uses a consistent, UTC-based time for
scheduling and rescheduling recurring jobs, even when DST changes affect
the local time.

To implement this solution, we need to do following things:

- Modify the PersistedServiceJob.createRecurrence method to calculate and
store the UTC epoch milliseconds in the JobSandbox.runTimeEpoch field.
- Update the code responsible for polling and rescheduling jobs to use the
JobSandbox.runTimeEpoch field when it is set. If the field is not set, It
would fall back to getting the runtime date to filter the jobs.

By using this approach, the system should be able to handle recurring job
scheduling more reliably, especially when DST changes are involved, as it
ensures that all time comparisons are made in a consistent UTC format.


Thanks & Regards
--
Deepak Dixit
ofbiz.apache.org


On Tue, Oct 17, 2023 at 11:00 AM Deepak Dixit  wrote:


Hi Dev,

I wanted to draw your attention to an issue we've encountered with the
OFBiz job scheduler, particularly when it comes to handling Daylight Saving
Time (DST) changes.

It appears that the job scheduler fails to create new recurring jobs when
DST ends, especially when the tempExprTypeId is set to FREQUENCY (e.g., 15
minutes, 30 minutes).

Upon further investigation, we've identified that the following condition
in PersistedServiceJob.createRecurrence might be the root of the issue:

java

if (next > startTime) {
 // ...
 // ...
}

I'm curious to know if anyone else has encountered a similar problem or if
you have any insights to share regarding this issue.

Thanks & Regards

--
Deepak Dixit
ofbiz.apache.org

Re: "Who We Are" Page

[Michael Brohl]

Hi Jacques,

sure.

Maybe we can generate the data base for it.

We should wait for the switch to Hugo though (which I know ist long due 
but I had not the time to finish it yet).


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 29.08.23 um 17:09 schrieb Jacques Le Roux:

Hi,

What do you think about adding a"Who We Are"* Page on the site using 
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+PMC+Members+and+Committers 
?


* https://apache.org/foundation/marks/linking#whoweare

Jacques

Re: Codenarc situation

[Michael Brohl]

Thanks Jacques!

Am 01.08.23 um 17:26 schrieb Jacques Le Roux:
Most of them indeed, there were though some remaining from previous 
Codenarc work


It's easily fixed using respectively these regexp in both repos

\Rpackage (.*)\R => package $1\R
\R\R\R => \R\R

Result:
codenarc {
 setConfigFile(new File('config/codenarc/codenarc.groovy'))
 setMaxPriority1Violations(0)
-    setMaxPriority2Violations(448)
-    setMaxPriority3Violations(4396)
+    setMaxPriority2Violations(439)
+    setMaxPriority3Violations(4216)

I push these changes

Jacques

Le 01/08/2023 à 17:17, Michael Brohl a écrit :
I think this is from the groovy refactoring. The package name was set 
under the License header with a single blank line.


Best would be to correct this with a script also.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 01.08.23 um 16:18 schrieb Jacques Le Roux:

Hi,

With last commit, 
https://ci2.apache.org/#/builders/46/builds/567/steps/4/logs/stdio, 
we have less priority 2 but more priority 3:


https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html

   <(p1=0; p2=439; p3=5249)>>


Compare with main build.gradle:

// Checks OFBiz Groovy coding conventions.
codenarc {
    setConfigFile(new File('config/codenarc/codenarc.groovy'))
    setMaxPriority1Violations(0)
    setMaxPriority2Violations(448)
    setMaxPriority3Violations(4396)
}

This is not blocking and according to 
https://github.com/apache/ofbiz-framework/commit/5d2301637f 
MaxPriorities has been fixed by the ones remaining in plugins (not 
only it seems)


At 1st glance, most new(?) are
"Blank line precedes package declaration in file 
FilterOutReceipts.groovy"

"File *.groovy has consecutive blank lines"

I'll change that and will let you know...

Jacques

Re: Codenarc situation

[Michael Brohl]

I think this is from the groovy refactoring. The package name was set 
under the License header with a single blank line.


Best would be to correct this with a script also.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 01.08.23 um 16:18 schrieb Jacques Le Roux:

Hi,

With last commit, 
https://ci2.apache.org/#/builders/46/builds/567/steps/4/logs/stdio, we 
have less priority 2 but more priority 3:


https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html

   <(p1=0; p2=439; p3=5249)>>


Compare with main build.gradle:

// Checks OFBiz Groovy coding conventions.
codenarc {
    setConfigFile(new File('config/codenarc/codenarc.groovy'))
    setMaxPriority1Violations(0)
    setMaxPriority2Violations(448)
    setMaxPriority3Violations(4396)
}

This is not blocking and according to 
https://github.com/apache/ofbiz-framework/commit/5d2301637f 
MaxPriorities has been fixed by the ones remaining in plugins (not 
only it seems)


At 1st glance, most new(?) are
"Blank line precedes package declaration in file 
FilterOutReceipts.groovy"

"File *.groovy has consecutive blank lines"

I'll change that and will let you know...

Jacques

Re: [GitHub] [ofbiz-framework]: Workflow run "Build and push docker images" failed!

[Michael Brohl]

I'll have a look, looks like we have a duplicate class now because of 
the Groovy refactoring.


Michael Brohl

ecomify GmbH - www.ecomify.de


Am 01.08.23 um 11:01 schrieb GitBox:

The GitHub Actions job "Build and push docker images" on ofbiz-framework.git 
has failed.
Run started by GitHub user mbrohl (triggered by mbrohl).

Head commit for run:
3e077e5f17b839d8cca88643e605975c2fc552c7 / Michael Brohl 

Fixed: Corrects groovy source folder location in build.gradle
(OFBIZ-12813)

Report URL: https://github.com/apache/ofbiz-framework/actions/runs/5724646734

With regards,
GitHub Actions via GitBox

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

[Michael Brohl]

Hi Jacques, Dan,

I believe your positions are not that far apart.

Jacques suggested to create a 23.09 branch which would happen in 
September 2023 and gives us 9 weeks from now. Dan suggested at least 4 
weeks to stabilize trunk before creating the branch.


I agree with you both: let's stabilize trunk in the next weeks with the 
goal to create a 23.09 branch. If we see that it will rather be 23.10, 
should be no problem.


I am working on the plugins and remaining framework issues. Wiebke has 
provided the scripts before going on vacation which are already prepared 
for plugins as well so I am confident that we will have a good 
foundation soon.


Thanks and regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 28.07.23 um 19:16 schrieb Jacques Le Roux:

Let's see what others think ;)

Le 28/07/2023 à 17:47, Daniel Watford a écrit :

Hi Jacques,

I would like to see a delay of at least 4 weeks to give interested 
parties

a chance to exercise the parts of OFBiz they are most familiar with.

I'm happy to be challenged on this, though. Choosing a reasonable 
amount of
time is a balance between duplicating work when resources are 
limited, and

moving the project forward. I don't think there is an obvious answer to
this one, so the maintainers will need to propose the branch when 
they feel

the time is right.

Although not expected to be the case, if we were to find lots of issues,
then we could delay creating the 23.xx branch accordingly.

On Fri, 28 Jul 2023 at 16:32, Jacques Le Roux 


wrote:


Hi Daniel,

Ho many time do you think we need?

Maybe a month is indeed short. Though actually the changes are pretty
simple and we should not cross much issues

Le 28/07/2023 à 17:17, Daniel Watford a écrit :

Hi Jacques,

Apologies if I've misunderstood your meaning, but I don't think we 
should

rush to create a 23.xx branch.

Following such a large refactor, we are likely to find issues in 
our use

of

groovy scripts over the coming weeks. If we go ahead and create a new

23.xx
branch from trunk too soon we will have to fix those groovy script 
issues

in trunk and the new branch - increasing the amount of work needed.

I agree that we want to get a 23.xx branch in place once we are happy

that
the groovy script refactor work has completed and had a chance to 
have a

few fixes applied.

Thanks,

Dan.

On Fri, 28 Jul 2023 at 16:08, Jacques Le Roux <

jacques.le.r...@les7arts.com>

wrote:


Le 03/05/2023 à 09:45, Jacopo Cappellato a écrit :

On Tue, May 2, 2023 at 9:17 AM Daniel Watford 

wrote:

[...]

I'll ask one more question (and then run for cover!): Rather than

carry

out

this work twice.  What if we abandon the 22.01 release and instead

make

a

new release branch (23.xx) soon after moving the Groovy sources?

Yes, we could do this. Abandon 22.01, perform the refactoring, 
create

a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

Hi,

In relation with [OFBIZ-12813] Refactor groovy folder structure 
and add

package declaration

As soon as a groovy file is modified, and especially moved, in trunk
(framework is done, plugins is waiting), it will be more hand work to
backport.
So I think we should indeed quickly think about creating a 23.xx

(23.09?)

release branch. Else if will be soon a nightmare to backport fixes.

Jacques

Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Michael Brohl]

Hi everyone,

short update: https://issues.apache.org/jira/browse/INFRA-24152

We made some progress migrating the website to Hugo but work has stalled 
because of higher priorities. The blog is now available through the 
archive https://blogsarchive.apache.org/#ofbiz until we finished the 
migration.


I'll keep you updated.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 01.03.23 um 13:44 schrieb Michael Brohl:

Hi everyone,

just a short update: we will start working on the migration of the 
website beginning mid March.


I hope that we can roll out the new website in April. I'll keep you 
updated.


Best regards,

Michael


Am 11.02.23 um 12:32 schrieb Michael Brohl:
See also https://issues.apache.org/jira/browse/INFRA-24152 for the 
infra migration Jira issue.


Michael Brohl

ecomify GmbH - www.ecomify.de


Am 07.02.23 um 19:06 schrieb Michael Brohl:

Dear community,

In the course of getting Wiebke to be able to help with our blog, it 
turned out that Apache Roller will be discontinued as the platform 
for blogs by infra [1].


There is an offer and already a pull request [2] to export the 
existing blog posts for a migration to Hugo [3].
Hugo is a static site generator which will generate individual pages 
from every markdown blog posts file which is provided in the PR.


That means we need to (at least)

- setup a Hugo project
- build up templates for the blog posts which also include header 
and footer for full page rendering
  (hence, we have to take over some of the templates/html 
code/javascrip/CSS to Hugo as well)

- generate the post pages and include them in the website under /blog.

These are quite some steps we have to take anyway and I ask myself 
if we should not switch over to Hugo for the whole website as well.
That should be not too difficult because we already have some kind 
of templates (in php) and there is already some sectioning with 
header, content, footer etc.


The advantages would be

- to truly separate content from the templates (it is now mixed 
php/content)
- blog posts can be generated from OFBiz commits and, together with 
page content, be send in by pull requests
- content automation (no need to change the copyright year manually, 
automated taxonimies for the blog etc.)
- easy process for a git supported writing process for pages and 
blog posts and a fast and automatable publishing process (git hooks 
or GitHub integration).


Coincidence: I am on a journey to migrate the ecomify websites to 
Hugo we have at least some knowledge there (maybe others as well?).


To sum up, I propose to migrate our blog and also the Apache OFBiz 
website to be an integrated, Hugo based website.


Opinions?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

[1] https://issues.apache.org/jira/browse/INFRA-22461
[2] https://github.com/apache/ofbiz-site/pull/8/files
[3] https://gohugo.io/

Re: [VOTE] Apache OFBiz 18.12.08

[Michael Brohl]

+1

Processing files for release: apache-ofbiz-18.12.08...
Downloading files for apache-ofbiz-18.12.08.zip...
...
Done!

Verifying files...
sha check of file: apache-ofbiz-18.12.08.zip
Using sha file: apache-ofbiz-18.12.08.zip.sha512
apache-ofbiz-18.12.08.zip: 6504F480 13109D2F 4DA5A90B 8C896549 DF642BF1 
85EA760F F29EC9BE ABD73D64 DB7A6CD6 404CB898 13BAA9BB 440CAB89 C236FC61 
AAD19730 B7B6BA7A E069D9B4
apache-ofbiz-18.12.08.zip: 6504F480 13109D2F 4DA5A90B 8C896549 DF642BF1 
85EA760F F29EC9BE ABD73D64 DB7A6CD6 404CB898 13BAA9BB 440CAB89 C236FC61 
AAD19730 B7B6BA7A E069D9B4


GPG verification output
gpg: Signature made Fri May 26 10:52:16 2023 CEST using RSA key ID 847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
" [ultimate]


Unpacking release file archive apache-ofbiz-18.12.08.zip...
Archive:  apache-ofbiz-18.12.08.zip
...

Initializing Gradle wrapper...
 === Prepare operation ===
/Users/mbrohl/Projects/apache-ofbiz/dist/apache-ofbiz-18.12.08/gradle/wrapper/gradle-wrapper.jar 
not found, we download it

 === Download gradle-wrapper.jar ===
 === Download gradle-wrapper.properties ===
 === Control downloaded files ===
...gradle/wrapper/gradle-wrapper.jar: OK
gradle/wrapper/gradle-wrapper.properties: OK
gradlew: OK
Running tests...
Downloading 
https://services.gradle.org/distributions/gradle-5.0-rc-5-bin.zip

.
Starting a Gradle Daemon (subsequent builds will be faster)
...
> Task :testIntegration

BUILD SUCCESSFUL in 7m 7s
30 actionable tasks: 25 executed, 5 up-to-date
Done processing files for release apache-ofbiz-18.12.08

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.05.23 um 11:33 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.08", eighth
release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.08.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.08.zip.asc: the detached signature file
* apache-ofbiz-18.12.08.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.08
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: [jira] [Commented] (OFBIZ-10478) Reducing scope of variables in org.apache.ofbiz.base package

[Michael Brohl]

Some more findings (not necessarily complete) are:

The method expandGeoGroup(GenericValue) from the type GeoWorker is not 
visible
The method isNonnegativeInteger(String) from the type UtilValidate is 
not visible
The method isPositiveInteger(String) from the type UtilValidate is not 
visible

The method secondsSinceStart() from the type UtilTimer is not visible
The method startTimer() from the type UtilTimer is not visible
The method stringToTimeStamp(String, String, TimeZone, Locale) from the 
type UtilDateTime is not visible
The method toDate(int, int, int, int, int, int) from the type 
UtilDateTime is not visible
The method toDate(String, String, String, String, String, String) from 
the type UtilDateTime is not visible
The method toDateString(Date, String) from the type UtilDateTime is not 
visible

The method toLongObject(Object) from the type UtilMisc is not visible

Regards,

Michael


Am 17.05.23 um 19:03 schrieb Michael Brohl:

Hi Jacques,

during a vendor import I noticed that there are several utul methods 
are being made private and therefore are not usable anymore.


Examples:

UtilDateTime#private static Timestamp getMonthStart(Timestamp stamp, 
int daysLater, int monthsLater, TimeZone timeZone, Locale locale)
StringUtil#private static Map strToMap(String str, 
String delim, boolean trim)


etc.

Can you explain why you reduced the scope?

Has there been any discussion to deprecate the public scope for those 
methods?


I'd suggest to revert those changes as it is not reasonable to make a 
small subset of those utility methods private.


Thanks,

Michael


Am 30.09.22 um 10:11 schrieb ASF subversion and git services (Jira):
 [ 
https://issues.apache.org/jira/browse/OFBIZ-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17611416#comment-17611416 
]


ASF subversion and git services commented on OFBIZ-10478:
-

Commit a1093281a48ba42e7e48438db9eb6deac89e7627 in ofbiz-framework's 
branch refs/heads/trunk from Jacques Le Roux
[ 
https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=a1093281a4 ]


Fixed: Reducing scope of variables in org.apache.ofbiz.base package 
(OFBIZ-10478)


Reverts several public to private changes that should not have been
runtime exception: java.lang.NoSuchMethodException



Reducing scope of variables in org.apache.ofbiz.base package


 Key: OFBIZ-10478
 URL: https://issues.apache.org/jira/browse/OFBIZ-10478
 Project: OFBiz
  Issue Type: Sub-task
  Components: base
    Affects Versions: Trunk, Upcoming Branch
    Reporter: Pradhan Yash Sharma
    Assignee: Jacques Le Roux
    Priority: Minor
 Fix For: Upcoming Branch

 Attachments: OFBIZ-10478.patch






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [jira] [Commented] (OFBIZ-10478) Reducing scope of variables in org.apache.ofbiz.base package

[Michael Brohl]

Hi Jacques,

during a vendor import I noticed that there are several utul methods are 
being made private and therefore are not usable anymore.


Examples:

UtilDateTime#private static Timestamp getMonthStart(Timestamp stamp, int 
daysLater, int monthsLater, TimeZone timeZone, Locale locale)
StringUtil#private static Map strToMap(String str, 
String delim, boolean trim)


etc.

Can you explain why you reduced the scope?

Has there been any discussion to deprecate the public scope for those 
methods?


I'd suggest to revert those changes as it is not reasonable to make a 
small subset of those utility methods private.


Thanks,

Michael


Am 30.09.22 um 10:11 schrieb ASF subversion and git services (Jira):

 [ 
https://issues.apache.org/jira/browse/OFBIZ-10478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17611416#comment-17611416
 ]

ASF subversion and git services commented on OFBIZ-10478:
-

Commit a1093281a48ba42e7e48438db9eb6deac89e7627 in ofbiz-framework's branch 
refs/heads/trunk from Jacques Le Roux
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=a1093281a4 ]

Fixed: Reducing scope of variables in org.apache.ofbiz.base package 
(OFBIZ-10478)

Reverts several public to private changes that should not have been
runtime exception: java.lang.NoSuchMethodException



Reducing scope of variables in org.apache.ofbiz.base package


 Key: OFBIZ-10478
 URL: https://issues.apache.org/jira/browse/OFBIZ-10478
 Project: OFBiz
  Issue Type: Sub-task
  Components: base
Affects Versions: Trunk, Upcoming Branch
Reporter: Pradhan Yash Sharma
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch

 Attachments: OFBIZ-10478.patch






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[Michael Brohl]

+1 from my side.

Best regards,

Michael


Am 03.05.23 um 09:45 schrieb Jacopo Cappellato:

On Tue, May 2, 2023 at 9:17 AM Daniel Watford  wrote:
[...]

I'll ask one more question (and then run for cover!): Rather than carry out
this work twice.  What if we abandon the 22.01 release and instead make a
new release branch (23.xx) soon after moving the Groovy sources?


Yes, we could do this. Abandon 22.01, perform the refactoring, create
a new release branch, stabilize (we could consider a shorter
stabilization period).
We could also extend our support (mostly for security vulnerability
fixes) to 18.12, at least until 1 or 2 releases have been published
out of the new branch.

Jacopo

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

[Michael Brohl]

se serviceFail(...) {...}
ServiceResponse serviceError(...) {...}

EventResponse eventSuccess(...) {...}
EventResponse eventFail(...) {...}
EventResponse eventError(...) {...}

//
// ExampleServiceAndEventImpl.groovy

// Here is the main implementation, initially implemented as a service
handler
ServiceResponse countProducts () {
...
...
return serviceSuccess([stock: 42])

// Here is the event handler implementation, leveraging the service
implementation as an adapter.
EventResponse countProductsEventHandler () {
  ServiceResponse sr = countProducts();
  return eventSuccess("Found ${sr.stock} products");
}

The return type of the above methods help identify whether we are dealing
with a service or event handler. If conversion is needed from one type to
the other, an adapter specific to the business logic can decide how to

map

between EventResponses and ServiceResponses.

Thanks,

Dan.

On Fri, 28 Apr 2023 at 14:27, Gil Portenseigne<

gil.portensei...@nereide.fr>

wrote:


Hello I got a quick look about it, having two separate class means
having two distinct groovy DSL and need lot of modification that IMO are
not worth the complexity for this subject.

I now only wonder, is it that bad too keep that one exception (about
untyped return) for GroovyBaseScript::success ?

Gil

Le 26/04/2023 à 09:49, Gil Portenseigne a écrit :

Hello,

I like the idea that the developer do not have to sync about which
method to use.

If I understand well what Michael envision, i.e. to use for event a
new GroovyBaseEvent class, and for services/scripts a GroovyBaseScript
class, that both extends a common class for the common code, should be
one way to allow this usage.

But I don't know about IDE integration behavior of such a solution...

Do you think that is worth a look ?

I will just add that there is a chance that project implementation are
using groovy script as the event target (I know some ;) )

Thanks,

Gil

Le 20/04/2023 à 17:13, Michael Brohl a écrit :

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 discussi

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

[Michael Brohl]

Hi everyone,

what do you think about this refactoring suggestion?

We would organize to do this work but won't start until the community 
decides to do so. It will be some amount of work so it should definetely 
be backed by the community.


Can we apply lazy consensus here or do we need some kind of voting?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.04.23 um 13:21 schrieb Michael Brohl:

Hi,

I suggest to start with a new ticket to coordinate the refactoring 
work (will you take this into your hands, Wiebke?).


OFBIZ-10226 has another intention which will not solve the overall 
problem Wiebke described.


Does the community agree that we'll have to do this work?

Even more, do we agree that it has to be done before we can ship a 
first 22.01 release based on JDK 17?


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.23 um 18:30 schrieb Jacques Le Roux:

Thanks Wiebke,

I know that for a while (https://s.apache.org/kewrn) but was 
desperately trying to avoid what you propose. It's indeed the right 
solution.


So I think we can go on with OFBIZ-10226. At the bottom there is a 
link to a related discussion with some opinions from then. Or do you 
prefer to start anew for the sake of clarity?


Thanks again for your work, I was not aware of this Groovy page. It 
definitely confirms what Mathieu said then.


Jacques

Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit :

Hi everyone,

I did a bit of research regarding the groovy debugging.
After some research I found this:

“The Java Platform Module System requires that classes in distinct 
modules have distinct package names. Groovy has its own "modules" 
but these haven’t historically been structured according to the 
above requirement. For this reason, Groovy 2.x and 3.0 should be 
added to the classpath not module path when using JDK9+. This places 
Groovy’s classes into the unnamed module where the split package 
naming requirement is not enforced.“
http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages 



For testing I used the service "sendEmailDated" in 
CommunicationEventServices.groovy. I can confirm the described 
behavior of Jacques, without a package declaration the service does 
not stop at my breakpoint. If I add the package declaration for the 
class, the service stops at my breakpoint.


From my point of view it would make sense for the project not only 
to add the package declaration in all groovy classes, but also to 
ensure a consistent folder structure.


For example, under framework -> base -> src there is a distinction 
between main and test. Within the test folder there is again a 
distinction between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, 
which means that there would be a src folder which in turn contains 
main, test, ... within these folders there is again a distinction 
between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> 
ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy 
-> org -> apache -> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb 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 

Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup

[Michael Brohl]

Thanks Daniel!

Best regards,

Michael

Am 27.04.23 um 09:14 schrieb Daniel Watford:

Hi Michael,

Demo-trunk and demo-next have now been refreshed with builds containing
OFBIZ-12808.

On Thu, 27 Apr 2023 at 07:40, Daniel Watford  wrote:


Hi Michael,

The demo instances do get updated overnight - around 02:35 from memory.

Just in case there was a race condition between the commits on
ofbiz-plugins vs ofbiz-framework, I've triggered a rebuild of the release
branch and trunk container images.

Once the re-build is complete I'll run the script to update the demo
instances with the new container images.

On Thu, 27 Apr 2023 at 07:28, Michael Brohl 
wrote:


Thanks all,

the fixes are implemented and merged for framework/plugins in the trunk
and release22.01 branches now.

When will those changes be deployed to the demo instances? Over night?

It would be helpful if someone can test framework and plugins on the
trunk and release22.01 demo instances to detect any runtime problems
caused by the dependency changes.

For plugins, changes were being made in the BIRT and LDAP components.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.04.23 um 17:24 schrieb Gil Portenseigne:

+1

Gil

Le 26/04/2023 à 16:36, Jacques Le Roux a écrit :

+1

Jacques

Le 26/04/2023 à 16:01, Jacopo Cappellato a écrit :

+1

Jacopo

On Wed, Apr 26, 2023 at 3:11 PM Michael Brohl
 wrote:

Hi everyone,

any objections against merging those pr's for framework/plugins in
trunk/release22.01?

I think it would be good to test the changes on the demo servers as
well
to detect possible runtime problems caused by the changed
dependencies.

If there are no objections, I would like to merge the changes
tomorrow.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira):

   [


https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714986#comment-17714986

]

Michael Brohl commented on OFBIZ-12808:
---

Fixes for framework / plugins for trunk and release22.01 are now
in the pull requests.

To test, the corresponding pr's for framework and plugins have to
be checked out respectively.


Eclipse build problems and proper dependency setup
--

   Key: OFBIZ-12808
   URL:
https://issues.apache.org/jira/browse/OFBIZ-12808
   Project: OFBiz
Issue Type: Bug
Components: ALL APPLICATIONS, ALL COMPONENTS, ALL

PLUGINS

  Affects Versions: 22.01.01, Upcoming Branch
      Reporter: Michael Brohl
      Assignee: Michael Brohl
  Priority: Major
   Fix For: 22.01.01, Upcoming Branch


Due to improper dependency configurations and the JPMS (Java
Plattform Module System) which was introduced to Java since
version 9, the Eclipse build and running/debugging is not working
with JDK 17 (trunk and release22.01).
The reason is that there are dependencies to libraries which are
also shipped with the JDK which causes a conflict leading to
ignore those packages/classes in the build.
We have a working solution for this.

--
This message was sent by Atlassian Jira
(v8.20.10#820010)


--
Daniel Watford

Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup

[Michael Brohl]

Thanks all,

the fixes are implemented and merged for framework/plugins in the trunk 
and release22.01 branches now.


When will those changes be deployed to the demo instances? Over night?

It would be helpful if someone can test framework and plugins on the 
trunk and release22.01 demo instances to detect any runtime problems 
caused by the dependency changes.


For plugins, changes were being made in the BIRT and LDAP components.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 26.04.23 um 17:24 schrieb Gil Portenseigne:

+1

Gil

Le 26/04/2023 à 16:36, Jacques Le Roux a écrit :

+1

Jacques

Le 26/04/2023 à 16:01, Jacopo Cappellato a écrit :

+1

Jacopo

On Wed, Apr 26, 2023 at 3:11 PM Michael Brohl 
 wrote:

Hi everyone,

any objections against merging those pr's for framework/plugins in
trunk/release22.01?

I think it would be good to test the changes on the demo servers as 
well
to detect possible runtime problems caused by the changed 
dependencies.


If there are no objections, I would like to merge the changes 
tomorrow.


Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira):
  [ 
https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714986#comment-17714986 
]


Michael Brohl commented on OFBIZ-12808:
---

Fixes for framework / plugins for trunk and release22.01 are now 
in the pull requests.


To test, the corresponding pr's for framework and plugins have to 
be checked out respectively.



Eclipse build problems and proper dependency setup
--

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

  Project: OFBiz
   Issue Type: Bug
   Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS
 Affects Versions: 22.01.01, Upcoming Branch
     Reporter: Michael Brohl
     Assignee: Michael Brohl
 Priority: Major
  Fix For: 22.01.01, Upcoming Branch


Due to improper dependency configurations and the JPMS (Java 
Plattform Module System) which was introduced to Java since 
version 9, the Eclipse build and running/debugging is not working 
with JDK 17 (trunk and release22.01).
The reason is that there are dependencies to libraries which are 
also shipped with the JDK which causes a conflict leading to 
ignore those packages/classes in the build.

We have a working solution for this.


--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [jira] [Commented] (OFBIZ-12808) Eclipse build problems and proper dependency setup

[Michael Brohl]

Hi everyone,

any objections against merging those pr's for framework/plugins in 
trunk/release22.01?


I think it would be good to test the changes on the demo servers as well 
to detect possible runtime problems caused by the changed dependencies.


If there are no objections, I would like to merge the changes tomorrow.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 21.04.23 um 14:54 schrieb Michael Brohl (Jira):

 [ 
https://issues.apache.org/jira/browse/OFBIZ-12808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17714986#comment-17714986
 ]

Michael Brohl commented on OFBIZ-12808:
---

Fixes for framework / plugins for trunk and release22.01 are now in the pull 
requests.

To test, the corresponding pr's for framework and plugins have to be checked 
out respectively.


Eclipse build problems and proper dependency setup
--

 Key: OFBIZ-12808
 URL: https://issues.apache.org/jira/browse/OFBIZ-12808
 Project: OFBiz
  Issue Type: Bug
  Components: ALL APPLICATIONS, ALL COMPONENTS, ALL PLUGINS
Affects Versions: 22.01.01, Upcoming Branch
Reporter: Michael Brohl
Assignee: Michael Brohl
Priority: Major
 Fix For: 22.01.01, Upcoming Branch


Due to improper dependency configurations and the JPMS (Java Plattform Module 
System) which was introduced to Java since version 9, the Eclipse build and 
running/debugging is not working with JDK 17 (trunk and release22.01).
The reason is that there are dependencies to libraries which are also shipped 
with the JDK which causes a conflict leading to ignore those packages/classes 
in the build.
We have a working solution for this.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[Michael Brohl]

Hi,

I suggest to start with a new ticket to coordinate the refactoring work 
(will you take this into your hands, Wiebke?).


OFBIZ-10226 has another intention which will not solve the overall 
problem Wiebke described.


Does the community agree that we'll have to do this work?

Even more, do we agree that it has to be done before we can ship a first 
22.01 release based on JDK 17?


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 25.04.23 um 18:30 schrieb Jacques Le Roux:

Thanks Wiebke,

I know that for a while (https://s.apache.org/kewrn) but was 
desperately trying to avoid what you propose. It's indeed the right 
solution.


So I think we can go on with OFBIZ-10226. At the bottom there is a 
link to a related discussion with some opinions from then. Or do you 
prefer to start anew for the sake of clarity?


Thanks again for your work, I was not aware of this Groovy page. It 
definitely confirms what Mathieu said then.


Jacques

Le 25/04/2023 à 16:09, Wiebke Pätzold a écrit :

Hi everyone,

I did a bit of research regarding the groovy debugging.
After some research I found this:

“The Java Platform Module System requires that classes in distinct 
modules have distinct package names. Groovy has its own "modules" but 
these haven’t historically been structured according to the above 
requirement. For this reason, Groovy 2.x and 3.0 should be added to 
the classpath not module path when using JDK9+. This places Groovy’s 
classes into the unnamed module where the split package naming 
requirement is not enforced.“
http://groovy-lang.org/releasenotes/groovy-3.0.html#Groovy3.0releasenotes-Splitpackages 



For testing I used the service "sendEmailDated" in 
CommunicationEventServices.groovy. I can confirm the described 
behavior of Jacques, without a package declaration the service does 
not stop at my breakpoint. If I add the package declaration for the 
class, the service stops at my breakpoint.


From my point of view it would make sense for the project not only to 
add the package declaration in all groovy classes, but also to ensure 
a consistent folder structure.


For example, under framework -> base -> src there is a distinction 
between main and test. Within the test folder there is again a 
distinction between groovy and Java.


Therefore I would suggest to introduce this structure everywhere, 
which means that there would be a src folder which in turn contains 
main, test, ... within these folders there is again a distinction 
between groovy and java.


Example:
applications -> product -> src -> main -> groovy -> org -> apache -> 
ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...
  -> test -> groovy 
-> org -> apache -> ofbiz ->...

-> java  -> org -> apache -> ofbiz ->...


What do you think about this idea?

Best regards,
Wiebke

ecomify GmbH - www.ecomify.de



Am 20.04.23 um 11:46 schrieb 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

HT

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&revision=1298908

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

[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) V

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

[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 Eclipse 
project, there
are a lot of errors (that I have have not experienced with OFBiz 
18).


Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot b

Re: Need help finding where JCrop is used

[Michael Brohl]

I think there is some functionality in the field of (product) content 
management to automatically resize images.


Has this anyting to do with it?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 19.04.23 um 08:17 schrieb Daniel Watford:

Thanks Jacques and Jacopo for your responses.

Jacques, like you I found the path to the functionality through
controller.xml, but was not able to find any path through the UI that a
user would take to make use of the functionality.

This leads me to believe the Jcrop (and other associated) functionality is
no longer in use and, like Jacopo said, it is acceptable to remove it from
the OFBiz sources. I'll raise a ticket separate to the other npm work to do
this.

Thanks,

Dan.

On Tue, 18 Apr 2023 at 11:00, Jacopo Cappellato 
wrote:


Hello,

For cases like this one, i.e. an external dependency from old code
that is only partially functional for a long time, I think it is
acceptable to remove it (if its presence is making it more difficult
to do some new work or refactoring).

Jacopo

On Mon, Apr 17, 2023 at 7:25 PM Jacques Le Roux
 wrote:

Hi Daniel,

It's used in ImageCrop.ftl. Itself used in 

inside ImageManagementScreens.xml

There is a  and a 
name="ImageCropping" inside ImageManagementForms.xml related to 
uri="CropImage">, etc.

I guess it's used to resize images but it does not seems to work well

(at least a jpg file was blurred)

This was initially put in in 2010 : https://s.apache.org/ak8s6 (can be

seen in https://markmail.org/message/udi25j4wyqyrowcu)

Not sure of the current quality

HTH

Jacques

Le 17/04/2023 à 13:43, Daniel Watford a écrit :

Hello,

As part of https://issues.apache.org/jira/browse/OFBIZ-12789 I wanted

to

understand how the javascript library jcrop was being used by OFBiz.

This

is so I can ensure any replacement library sourced from npm would

continue

to work correctly.

I have found the various screen and form definitions
(ImageManagementScreens and ImageManagementForms) in
applications/product/widget/catalog, but cannot find any path through

the

UI that would take a user to these screens.

I have found the Image Management sub-application under
https://localhost:8443/catalog/control/Imagemanagement, but this

screen

does not appear to make use of image cropping or resizing.

Please could someone guide me to the correct part of the UI where
jquery.jcrop.js is used? Or perhaps this functionality was removed at

some

point and we just have some old library files let in the OFBiz sources

that

can be cleaned up?

Thanks,

Dan.

Re: Moving node/npm to sub-projects. Should we apply to release22.01

[Michael Brohl]

+1 from my side bringing this to the 22.01 branch as well.

Thanks for the work and initiative, Daniel.

Best regards,

Michael


Am 14.04.23 um 16:59 schrieb Jacques Le Roux:

Hi Ingo,

Your message has been moderated, else it would not have reached this 
Mailing List.


Please subscribe to the MLs: http://ofbiz.apache.org/mailing-lists.html.

Thanks

Jacques

Le 14/04/2023 à 13:01, Ingo Richter a écrit :

Hey,

Sadly I do not have the time right now to check the changes but I 
wanted to chime in on the proposal to apply them to release 22.01:


I agree with Daniels opinion on frontend plugins that do not only 
profit very much from NPM but also benefit from the ability to apply 
different versions of the same plugin on a plugin-basis. There might 
be one plugin running on a frontend library of a different version 
than a second plugin were an update to the same version might just 
not be viable. The proposed changes make it possible to use NPM in 
both plugins simultaneously.


While the integration of NPM into OFBiz 22.01 is already a huge 
benefit, Daniels changes make it usable for OFBiz based frontend 
applications as well which - in my opinion - should not be delayed to 
a future release.


Thanks for your efforts, Daniel!

Ingo


Am 14.04.23 um 09:11 schrieb Daniel Watford:

Hello,

As part of working on OFBIZ-12789 to see if we could further utilise 
NPM as
a repository of various javascript modules rather than keep those 
modules'
sources in the OFBiz source repository, I went down a bit of a 
rabbit hole
changing the OFBiz build to allow node/npm use in multiple OFBiz 
components

(gradle sub-projects).

My aim was to allow a plugin to be able to use npm modules without 
having
to modify the ofbiz-framework parent build.gradle file. The current 
use of

npm for common-theme involves configuration applied in the root
build.gradle file.

The result was a 'convention' plugin, created in 
ofbiz-framework/buildSrc
which describes how the Gradle Node Plugin should be applied to a 
gradle
project. OFBiz components wishing to use node when building can 
'apply' the

ofbiz-node-conventions plugin to their gradle sub-project which will:
- apply and configure the com.github.node-gradle plugin
- configure the plugin to use 'npm install' or 'npm ci' depending on 
if the

CI environment variable is defined.
- run 'npm install/ci' as part of the 'classes' parent gradle task,
ensuring npm modules have been retrieved regardless of whether 
gradle is

being used to build, run or create a distribution of OFBiz.
- clean up retrieved node_modules as part of the parent project's
'cleanAll' task.

These changes can be viewed in PR (
https://github.com/apache/ofbiz-framework/pull/621).

[
Note: Gradle documents relating to 'convention' plugins:   -
https://docs.gradle.org/current/samples/sample_convention_plugins.html
  -
https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:build_sources 


]

A corresponding PR has been created for ofbiz-plugins (
https://github.com/apache/ofbiz-plugins/pull/77). This PR introduces a
change to the example plugin to demonstrate use of the Gradle Node 
Plugin

in an OFBiz plugin component.

In the case of the example plugin, a small Typescript React web
application, created using Vite, has been integrated to show an OFBiz
screen can be rendered to include CSS and javascript created by an npm
build step. If there is an appetite to keep this functionality in the
example plugin, perhaps we can extend the react app to call the REST 
api to

retrieve and display live OFBiz data.

I think these changes will be very useful for plugins which need to
incorporate a web front-end, such as eCommerce, rest-api (swagger), 
solr

and webpos. These plugins all use some externally sourced javascript
modules which should hopefully be available from NPM. In my opinion it
would be great to get these modules out of the OFBiz sources and 
retrieve

them at build time.


QUESTIONS

Any concerns about this approach to retrieving javascript code at build
time? We already decided to take this approach with common-theme, but
applying the pattern more widely will increase the time it takes to 
perform

an initial build. Subsequent builds should be faster since node_modules
would have already been downloaded by all components using the build
pattern.


Should we apply these changes to Release 22.01?
I would like to do so as I think it will make it easier for system
integrators to deploy more feature rich plugins with OFBiz. However 
I do

appreciate that we need to stop making changes to 22.01 at some point
otherwise we'll keep delaying its eventual release. However again, 
if these
changes are useful for system integrators, then it could be years 
before

they can use them in a future 23.xx/24.xx release.

Please give the PRs a try and let me know what you think.

Thanks,

Dan.

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

[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 Eclipse project, 
there

are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 527

Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToX

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

[Michael Brohl]

Hi Daniel,

thanks for your reply!

Are you aware that you can get a free license being an Open Source 
Commiter at the ASF? See 
https://www.jetbrains.com/community/opensource/#support .


I have OFBiz up and running with IntelliJ Idea which works flawlessly 
but we are mainly using Eclipse for the whole team and trying to get it 
running there also.


Best regards,

Michael

Am 14.04.23 um 17:33 schrieb Daniel Watford:

Hi Michael,

I did try getting Eclipse up and running a few weeks ago for OFBiz but
failed, unfortunately.

Following up from Jacques, I think Groovy debugging is going to be a really
important feature for an OFBiz Developers' IDE since so much of our
minilang is getting converted to Groovy scripts. Using IntelliJ 'just
works'.

I let my IntelliJ Ultimate license lapse a while ago so recently updated to
the latest Community edition. The only thing missing from the IntelliJ
Community edition for my work was Freemarker Template support.

Every now and then I try using VS Code for OFBiz development but have not
been successful so far. Groovy/Gradle support is not there in vscode at the
moment and, as mentioned for Eclipse, I think we really need good Groovy
support in our IDE to develop OFBiz effectively.

It's a shame about vscode as the ability to run your development
environment inside a container or in WSL2 is really useful.

So, apologies that I haven't really answered the original question and have
gone slightly off topic, but my recommendation is to give IntelliJ a try.

Dan.


On Fri, 14 Apr 2023 at 15:50, Jacques Le Roux 
wrote:


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-

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

[Michael Brohl]

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 Eclipse project, 
there

are a lot of errors (that I have have not experienced with OFBiz 18).

Here are some of them (100 of 3967 errors):


Description Resource Path Location Type
Attributes cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 527

Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 164 Java Problem
Comment cannot be resolved to a type LabelManagerFactory.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 169 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 128 Java Problem
Comment cannot be resolved to a type SaveLabelsToXmlFile.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools/labelmanager 


line 143 Java Problem
Comment cannot be resolved to a type WebToolsDbEvents.java
/ofbiz/framework/webtools/src/main/java/org/apache/ofbiz/webtools 
line 99

Java Problem
DefaultHandler cannot be resolved to a type EntitySaxReader.java
/ofbiz/framework/entity/src/main/java/org/apache/ofbiz/entity/util 
line 75

Java Problem
DefaultHandler cannot be resolved to a type WebAppUtil.java
/ofbiz/framework/webapp/src/main/java/org/apache/ofbiz/webapp line 
261 Java

Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security 
line 115

Java Problem
DocumentBuilder cannot be resolved to a type CsrfUtilTests.java
/ofbiz/framework/security/src/test/java/org/apache/ofbiz/security 
line 152

Java Problem
DocumentBuilder cannot be resolved to a type GatewayResponse.java
/ofbiz/applications/accounting/src/main/java/org/apache/ofbiz/accounting/thirdparty/eway 


line 169 Java Problem
DocumentBuilder cannot be resolved to a type ModelService.java

Re: [VOTE] Apache OFBiz 18.12.07

[Michael Brohl]

+1

Thanks,

Michael

Am 03.04.23 um 09:47 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.07", seventh
and probably final release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.07.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.07.zip.asc: the detached signature file
* apache-ofbiz-18.12.07.zip.sha512: checksum file

Please download and test the zip file and its signatures (for
instructions on testing the signatures see
http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.07
[ -1] do not release

This vote is open for at least 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: Please add me as an Apache OFBiz Contributor

[Michael Brohl]

Hi Adrian,

welcome to the Apache OFbiz community.

We have received your ICLA and I'll take care of your Jira access.

Best regards,

Michael


Am 04.04.23 um 11:14 schrieb Adrian Wolf:

Hello everyone,

I would like to ask you to add me as an Apache OFBiz Contributor.
My Confluence username is: adrian.wolf

For Jira, I'd like to submit the following informations:
email:adrian.w...@ecomify.de
username: awolf
alternate username: a.wolf
display name: Adrian Wolf

Thanks and kind regards,
Adrian Wolf

Re: Please add me as an Apache OFBiz Contributor

[Michael Brohl]

Hi Pascal,

thanks for joining us!

I have just created your Jira account, you should receive an email to 
verify.


Welcome on board,

Michael


Am 20.03.23 um 14:25 schrieb Pascal Zoschke:

Hello everyone,


I would like to ask you to add me as an Apache OFBiz Contributor.

My Confluence username is: pzoschke

For Jira, I'd like to submit the following informations:
email: pascal.zosc...@ecomify.de

username: pzoschke
alternate username: pascal.zoschke
display name: Pascal Zoschke


Thanks and kind regards
Pascal Zoschke


Am 13.03.23 um 17:22 schrieb Matt Sicker:

Dear Zoschke Pascal,

This message acknowledges receipt of your ICLA, which has been filed 
in the Apache Software Foundation records.


With this message, the OFBiz PMC has been notified that your ICLA has 
been filed.


** Please contact the Apache OFBiz PMC with any further questions, 
not the Secretary. Thanks. **


If you have been invited as a committer, please provide the Apache 
OFBiz PMC (copied) with your preferred Apache id.


The id must not already be in use. See 
https://people.apache.org/committer-index.html
Note that some existing ids include '-' and '_'. These characters are 
no longer permitted in ids.


The id must consist of lowercase alphanumeric characters only, 
starting with an alphabetic character.

Minimum length 3 characters. No special characters.

Warm Regards,

--
Matt Sicker
Secretary, Apache Software Foundation

Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Michael Brohl]

Hi everyone,

just a short update: we will start working on the migration of the 
website beginning mid March.


I hope that we can roll out the new website in April. I'll keep you updated.

Best regards,

Michael


Am 11.02.23 um 12:32 schrieb Michael Brohl:
See also https://issues.apache.org/jira/browse/INFRA-24152 for the 
infra migration Jira issue.


Michael Brohl

ecomify GmbH - www.ecomify.de


Am 07.02.23 um 19:06 schrieb Michael Brohl:

Dear community,

In the course of getting Wiebke to be able to help with our blog, it 
turned out that Apache Roller will be discontinued as the platform 
for blogs by infra [1].


There is an offer and already a pull request [2] to export the 
existing blog posts for a migration to Hugo [3].
Hugo is a static site generator which will generate individual pages 
from every markdown blog posts file which is provided in the PR.


That means we need to (at least)

- setup a Hugo project
- build up templates for the blog posts which also include header and 
footer for full page rendering
  (hence, we have to take over some of the templates/html 
code/javascrip/CSS to Hugo as well)

- generate the post pages and include them in the website under /blog.

These are quite some steps we have to take anyway and I ask myself if 
we should not switch over to Hugo for the whole website as well.
That should be not too difficult because we already have some kind of 
templates (in php) and there is already some sectioning with header, 
content, footer etc.


The advantages would be

- to truly separate content from the templates (it is now mixed 
php/content)
- blog posts can be generated from OFBiz commits and, together with 
page content, be send in by pull requests
- content automation (no need to change the copyright year manually, 
automated taxonimies for the blog etc.)
- easy process for a git supported writing process for pages and blog 
posts and a fast and automatable publishing process (git hooks or 
GitHub integration).


Coincidence: I am on a journey to migrate the ecomify websites to 
Hugo we have at least some knowledge there (maybe others as well?).


To sum up, I propose to migrate our blog and also the Apache OFBiz 
website to be an integrated, Hugo based website.


Opinions?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

[1] https://issues.apache.org/jira/browse/INFRA-22461
[2] https://github.com/apache/ofbiz-site/pull/8/files
[3] https://gohugo.io/

Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Michael Brohl]

See also https://issues.apache.org/jira/browse/INFRA-24152 for the infra 
migration Jira issue.


Michael Brohl

ecomify GmbH - www.ecomify.de


Am 07.02.23 um 19:06 schrieb Michael Brohl:

Dear community,

In the course of getting Wiebke to be able to help with our blog, it 
turned out that Apache Roller will be discontinued as the platform for 
blogs by infra [1].


There is an offer and already a pull request [2] to export the 
existing blog posts for a migration to Hugo [3].
Hugo is a static site generator which will generate individual pages 
from every markdown blog posts file which is provided in the PR.


That means we need to (at least)

- setup a Hugo project
- build up templates for the blog posts which also include header and 
footer for full page rendering
  (hence, we have to take over some of the templates/html 
code/javascrip/CSS to Hugo as well)

- generate the post pages and include them in the website under /blog.

These are quite some steps we have to take anyway and I ask myself if 
we should not switch over to Hugo for the whole website as well.
That should be not too difficult because we already have some kind of 
templates (in php) and there is already some sectioning with header, 
content, footer etc.


The advantages would be

- to truly separate content from the templates (it is now mixed 
php/content)
- blog posts can be generated from OFBiz commits and, together with 
page content, be send in by pull requests
- content automation (no need to change the copyright year manually, 
automated taxonimies for the blog etc.)
- easy process for a git supported writing process for pages and blog 
posts and a fast and automatable publishing process (git hooks or 
GitHub integration).


Coincidence: I am on a journey to migrate the ecomify websites to Hugo 
we have at least some knowledge there (maybe others as well?).


To sum up, I propose to migrate our blog and also the Apache OFBiz 
website to be an integrated, Hugo based website.


Opinions?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

[1] https://issues.apache.org/jira/browse/INFRA-22461
[2] https://github.com/apache/ofbiz-site/pull/8/files
[3] https://gohugo.io/

Re: Demo sites not response - suspect low RAM following docker container deployment

[Michael Brohl]

That sounds great, thanks!

Michael


Am 11.02.23 um 11:56 schrieb Daniel Watford:

32 GB - Nice! :)

And we have 8 vcpus too - rather than the 2 we started with . A 4 times the
previous CPU and memory capacity


On Sat, 11 Feb 2023 at 10:14, Jacques Le Roux 
wrote:


Hi Michael,

I guess it should be OK now. We got 32GB!

The demos are back and should be faster

Jacques

Le 11/02/2023 à 10:42, Michael Brohl a écrit :

Hi Dan, all,

maybe we can find a way to experiment on this outside the productive

VM's for our demos?

Best regards,

Michael


Am 11.02.23 um 09:34 schrieb Daniel Watford:

Hello,

After checking Saturday morning, it looks like the demo sites are not
responding to browser requests and I cannot SSH to ofbiz-vm1.apache.org

,

the demo sites host.

This follows some experiments on Friday to deploy a docker container
version of OFBiz. (Progress is reported here -[OFBIZ-12757] Experiment

with

deploying OFBiz containers to the demo sites server - ASF JIRA (

apache.org)

<https://issues.apache.org/jira/browse/OFBIZ-12757>)

On Friday we had a similar lock-up on the host which was thought to be

due

to running out of memory on the VM.

I suspect that, with the nightly rebuild of trunk, stable and next,

these

processes may cause a higher memory load on the server compared to

normal

running, and this may have caused us to exhaust available RAM on the

server

again.

If this suspicion is correct, then there is not enough RAM on the host

to

support docker experimentation in addition to normal operation of the

sites.

A request has been made to INFRA for a RAM increase which has been

accepted

([INFRA-24185] Request to increase RAM on ofbiz-vm1.apache.org - ASF

JIRA

<https://issues.apache.org/jira/browse/INFRA-24185>). Depending on

INFRA

availability, hopefully this will be completed early next week.

What can we do now?
When we had the previous lock-up on Friday, the demo host did eventually
recover and start accepting browser requests and SSH connections. I

imagine

the OFBiz build process is still ongoing - and would have been running

for

5.5 hours at time of writing this message.

If the host recovers and I am available, I will SSH to the host and

disable

the docker containers, hopefully avoiding this issue over the next few

days

until the RAM uplift is applied.

Alternatively, if we ask INFRA to reboot the VM, perhaps they can apply

the

RAM lift at the same time.

Dan.

Re: Demo sites not response - suspect low RAM following docker container deployment

[Michael Brohl]

Hi Dan, all,

maybe we can find a way to experiment on this outside the productive 
VM's for our demos?


Best regards,

Michael


Am 11.02.23 um 09:34 schrieb Daniel Watford:

Hello,

After checking Saturday morning, it looks like the demo sites are not
responding to browser requests and I cannot SSH to ofbiz-vm1.apache.org,
the demo sites host.

This follows some experiments on Friday to deploy a docker container
version of OFBiz. (Progress is reported here -[OFBIZ-12757] Experiment with
deploying OFBiz containers to the demo sites server - ASF JIRA (apache.org)
)

On Friday we had a similar lock-up on the host which was thought to be due
to running out of memory on the VM.

I suspect that, with the nightly rebuild of trunk, stable and next, these
processes may cause a higher memory load on the server compared to normal
running, and this may have caused us to exhaust available RAM on the server
again.

If this suspicion is correct, then there is not enough RAM on the host to
support docker experimentation in addition to normal operation of the sites.

A request has been made to INFRA for a RAM increase which has been accepted
([INFRA-24185] Request to increase RAM on ofbiz-vm1.apache.org - ASF JIRA
). Depending on INFRA
availability, hopefully this will be completed early next week.

What can we do now?
When we had the previous lock-up on Friday, the demo host did eventually
recover and start accepting browser requests and SSH connections. I imagine
the OFBiz build process is still ongoing - and would have been running for
5.5 hours at time of writing this message.

If the host recovers and I am available, I will SSH to the host and disable
the docker containers, hopefully avoiding this issue over the next few days
until the RAM uplift is applied.

Alternatively, if we ask INFRA to reboot the VM, perhaps they can apply the
RAM lift at the same time.

Dan.

Re: [PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Michael Brohl]

Hi Taher,

while this sounds like an interesting approach, I personally want to 
avoid to face things more complex than they have to be.


At ecomify, we are shifting to Hugo to get rid of things like Wordpress 
/ database maintenance, possible security issues etc.. We have limited 
ressources in our project here so I'm interested to keep things simple 
and effortless as much as we can.


Hugo is an infra supported solution, it seems to be the official 
migration target away from Roller so it seems to be the given way for 
the blog.


The question is if we also want to shift to Hugo for the website with a 
- then integrated - blog.


Thanks for your input and greetings,

Michael


Am 08.02.23 um 11:13 schrieb Taher Alkhateeb:

Hello, just throwing another idea in the pile, which I used in the past.

It is possible is to deploy a headless CMS. A headless CMS gives you admin user 
interface to control content, but the website is just a regular website (can be 
the existing one) that communicates with that headless CMS. What you can do 
with that is be able to deploy whatever exists and just replace the dynamic 
parts with calls to the headless CMS. And you control the content from there. 
So you don't even need to commit code, build and deploy, you just login to the 
admin section and edit things.

​​​Maybe the advantage of this approach is that you build on what exists 
instead of re-writing. This disadvantage might be that you have more pieces 
(website, CMS-admin, CMS-database) that should all be deployed and maintained. 
Thank you for all the efforts on maintaining all this content either way.

On Wednesday, February 08, 2023 12:55 +03, Daniel Watford  
wrote:
  Hi Michael,

This sounds very interesting.

I have gone back and forth over the years between CMS driven (WordPress)
and statically generated sites (Jekyll) depending on the users that
would be responsible for authoring content. Mixing the two with tools like
Next.js was also interesting.

WordPress suited non-technical better, whereas technical users benefited
from being able to generate the exact site they wanted. Plus the static
sites have the benefit of fast load times without having to implement
caches (although caching at CDNs is still useful)

Since we are a techy bunch I would support building the website using a
static generation tool. I've heard good things about Hugo, and since there
is existing experience on this tool within our community it would seem a
reasonable direction to take.

I'm also interested to see if adding more data-driven pages to the site
would be easier with Hugo. I quite like the idea of a few utility pages to
help generate seed data for users, such as:
- Custom time period generator
- Chart of accounts generator

My only concern with changing the site is the amount of work involved since
we have limited resources, but since we are being forced to take action in
order to get the blog operational, perhaps widening the scope to the site
is reasonable. I expect we can keep the existing HTML pages, and replace
them with Hugo generated pages as and when needed.

+1 from me.

Dan.


On Tue, 7 Feb 2023 at 18:07, Michael Brohl  wrote:


Dear community,

In the course of getting Wiebke to be able to help with our blog, it
turned out that Apache Roller will be discontinued as the platform for
blogs by infra [1].

There is an offer and already a pull request [2] to export the existing
blog posts for a migration to Hugo [3].
Hugo is a static site generator which will generate individual pages
from every markdown blog posts file which is provided in the PR.

That means we need to (at least)

- setup a Hugo project
- build up templates for the blog posts which also include header and
footer for full page rendering
(hence, we have to take over some of the templates/html
code/javascrip/CSS to Hugo as well)
- generate the post pages and include them in the website under /blog.

These are quite some steps we have to take anyway and I ask myself if we
should not switch over to Hugo for the whole website as well.
That should be not too difficult because we already have some kind of
templates (in php) and there is already some sectioning with header,
content, footer etc.

The advantages would be

- to truly separate content from the templates (it is now mixed
php/content)
- blog posts can be generated from OFBiz commits and, together with page
content, be send in by pull requests
- content automation (no need to change the copyright year manually,
automated taxonimies for the blog etc.)
- easy process for a git supported writing process for pages and blog
posts and a fast and automatable publishing process (git hooks or GitHub
integration).

Coincidence: I am on a journey to migrate the ecomify websites to Hugo
we have at least some knowledge there (maybe others as well?).

To sum up, I propose to migrate our blog and also the Apache OFBiz
website to be an integrated, Hugo based website.

Opinions?

Best reg

[PROPOSAL] Migration of the Apache OFBiz website to Hugo

[Michael Brohl]

Dear community,

In the course of getting Wiebke to be able to help with our blog, it 
turned out that Apache Roller will be discontinued as the platform for 
blogs by infra [1].


There is an offer and already a pull request [2] to export the existing 
blog posts for a migration to Hugo [3].
Hugo is a static site generator which will generate individual pages 
from every markdown blog posts file which is provided in the PR.


That means we need to (at least)

- setup a Hugo project
- build up templates for the blog posts which also include header and 
footer for full page rendering
  (hence, we have to take over some of the templates/html 
code/javascrip/CSS to Hugo as well)

- generate the post pages and include them in the website under /blog.

These are quite some steps we have to take anyway and I ask myself if we 
should not switch over to Hugo for the whole website as well.
That should be not too difficult because we already have some kind of 
templates (in php) and there is already some sectioning with header, 
content, footer etc.


The advantages would be

- to truly separate content from the templates (it is now mixed php/content)
- blog posts can be generated from OFBiz commits and, together with page 
content, be send in by pull requests
- content automation (no need to change the copyright year manually, 
automated taxonimies for the blog etc.)
- easy process for a git supported writing process for pages and blog 
posts and a fast and automatable publishing process (git hooks or GitHub 
integration).


Coincidence: I am on a journey to migrate the ecomify websites to Hugo 
we have at least some knowledge there (maybe others as well?).


To sum up, I propose to migrate our blog and also the Apache OFBiz 
website to be an integrated, Hugo based website.


Opinions?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

[1] https://issues.apache.org/jira/browse/INFRA-22461
[2] https://github.com/apache/ofbiz-site/pull/8/files
[3] https://gohugo.io/

Re: Welcome to Daniel Watford as new PMC member

[Michael Brohl]

Congratulations, Daniel!

Best regards,

Michael


Am 28.01.23 um 11:57 schrieb Jacopo Cappellato:

The OFBiz PMC has invited Daniel Watford as a new PMC member and we
are glad to announce that Daniel has accepted the nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

Hi Jacques,

we are using Ubuntu for all our servers and I cannot confirm that.

update-alternatives is used to generally set the envoronment to a  
specific JDK through JAVA_HOME. You can still set and thus override this 
environment variable in the shell session for the demo user.


On our developer machines (Mac OS/Unix based) we use simple aliases to 
change the JAVA_HOME variable to the needed JDK and can change fluently 
between them.


sudo is not required for this.

Regards,

Michael


Am 23.01.23 um 17:03 schrieb Jacques Le Roux:

Hi,

I got it to work, as often this was not as simple as expected, long 
story as short as possible.


It was not possible to set java env vars (JAVA_HOME and PATH). Because 
The VM uses "Ubuntu 20.04.5 LTS".


Ubuntu by default uses update-java-alternatives to handle Java 
versions. We had only JDK 11 so far, it's easy to add JDK 17 with 
"alternatives".
Update-alternatives uses symlink to handle env vars. So setting java 
env vars in scripts (or even in terminal) simply does not work.


So I thought that by using something like*

   |update-java-alternatives -s java-versionexport 
JAVA_HOME=/usr/lib/jvm/|||java-version|/||export PATH=$PATH:$JAVA_HOME|


   ||

in scripts it would be easy to set the necessary versions.

But update-java-alternatives requires to use sudo.
And, for security reason, all demo scripts must be run with ofbizDemo 
user.

Again for security reason, ofbizDemo is not a sudoer.

So update-java-alternatives was not an option.
I did not know anything about "SDKMAN!"** but it seemed to be a solution.
Again, not as simple as expected. SDKMAN uses BASH to set env vars and 
Ubuntu uses DASH behind "sh".

So few adjustments were necessary. You can see them at***

* https://aboullaite.me/switching-between-java-versions-on-ubuntu-linux/
** https://sdkman.io/
*** 
https://gitbox.apache.org/repos/asf?p=ofbiz-tools.git;a=commit;h=110483791d1bf640fd15e2d5589c940239c3c444


Enjoy!

Jacques

Le 20/01/2023 à 17:00, Jacques Le Roux a écrit :

Hi Michael,

I'm sorry, somehow I missed your email. I can't give you access, 
that's Infra's privilege.
We recently had a discussion with Daniel on Slack OFBiz channel about 
that, here is the relevant part copy


   <followhttps://infra.apache.org/vm-for-project.html#ssh-keys

<https://infra.apache.org/vm-for-project.html#ssh-keys>
   You need also to ask Infra for being a sudoer as explained 
athttps://infra.apache.org/vm-management.html
<https://infra.apache.org/vm-management.html>So first you need to ask 
the PMC>>


As your are a PMC, I think you don't need need to ask the PMC.

I thought that setting different JAVA_HOME environment variable 
values in one of the scripts would have undesirable side effects on 
the other scripts.


Anyway let me try your trick as it seems indeed easy.

Jacques

Le 14/01/2023 à 10:10, Michael Brohl a écrit :

Hi Jacques,

I have no access to the server right now so I cannot see where the 
Java installations reside or which Linux distro we use.


Can you give me access, preferably per ssh/public key to the machine?

On Ubuntu and Mac, you just install the different JDK's beside each 
other and point to the JDK which should be used by setting the 
JAVA_HOME environment variable in the start script. Easy.


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 13.01.23 um 18:23 schrieb Jacques Le Roux:

Le 13/01/2023 à 14:15, Michael Brohl a écrit :

set JAVA_HOME to the right JDK in the OFBiz start/stop scripts

Hi Michael,

That's a good news, how would you do that? A patch at 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup would 
be welcome


Thanks

Jacques

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

Hi Jacques,

I have no access to the server right now so I cannot see where the Java 
installations reside or which Linux distro we use.


Can you give me access, preferably per ssh/public key to the machine?

On Ubuntu and Mac, you just install the different JDK's beside each 
other and point to the JDK which should be used by setting the JAVA_HOME 
environment variable in the start script. Easy.


Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 13.01.23 um 18:23 schrieb Jacques Le Roux:

Le 13/01/2023 à 14:15, Michael Brohl a écrit :

set JAVA_HOME to the right JDK in the OFBiz start/stop scripts

Hi Michael,

That's a good news, how would you do that? A patch at 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup would be 
welcome


Thanks

Jacques

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

Hi Jacques,

where is the problem to run the demos using different JDK's?

I know it is possible to have different JDK's installed on Linux based 
Systems and set JAVA_HOME to the right JDK in the OFBiz start/stop scripts.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 13.01.23 um 08:44 schrieb Jacques Le Roux:

Hi,

All works and is ready here but the demos which are still under JDK 
11. If nobody disagree, as a temporary solution, I propose to stop the 
current stable (18.12) to allow next (22.01) and trunk to run under 
JDK 17


Opinions?

TIA

Jacques

Le 10/01/2023 à 16:48, Jacques Le Roux a écrit :

Michael, All,

I answered in the Jira. I think we are ready now for the next step: 
CI...


Le 10/01/2023 à 08:18, Michael Brohl a écrit :
Judging from the issues in 
https://issues.apache.org/jira/browse/OFBIZ-12400 it doesn't seem 
that we are ready for a release yet.


To bring this to attention for a wieder audience here: @Jacques: why 
is it necessary to make use of release candidate distributions of 
Gradle instead of stable ones?


Best regards,

Michael


Am 03.01.23 um 14:26 schrieb Michael Brohl:
I would recommend having it running some time on buildbot and the 
demos for field testing before we do a release.


Thanks,

Michael


Am 03.01.23 um 11:03 schrieb Jacques Le Roux:

Thanks Gil!

Hi All, should we start a vote about releasing 22.01.01 under 
Gradle 7.6 and JDK 17?


Maybe before we could run 22.01 under Gradle 7.6 and JDK 17 in 
GitHub Action, BuildBot (ie OFBiz CI) and demos as proposed by 
OFBIZ-12729?


We can also do both, because voting and releasing would take some 
time.


What do you think?

Thanks

Jacques

Le 03/01/2023 à 09:34, gil.portenseigne a écrit :

Hello Jacques,

+1 to release with Gradle 7.6 and JDK 17, that'd be great !

Thanks,

Gil
On 02/01/23 11:15, Jacques Le Roux wrote:

Hi Nicolas, All,

Thanks Nicolas for your opinions. I'm surprised that we are only 
5 to express opinions about this important decision.


Is nobody else interested ?

Thanks

Jacques


Le 30/12/2022 à 16:04, Nicolas Malin a écrit :

Hello Jacques,

I did the migration from my part with your suggest and I 
confirm that
ofbiz test passed with success. I also didn't detect any 
problem on
standard process for ordering and invoicing during manual 
simulation.


However, I didn't realize any loading test.

So no worries from my part to move forward.

Thanks for the works !

Nicolas


On 22/12/2022 19:02, Jacques Le Roux wrote:

Hi Team,

So far, we have only Michael's, Eugen's and Daniel's opinions 
about releasing the 22.01.01 version under Gradle 7.6 and JDK 
17 (OFBIZ-12400).


To summarize, Michael is against, Eugen and Daniel are for. 
Daniel
suggests that we can use workarounds but need to later update 
OFBiz

to handle strong encapsulation.

Michael, I was surprised by your opinion, because of 
https://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 
year ago:


    <first stable version during the year 2022.>>


And that led me to closely verify the situation. Fortunately, 
after
OFBIZ-12726 (integration tests), I believe we can trust using 
Gradle

7.6 and JDK 17 by using temporary workarounds.

So my question is, should we vote for releasing the 22.01.01 
version under Gradle 7.6 and JDK 17 or should we wait 22.01.02?


I have decided on my side to update GH, BuildBot and demos to 
run under Gradle 7.6 and JDK 17. If nobody is against of course.
This will take some time, but I don't expect much. For that we 
need to push the workarounds in all supported branches. It's 
not a big deal:


-    // jdk.serialFilter is to "Prevent possible DOS attack 
done using Java deserialisation" (OFBIZ-12592)

  applicationDefaultJvmArgs = project.hasProperty('jvmArgs')
  ? jvmArgs.tokenize()
-    : 
['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50']

+    : ['-Xms128M','-Xmx1024M',
+ 
'-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50', 
// OFBIZ-12592 and OFBIZ-12716
+ '--add-exports=java.base/sun.util.calendar=ALL-UNNAMED', // 
OFBIZ-12721

+ '--add-opens=java.base/java.util=ALL-UNNAMED' // OFBIZ-12726
+    ]

To release w/o the workarounds it is enough to remove the 2 
"ALL-UNNAMED" lines.


It also would be great to freeze a 23.01 branch and use it as 
next demos while replacing the 18.12 by 22.01 as stable.


Looking forward for opinions...

Thanks

Jacques

Re: Please add me as an Apache OFBiz Contributor

[Michael Brohl]

Hi Tobias,

welcome on board!

You are now assigned to the contributor‘s role in Jira and Confluence.

Happy contributing,
Michael

> 
> Am 11.01.2023 um 14:38 schrieb Tobias Hahn :
> 
> Hello everyone,
> 
> 
> I would like to ask you to add me as an Apache OFBiz Contributor.
> 
> My Confluence username is: tobias.hahn
> 
> 
> For Jira, I'd like to submit the following information:
> 
> email: tobias.h...@ecomify.de
> 
> username: thahn
> 
> alternate username: tobiashahn
> 
> display name: Tobias Hahn
> 
> 
> Thanks and kind regards,
> 
> Tobias Hahn
> 

Re: Please add me as an Apache OFBiz Contributor

[Michael Brohl]

Hi Chenghu,

I have now added you to the contributor‘s role in Jira and Confluence.
Looking forward to your contributions,

Michael

> 
> Am 08.01.2023 um 20:36 schrieb Michael Brohl :
> 
> Hi Cheng Hu,
> 
> welcome on board!
> 
> I have created your Jira account cshan, you should receive an email to reset 
> your password.
> 
> Please give me a short notice when your Jira account is accessible, I will 
> then assign you the contributor's role.
> 
> Please check you Confluence username: I was not able to assign you to the 
> permissions because I cannot find anyone using the given username.
> 
> Happy contributing,
> 
> Michael Brohl
> 
> ecomify GmbH - www.ecomify.de
> 
> 
>> Am 06.01.23 um 11:37 schrieb Cheng Hu Shan:
>> Hello everyone,
>> 
>> I would like to ask you to add me as an Apache OFBiz Contributor.
>> My Confluence username is: Chenghu Shan
>> 
>> For Jira, I'd like to submit the following informations:
>> email:cheng-hu.s...@ecomify.de
>> username: cshan
>> alternate username: chshan
>> display name: Chenghu Shan
>> 
>> Thanks and kind regards,
>> Chenghu Shan
>> 

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

Judging from the issues in 
https://issues.apache.org/jira/browse/OFBIZ-12400 it doesn't seem that 
we are ready for a release yet.


To bring this to attention for a wieder audience here: @Jacques: why is 
it necessary to make use of release candidate distributions of Gradle 
instead of stable ones?


Best regards,

Michael


Am 03.01.23 um 14:26 schrieb Michael Brohl:
I would recommend having it running some time on buildbot and the 
demos for field testing before we do a release.


Thanks,

Michael


Am 03.01.23 um 11:03 schrieb Jacques Le Roux:

Thanks Gil!

Hi All, should we start a vote about releasing 22.01.01 under Gradle 
7.6 and JDK 17?


Maybe before we could run 22.01 under Gradle 7.6 and JDK 17 in GitHub 
Action, BuildBot (ie OFBiz CI) and demos as proposed by OFBIZ-12729?


We can also do both, because voting and releasing would take some time.

What do you think?

Thanks

Jacques

Le 03/01/2023 à 09:34, gil.portenseigne a écrit :

Hello Jacques,

+1 to release with Gradle 7.6 and JDK 17, that'd be great !

Thanks,

Gil
On 02/01/23 11:15, Jacques Le Roux wrote:

Hi Nicolas, All,

Thanks Nicolas for your opinions. I'm surprised that we are only 5 
to express opinions about this important decision.


Is nobody else interested ?

Thanks

Jacques


Le 30/12/2022 à 16:04, Nicolas Malin a écrit :

Hello Jacques,

I did the migration from my part with your suggest and I confirm that
ofbiz test passed with success. I also didn't detect any problem on
standard process for ordering and invoicing during manual simulation.

However, I didn't realize any loading test.

So no worries from my part to move forward.

Thanks for the works !

Nicolas


On 22/12/2022 19:02, Jacques Le Roux wrote:

Hi Team,

So far, we have only Michael's, Eugen's and Daniel's opinions 
about releasing the 22.01.01 version under Gradle 7.6 and JDK 17 
(OFBIZ-12400).


To summarize, Michael is against, Eugen and Daniel are for. Daniel
suggests that we can use workarounds but need to later update OFBiz
to handle strong encapsulation.

Michael, I was surprised by your opinion, because of 
https://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 
year ago:


    <stable version during the year 2022.>>


And that led me to closely verify the situation. Fortunately, after
OFBIZ-12726 (integration tests), I believe we can trust using Gradle
7.6 and JDK 17 by using temporary workarounds.

So my question is, should we vote for releasing the 22.01.01 
version under Gradle 7.6 and JDK 17 or should we wait 22.01.02?


I have decided on my side to update GH, BuildBot and demos to run 
under Gradle 7.6 and JDK 17. If nobody is against of course.
This will take some time, but I don't expect much. For that we 
need to push the workarounds in all supported branches. It's not 
a big deal:


-    // jdk.serialFilter is to "Prevent possible DOS attack done 
using Java deserialisation" (OFBIZ-12592)

  applicationDefaultJvmArgs = project.hasProperty('jvmArgs')
  ? jvmArgs.tokenize()
-    : 
['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50']

+    : ['-Xms128M','-Xmx1024M',
+ 
'-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50', 
// OFBIZ-12592 and OFBIZ-12716
+ '--add-exports=java.base/sun.util.calendar=ALL-UNNAMED', // 
OFBIZ-12721

+ '--add-opens=java.base/java.util=ALL-UNNAMED' // OFBIZ-12726
+    ]

To release w/o the workarounds it is enough to remove the 2 
"ALL-UNNAMED" lines.


It also would be great to freeze a 23.01 branch and use it as 
next demos while replacing the 18.12 by 22.01 as stable.


Looking forward for opinions...

Thanks

Jacques

Re: Please add me as an Apache OFBiz Contributor

[Michael Brohl]

Hi Cheng Hu,

welcome on board!

I have created your Jira account cshan, you should receive an email to 
reset your password.


Please give me a short notice when your Jira account is accessible, I 
will then assign you the contributor's role.


Please check you Confluence username: I was not able to assign you to 
the permissions because I cannot find anyone using the given username.


Happy contributing,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 06.01.23 um 11:37 schrieb Cheng Hu Shan:

Hello everyone,

I would like to ask you to add me as an Apache OFBiz Contributor.
My Confluence username is: Chenghu Shan

For Jira, I'd like to submit the following informations:
email:cheng-hu.s...@ecomify.de
username: cshan
alternate username: chshan
display name: Chenghu Shan

Thanks and kind regards,
Chenghu Shan

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

I would recommend having it running some time on buildbot and the demos 
for field testing before we do a release.


Thanks,

Michael


Am 03.01.23 um 11:03 schrieb Jacques Le Roux:

Thanks Gil!

Hi All, should we start a vote about releasing 22.01.01 under Gradle 
7.6 and JDK 17?


Maybe before we could run 22.01 under Gradle 7.6 and JDK 17 in GitHub 
Action, BuildBot (ie OFBiz CI) and demos as proposed by OFBIZ-12729?


We can also do both, because voting and releasing would take some time.

What do you think?

Thanks

Jacques

Le 03/01/2023 à 09:34, gil.portenseigne a écrit :

Hello Jacques,

+1 to release with Gradle 7.6 and JDK 17, that'd be great !

Thanks,

Gil
On 02/01/23 11:15, Jacques Le Roux wrote:

Hi Nicolas, All,

Thanks Nicolas for your opinions. I'm surprised that we are only 5 
to express opinions about this important decision.


Is nobody else interested ?

Thanks

Jacques


Le 30/12/2022 à 16:04, Nicolas Malin a écrit :

Hello Jacques,

I did the migration from my part with your suggest and I confirm that
ofbiz test passed with success. I also didn't detect any problem on
standard process for ordering and invoicing during manual simulation.

However, I didn't realize any loading test.

So no worries from my part to move forward.

Thanks for the works !

Nicolas


On 22/12/2022 19:02, Jacques Le Roux wrote:

Hi Team,

So far, we have only Michael's, Eugen's and Daniel's opinions 
about releasing the 22.01.01 version under Gradle 7.6 and JDK 17 
(OFBIZ-12400).


To summarize, Michael is against, Eugen and Daniel are for. Daniel
suggests that we can use workarounds but need to later update OFBiz
to handle strong encapsulation.

Michael, I was surprised by your opinion, because of 
https://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 
year ago:


    >


And that led me to closely verify the situation. Fortunately, after
OFBIZ-12726 (integration tests), I believe we can trust using Gradle
7.6 and JDK 17 by using temporary workarounds.

So my question is, should we vote for releasing the 22.01.01 
version under Gradle 7.6 and JDK 17 or should we wait 22.01.02?


I have decided on my side to update GH, BuildBot and demos to run 
under Gradle 7.6 and JDK 17. If nobody is against of course.
This will take some time, but I don't expect much. For that we 
need to push the workarounds in all supported branches. It's not a 
big deal:


-    // jdk.serialFilter is to "Prevent possible DOS attack done 
using Java deserialisation" (OFBIZ-12592)

  applicationDefaultJvmArgs = project.hasProperty('jvmArgs')
  ? jvmArgs.tokenize()
-    : 
['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50']

+    : ['-Xms128M','-Xmx1024M',
+ 
'-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50', 
// OFBIZ-12592 and OFBIZ-12716
+ '--add-exports=java.base/sun.util.calendar=ALL-UNNAMED', // 
OFBIZ-12721
+    '--add-opens=java.base/java.util=ALL-UNNAMED' // 
OFBIZ-12726

+    ]

To release w/o the workarounds it is enough to remove the 2 
"ALL-UNNAMED" lines.


It also would be great to freeze a 23.01 branch and use it as next 
demos while replacing the 18.12 by 22.01 as stable.


Looking forward for opinions...

Thanks

Jacques

Re: OFBiz connection to Postgres database without JBDC

[Michael Brohl]

Hi Douglas,

Do you have some reference to read why Postgres is blocking JDBC?

OFBiz is database agnostic, the implementation to achieve this uses JDBC 
as the core mechanism.
So I guess it would be quite difficult to connect OFBiz in another way 
than JDBC.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 27.12.22 um 17:38 schrieb Douglas Melo:

Good morning people!

Is it possible to make OFBiz Connection in Postgresql database without JDBC?
It looks like JBDC has been blocked by the Postgres team due to a security 
vulnerability.
Is there any other way to connect to the database without JBDC?
Or do you know if there is any secure JBDC file?

Douglas Melo
douglas.mel...@hotmail.com 
(https://link.getmailspring.com/link/0073d57a-7206-4151-86ce-cd5b2e124...@getmailspring.com/0?redirect=mailto%3Adouglas.melo98%40hotmail.com&recipient=ZGV2QG9mYml6LmFwYWNoZS5vcmc%3D)
+55 28 99955-2528 (tel:+55%2028%2099955-2528)

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

There's a typo in my below statement.

It should read: "What I was saying is, that we'll have to do proper 
testing before releasing 22.01 with JDK 17." (not JDK 11)


Michael


Am 23.12.22 um 16:51 schrieb Michael Brohl:

Hi Jacques,

I am confused. What makes you think that I am against releasing 
22.01.01 with JDK 17?


In the contrary, I was the one suggesting to skip JDK 11 in favour of 
JDK 17.


What I was saying is, that we'll have to do proper testing before 
releasing 22.01 with JDK 11. In my opinion, testing defines WHEN we 
can release 22.01 with JDK 17, not if.


Michael


Am 22.12.22 um 19:02 schrieb Jacques Le Roux:

Hi Team,

So far, we have only Michael's, Eugen's and Daniel's opinions about 
releasing the 22.01.01 version under Gradle 7.6 and JDK 17 
(OFBIZ-12400).


To summarize, Michael is against, Eugen and Daniel are for. Daniel 
suggests that we can use workarounds but need to later update OFBiz 
to handle strong encapsulation.


Michael, I was surprised by your opinion, because of 
https://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 year ago:


   <stable version during the year 2022.>>


And that led me to closely verify the situation. Fortunately, after 
OFBIZ-12726 (integration tests), I believe we can trust using Gradle 
7.6 and JDK 17 by using temporary workarounds.


So my question is, should we vote for releasing the 22.01.01 version 
under Gradle 7.6 and JDK 17 or should we wait 22.01.02?


I have decided on my side to update GH, BuildBot and demos to run 
under Gradle 7.6 and JDK 17. If nobody is against of course.
This will take some time, but I don't expect much. For that we need 
to push the workarounds in all supported branches. It's not a big deal:


-    // jdk.serialFilter is to "Prevent possible DOS attack done 
using Java deserialisation" (OFBIZ-12592)

 applicationDefaultJvmArgs = project.hasProperty('jvmArgs')
 ? jvmArgs.tokenize()
-    : 
['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50']

+    : ['-Xms128M','-Xmx1024M',
+ 
'-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50', 
// OFBIZ-12592 and OFBIZ-12716
+ '--add-exports=java.base/sun.util.calendar=ALL-UNNAMED', // 
OFBIZ-12721
+    '--add-opens=java.base/java.util=ALL-UNNAMED' // 
OFBIZ-12726

+    ]

To release w/o the workarounds it is enough to remove the 2 
"ALL-UNNAMED" lines.


It also would be great to freeze a 23.01 branch and use it as next 
demos while replacing the 18.12 by 22.01 as stable.


Looking forward for opinions...

Thanks

Jacques

Re: [OFBIZ-12400] Releasing the 22.01.01 version under Gradle 7.6 and JDK 17

[Michael Brohl]

Hi Jacques,

I am confused. What makes you think that I am against releasing 22.01.01 
with JDK 17?


In the contrary, I was the one suggesting to skip JDK 11 in favour of 
JDK 17.


What I was saying is, that we'll have to do proper testing before 
releasing 22.01 with JDK 11. In my opinion, testing defines WHEN we can 
release 22.01 with JDK 17, not if.


Michael


Am 22.12.22 um 19:02 schrieb Jacques Le Roux:

Hi Team,

So far, we have only Michael's, Eugen's and Daniel's opinions about 
releasing the 22.01.01 version under Gradle 7.6 and JDK 17 (OFBIZ-12400).


To summarize, Michael is against, Eugen and Daniel are for. Daniel 
suggests that we can use workarounds but need to later update OFBiz to 
handle strong encapsulation.


Michael, I was surprised by your opinion, because of 
https://markmail.org/message/fq3fpxeg5yfshjwz where you said 1 year ago:


   >


And that led me to closely verify the situation. Fortunately, after 
OFBIZ-12726 (integration tests), I believe we can trust using Gradle 
7.6 and JDK 17 by using temporary workarounds.


So my question is, should we vote for releasing the 22.01.01 version 
under Gradle 7.6 and JDK 17 or should we wait 22.01.02?


I have decided on my side to update GH, BuildBot and demos to run 
under Gradle 7.6 and JDK 17. If nobody is against of course.
This will take some time, but I don't expect much. For that we need to 
push the workarounds in all supported branches. It's not a big deal:


-    // jdk.serialFilter is to "Prevent possible DOS attack done using 
Java deserialisation" (OFBIZ-12592)

 applicationDefaultJvmArgs = project.hasProperty('jvmArgs')
 ? jvmArgs.tokenize()
-    : 
['-Xms128M','-Xmx1024M','-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50']

+    : ['-Xms128M','-Xmx1024M',
+ 
'-Djdk.serialFilter=maxarray=10;maxdepth=20;maxrefs=1000;maxbytes=50', 
// OFBIZ-12592 and OFBIZ-12716

+ '--add-exports=java.base/sun.util.calendar=ALL-UNNAMED', // OFBIZ-12721
+    '--add-opens=java.base/java.util=ALL-UNNAMED' // OFBIZ-12726
+    ]

To release w/o the workarounds it is enough to remove the 2 
"ALL-UNNAMED" lines.


It also would be great to freeze a 23.01 branch and use it as next 
demos while replacing the 18.12 by 22.01 as stable.


Looking forward for opinions...

Thanks

Jacques

Re: OFBiz 21.01 releases

[Michael Brohl]

You are confusing me, Jacques.

There is no release 20.01.01, its 22.01.01, right?

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 20.12.22 um 11:55 schrieb Jacques Le Roux:
You are right, confident as all seamed to go well running OFBiz, I did 
not ran integration tests yet


There is a lot of work to do regarding those. Currently we have 322 
errors and 190 failures.
I'm still confident that it should not be as hard as it looks to fix, 
but indeed that could maybe take several weeks.


So releasing 20.01.01 with gradle 7.6 and JDK 17, seems indeed a bit 
early.


In order to accelerate releasing 20.01.02, or next, with gradle 7.6 
and JDK 17, I suggest to run the demos with them.


What do you guys think?

Jacques

Le 20/12/2022 à 09:33, Michael Brohl a écrit :
In my opinion, before we do a RELEASE based on a new JDK (doing a 
step from 8 to 17), we should have some serious testing with 
different environments etc.


It's only a few weeks since the change which is much different from 
the long stabilization phases we had in the past.


How can we organize this?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


PS: we could do some testing on Mac and Ubuntu but it will take some 
time


Am 20.12.22 um 07:53 schrieb Jacques Le Roux:

Hi All,

After Eugen suggested so, for few weeks now I'm using 7.6 and JDK 17 
without any problems.


For that, we have OFBIZ-12400 "Upgrade to gradle 7.6 - support jdk 
11 -> 17" with 2 minor subtasks open.


I suggest that you also test on your side in order to allow to 
release the 22.01.01 version with this configuration.


TIA

Jacques

Le 19/12/2022 à 14:13, Nicolas Malin a écrit :

Yeah,

I'm agree for the 22.01,
I'm just disappointed to didn't find the time to present our work 
on the new decorator and theme for this release, but sure for the 
next :)


Nicolas


On 16/12/2022 10:12, Daniel Watford wrote:

Hello,

The ofbiz project recently announced there would be no further 
releases for

18.12.

Has there been any releases for version 21.01, and if so should 
they be

downloadable from the ofbiz website?

Thanks,

Dan

Re: OFBiz 21.01 releases

[Michael Brohl]

In my opinion, before we do a RELEASE based on a new JDK (doing a step 
from 8 to 17), we should have some serious testing with different 
environments etc.


It's only a few weeks since the change which is much different from the 
long stabilization phases we had in the past.


How can we organize this?

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


PS: we could do some testing on Mac and Ubuntu but it will take some time

Am 20.12.22 um 07:53 schrieb Jacques Le Roux:

Hi All,

After Eugen suggested so, for few weeks now I'm using 7.6 and JDK 17 
without any problems.


For that, we have OFBIZ-12400 "Upgrade to gradle 7.6 - support jdk 11 
-> 17" with 2 minor subtasks open.


I suggest that you also test on your side in order to allow to release 
the 22.01.01 version with this configuration.


TIA

Jacques

Le 19/12/2022 à 14:13, Nicolas Malin a écrit :

Yeah,

I'm agree for the 22.01,
I'm just disappointed to didn't find the time to present our work on 
the new decorator and theme for this release, but sure for the next :)


Nicolas


On 16/12/2022 10:12, Daniel Watford wrote:

Hello,

The ofbiz project recently announced there would be no further 
releases for

18.12.

Has there been any releases for version 21.01, and if so should they be
downloadable from the ofbiz website?

Thanks,

Dan

Re: OFBiz 21.01 releases

[Michael Brohl]

Hi Dan,

remark: it will be an 22.01 release, not 21.01. We have created the 
branch at the beginning of this year.


Stable  branches generally only receive bug fixes and - if the community 
agrees - non-breaking small features. So yes.


Best regards,

Michael


Am 16.12.22 um 10:58 schrieb Daniel Watford:

Thanks, Jacques.

If 21.01 is coming soon, does that mean we have a feature freeze in place -
i.e. we should only commit bug fixes or agreed features to the 21.01 branch
in order to stablise the release?

On Fri, 16 Dec 2022 at 09:30, Jacques Le Roux 
wrote:


Hi Daniel,

Not yet, but it should be "soon" (ie in few weeks), hopefully using JDK 17
and Gradle 7.6...

Jacques

Le 16/12/2022 à 10:12, Daniel Watford a écrit :

Hello,

The ofbiz project recently announced there would be no further releases

for

18.12.

Has there been any releases for version 21.01, and if so should they be
downloadable from the ofbiz website?

Thanks,

Dan

Re: How committers should handle old Jira Issues (and patches)

[Michael Brohl]

Hi Giulio,

thanks for taking care of the Jira issues and bringing this up.

As to my knowledge, there is no strict rule on how to handle this. We 
are a community of volunteers and sometimes contributors come and go so 
it is common that you will get late or no responses to an issue comment.


Personally, I ask 1-3 times and then decide for myself on how to proceed 
with the issue. The action taken depends on the issue (working on it, 
closing it because of no response, ...).


So I encourage you to decide what you think would be the best for the 
project and go on. If there is an objection, it will be raised.


Regarding the mentioned OFBIT-9362, your comment is only 4 days old. You 
should give people at least 1-2 weeks to respond.  What you can also do 
is to mention how you will proceed with the issue if there is no 
response within xx days/weeks.


Hope this helps,

best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 28.10.22 um 19:14 schrieb Giulio Speri - MpStyle Srl:

Hello devs,

I hope you're doing great.
I recently started to give a check to the old ofbiz issues in Jira with the
status "patch available", both to increase my contribution as (new)
committer and also to try to reduce the bug list.
To warm up I started with the "trivia" issues and then I'll proceed. :)

I came across some (quite) old issues and I tried to gather informations by
contacting the original reporter or the assignee of that task (ie:
OFBIZ-9362).
What if nobody replies for some time (maybe the original reporter/assignee
is no more involved in the project so not able to respond), as for the case
of the issue OFBIZ-9362 ? Are there some community guidelines for this kind
of situation? Should I keep waiting for a response or should I re-analyze
the issue, assign it to me and then work on it?


Thank you in advance,

Giulio

Re: Welcome to Leila Mekika as new committer

[Michael Brohl]

Congratulations and welcome from me as well, Leila!

Looking forward to your contributions and working together.

Best regards,

Michael

Am 04.10.22 um 09:30 schrieb MLeila:

Hello all,

Thanks for your welcome!
I am glad to join the team and be able to contribute more actively on 
the project


Regards,
Leila

Le 04/10/2022 à 07:38, Devanshu Vyas a écrit :

Many congratulations and welcome aboard Leila!!

Thanks & Regards,
Devanshu Vyas.


On Mon, Oct 3, 2022 at 6:27 PM Nicolas Malin 
wrote:


The OFBiz PMC has invited Leila Mekika as new
committer and we are glad to announce that she have accepted the
nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: Tenant and properties

[Michael Brohl]

Hi Jacques,

I revisited the thread and discussions. My conclusion ist still the same 
so I will cite it here again:


"Essentially, I'm against deprecating file based properties and be in
favor of a general fallback solution (SystemProperty -> .properties) for
all properties *except* properties which cannot be read from the
database (system startup properties etc.)

It is extremely helpful to maintain file based properties along with
templates and a build solution to populate system specific sets of
settings (we had a discussion about it). This cannot be achieved
reasonably with pure database based properties.

And again some remark: the initial problem was simply SystemProperty
demo data overriding file based properties, which can be solved by
preventing to load them by default."

The solution is pretty simple and does not need any development except 
to prevent loading the demo SystemProperty data.


Changing from seed to seed-initial does not help in this case as it will 
still load DEMO data as seed data and will confuse users who are not 
aware of the mechanism, asking themselves why their file property 
configuration is not used.


I recommend to leave the demo data xml file in place as an example for 
SystemProperty data end remove it from any loading mechanism by 
commenting out the reference in ofbiz-component.xml.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 30.08.22 um 11:28 schrieb Jacques Le Roux:

Le 30/08/2022 à 10:20, Jacques Le Roux a écrit :

Hi,

It's a long time now I, from time to time, have a look at this issue. 
At some point I had at least 13 related links, remain open only:

https://issues.apache.org/jira/browse/OFBIZ-7112 "EntityUtilProperties"
https://issues.apache.org/jira/browse/OFBIZ-6712 "Increase the number 
of EntityUtilProperties methods which really use 
getSystemPropertyValue()"
https://issues.apache.org/jira/browse/OFBIZ-7754 "The big problem 
when loading seed."
https://issues.apache.org/jira/browse/OFBIZ-6164 "Improve 
configurability of OFBiz"


And somehow related (to review when the rest is done):
https://cwiki.apache.org/confluence/display/OFBIZ/Extension+in+Multitenancy+support 


https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support

We discussed a lot about that (notably*) but did not decide about it.
* https://markmail.org/message/md6fuoouan377c6w (look rather at 
bottom of the thread where some opinionated conclusions show)


For OFBIZ-7754 I notably suggested (comment there 
https://s.apache.org/cyx1j):


   <believe we should 1st separate properties, keep generic ones in 
properties files and

   put others in DB.>>

But Michael is basically against that, see bottom of the thread 
(markmail) above.


I don't think anybody is against changing from seed to seed-initial 
for CommonSystemPropertyData.xml rather than removing it as suggested 
by Hans (who created it).
I mean maybe some users are relying on that now. Note that it goes in 
the direction I suggested above.


Then, if nobody is against, I'll close OFBIZ-7754 (and hopefully 
other but 7112) and create a new Jira task to separate all properties 
as Hans did for CommonSystemPropertyData


Afterward I'll get back to OFBIZ-7112

What do you think?

Note that I'll not wait forever for opinions. It will not be longer 
than next week.


TIA

Jacques
Regarding Michael's then reluctance, I already suggested a maybe 
solution:
instead of using load-initial to load alike properties from files 
(those that can be tenant specific)
we could create a load-tenant reader that would be only used if 
<> or if the user prefer using DB data instead of 
properties in file for all properties types (ie business and system)


Michael, what do you think about that?

Another option, somehow related, is to use Taher's suggestion and have 
all properties in a sole file as HTTPD does, I'm not much inclined to 
that. (It's only in my memories, I can't find a reference back)


I have created
https://issues.apache.org/jira/browse/OFBIZ-12689 "Separate business 
properties from system properties"
https://issues.apache.org/jira/browse/OFBIZ-12688 "Change 
SystemProperty entity name to BusinessProperty" (depends upon 12689)


Jacques

Re: Tenant and properties

[Michael Brohl]

Hi Jacques,

unfortunately not yet, sorry for the delay. Hope to be able to get into 
it this week.


Thanks and regards,

Michael


Am 12.09.22 um 11:26 schrieb Jacques Le Roux:

Hi Michael,

Did you get a chance?

Thanks

Jacques

Le 03/09/2022 à 20:21, Michael Brohl a écrit :

Hi Jacques,

I will dig into this further in the next days.

Thanks,

Michael

Am 30.08.22 um 11:28 schrieb Jacques Le Roux:

Le 30/08/2022 à 10:20, Jacques Le Roux a écrit :

Hi,

It's a long time now I, from time to time, have a look at this 
issue. At some point I had at least 13 related links, remain open 
only:
https://issues.apache.org/jira/browse/OFBIZ-7112 
"EntityUtilProperties"
https://issues.apache.org/jira/browse/OFBIZ-6712 "Increase the 
number of EntityUtilProperties methods which really use 
getSystemPropertyValue()"
https://issues.apache.org/jira/browse/OFBIZ-7754 "The big problem 
when loading seed."
https://issues.apache.org/jira/browse/OFBIZ-6164 "Improve 
configurability of OFBiz"


And somehow related (to review when the rest is done):
https://cwiki.apache.org/confluence/display/OFBIZ/Extension+in+Multitenancy+support 


https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support

We discussed a lot about that (notably*) but did not decide about it.
* https://markmail.org/message/md6fuoouan377c6w (look rather at 
bottom of the thread where some opinionated conclusions show)


For OFBIZ-7754 I notably suggested (comment there 
https://s.apache.org/cyx1j):


   <believe we should 1st separate properties, keep generic ones in 
properties files and

   put others in DB.>>

But Michael is basically against that, see bottom of the thread 
(markmail) above.


I don't think anybody is against changing from seed to seed-initial 
for CommonSystemPropertyData.xml rather than removing it as 
suggested by Hans (who created it).
I mean maybe some users are relying on that now. Note that it goes 
in the direction I suggested above.


Then, if nobody is against, I'll close OFBIZ-7754 (and hopefully 
other but 7112) and create a new Jira task to separate all 
properties as Hans did for CommonSystemPropertyData


Afterward I'll get back to OFBIZ-7112

What do you think?

Note that I'll not wait forever for opinions. It will not be longer 
than next week.


TIA

Jacques
Regarding Michael's then reluctance, I already suggested a maybe 
solution:
instead of using load-initial to load alike properties from files 
(those that can be tenant specific)
we could create a load-tenant reader that would be only used if 
<> or if the user prefer using DB data instead of 
properties in file for all properties types (ie business and system)


Michael, what do you think about that?

Another option, somehow related, is to use Taher's suggestion and 
have all properties in a sole file as HTTPD does, I'm not much 
inclined to that. (It's only in my memories, I can't find a 
reference back)


I have created
https://issues.apache.org/jira/browse/OFBIZ-12689 "Separate business 
properties from system properties"
https://issues.apache.org/jira/browse/OFBIZ-12688 "Change 
SystemProperty entity name to BusinessProperty" (depends upon 12689)


Jacques

Re: Tenant and properties

[Michael Brohl]

Hi Jacques,

I will dig into this further in the next days.

Thanks,

Michael

Am 30.08.22 um 11:28 schrieb Jacques Le Roux:

Le 30/08/2022 à 10:20, Jacques Le Roux a écrit :

Hi,

It's a long time now I, from time to time, have a look at this issue. 
At some point I had at least 13 related links, remain open only:

https://issues.apache.org/jira/browse/OFBIZ-7112 "EntityUtilProperties"
https://issues.apache.org/jira/browse/OFBIZ-6712 "Increase the number 
of EntityUtilProperties methods which really use 
getSystemPropertyValue()"
https://issues.apache.org/jira/browse/OFBIZ-7754 "The big problem 
when loading seed."
https://issues.apache.org/jira/browse/OFBIZ-6164 "Improve 
configurability of OFBiz"


And somehow related (to review when the rest is done):
https://cwiki.apache.org/confluence/display/OFBIZ/Extension+in+Multitenancy+support 


https://cwiki.apache.org/confluence/display/OFBIZ/Multitenancy+support

We discussed a lot about that (notably*) but did not decide about it.
* https://markmail.org/message/md6fuoouan377c6w (look rather at 
bottom of the thread where some opinionated conclusions show)


For OFBIZ-7754 I notably suggested (comment there 
https://s.apache.org/cyx1j):


   >

But Michael is basically against that, see bottom of the thread 
(markmail) above.


I don't think anybody is against changing from seed to seed-initial 
for CommonSystemPropertyData.xml rather than removing it as suggested 
by Hans (who created it).
I mean maybe some users are relying on that now. Note that it goes in 
the direction I suggested above.


Then, if nobody is against, I'll close OFBIZ-7754 (and hopefully 
other but 7112) and create a new Jira task to separate all properties 
as Hans did for CommonSystemPropertyData


Afterward I'll get back to OFBIZ-7112

What do you think?

Note that I'll not wait forever for opinions. It will not be longer 
than next week.


TIA

Jacques
Regarding Michael's then reluctance, I already suggested a maybe 
solution:
instead of using load-initial to load alike properties from files 
(those that can be tenant specific)
we could create a load-tenant reader that would be only used if 
<> or if the user prefer using DB data instead of 
properties in file for all properties types (ie business and system)


Michael, what do you think about that?

Another option, somehow related, is to use Taher's suggestion and have 
all properties in a sole file as HTTPD does, I'm not much inclined to 
that. (It's only in my memories, I can't find a reference back)


I have created
https://issues.apache.org/jira/browse/OFBIZ-12689 "Separate business 
properties from system properties"
https://issues.apache.org/jira/browse/OFBIZ-12688 "Change 
SystemProperty entity name to BusinessProperty" (depends upon 12689)


Jacques

Re: [VOTE] Apache OFBiz 18.12.06

[Michael Brohl]

+1

~/Projects/apache-ofbiz/dist  ../ofbiz-tools/verify-ofbiz-release.sh -d 
-v -t apache-ofbiz-18.12.06

Processing files for release: apache-ofbiz-18.12.06...
Downloading files for apache-ofbiz-18.12.06.zip...
...
Done!

Verifying files...
sha check of file: apache-ofbiz-18.12.06.zip
Using sha file: apache-ofbiz-18.12.06.zip.sha512
apache-ofbiz-18.12.06.zip: AC409201 EE9C5A0F BAFCDA94 0E29DA0A DC39DC4D 
DEF25690 BD962C9E 0209C412 E52B14D7 44587E42 B208B8BD C24B25E4 E313536F 
EA6C1082 2657AB36 55E3F99D
apache-ofbiz-18.12.06.zip: AC409201 EE9C5A0F BAFCDA94 0E29DA0A DC39DC4D 
DEF25690 BD962C9E 0209C412 E52B14D7 44587E42 B208B8BD C24B25E4 E313536F 
EA6C1082 2657AB36 55E3F99D

sha checksum OK

GPG verification output
gpg: Signature made Wed Aug 24 14:33:57 2022 CEST using RSA key ID 847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
" [ultimate]


...
Initializing Gradle wrapper...
 === Prepare operation ===
/Users/mbrohl/Projects/apache-ofbiz/dist/apache-ofbiz-18.12.06/gradle/wrapper/gradle-wrapper.jar 
not found, we download it

 === Download gradle-wrapper.jar ===
 === Download gradle-wrapper.properties ===
 === Control downloaded files ===
gradle/wrapper/gradle-wrapper.jar: OK
gradle/wrapper/gradle-wrapper.properties: OK
gradlew: OK
Running tests...

...

BUILD SUCCESSFUL in 6m 17s
30 actionable tasks: 25 executed, 5 up-to-date
Done processing files for release apache-ofbiz-18.12.06

Thanks,

Michael


Am 25.08.22 um 10:10 schrieb Jacopo Cappellato:

This is the vote thread to publish "Apache OFBiz 18.12.06", the sixth and
final release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.06.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.06.zip.asc: the detached signature file
* apache-ofbiz-18.12.06.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.06
[ -1] do not release

This vote is open for 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Re: CI github failed : Java 11 or java 17

[Michael Brohl]

Hi Nicolas,

I suggested to think about switching to JDK 17 LTS a while ago: 
https://lists.apache.org/thread/8cpz4dh7zoznp4mx2xxv35hns4j8mvf0


Time went by, so I think it would be better to skip 11 and go with 17 
LTS, because we will have longer support.


What do you think?

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 15.07.22 um 10:14 schrieb Nicolas Malin:

Hello,

I saw that break the CI github because I commited a List.of on 
release22.01 [1] not supported by java 8


After a quick check, the CI work on java 8 and the documentation quote 
also the java 8 (release22.01 and trunk) but for the demo server we 
move to java 11 [2]


I propose to update the CI and documentation but to be sure, we move 
the release22.01 on java 11 or the LTS 17 ?


Reading you
Nicolas


[1] https://gitbox.apache.org/repos/asf/ofbiz-framework.git
[2] https://lists.apache.org/thread/fq6q58lv52751t4xlkb17mmwkj4kk8q4

Re: Codenarc integration, rules to use.

[Michael Brohl]

Hi Gil,

I was on vacation so a bit late: I fully agree to apply these rules.

We should, however, encourage contributors to apply those changes in 
separate commits which ONLY contain those changes and not mix it up with 
other changes to make review work easier.


Thanks for the initiative,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 04.07.22 um 17:24 schrieb Gil Portenseigne:

Hello Devs,

I would like to continue Codenarc integration in OFBiz (OFBIZ-11167).

For those who are not aware, Codenarc is an analysis tools for Groovy
for defects, bad practices, inconsistencies, style issues and more.

For this purpose we need to agree about the ruleset to put in place.

I took as a basis the ruleset :
https://codenarc.org/StarterRuleSet-AllRulesByCategory.groovy.txt

And started to fix some in https://github.com/apache/ofbiz-framework/pull/517

Before doing the complete work, a first rule made me wonder if that is a
choice that we will be doing as a community :

IfStatementBraces - Use braces for if statements, even for a single statement.

There are 234 occurrences in the project, and I guess that some opinions
might diverge on this subject.

Moreover, some rules needs lots of fixes in the project (those with more
than 200 occurrences) :

++-+
| Number of  | Rule name and details
   |
| occurrence |  
   |
++=+
| 9883   | UnnecessaryGString  - String objects should be created with 
single  |
||  quotes, and GString  objects created with double quotes. 
Creating  |
||  normal String objects with  double quotes is confusing to 
readers. |
++-+
| 4569   | DuplicateStringLiteral  - Code containing duplicate String 
literals |
||  can usually be improved by  declaring the String as a constant  
   |
|| field. The ignoreStrings property ()  can optionally specify a   
   |
|| comma-separated list of Strings to ignore.   
   |
++-+
| 4209   | SpaceAroundMapEntryColon  - Check for configured formatting of   
   |
|| whitespace around colons for  literal Map entries.   
   |
|| The characterBeforeColonRegex and  characterAfterColonRegex  
   |
|| properties specify a regular expression that  must match the 
   |
|| character before/after the colon.
   |
++-+
| 1448   | LineLength  - Checks the maximum length for each line of 
   |
|| source code. It checks for  number of characters, so lines   
   |
||  that include tabs may appear longer than  the allowed number
   |
||  when viewing the file. The maximum line length can  be  
   |
|| configured by setting the length property, which defaults to 
120.   |
++-+
| 885| UnnecessaryGetter  - Checks for explicit calls to 
getter/accessor   |
||  methods which can, for  the most part, be replaced by property  
   |
||  access. A getter is defined as a  method call that matches  
   |
|| get[A-Z] but not getClass() or get[A-Z][A-Z]  such as getURL().  
   |
||  Getters do not take method arguments. The  ignoreMethodNames
   |
|| property (null) can specify method names that should  be ignored 
   |
|| , optionally containing wildcard characters ('*' or '?').
   |
++-+
| 601| NoDef - def should not be used. You should replace it with   
   |
|| concrete type.   
   |
++-+
| 485| MethodReturnTypeRequired  - Checks that method return types  
   |
||  are not dynamic, that is they are  explicitly stated and
   |
||  different than def. 
   |
++-+
| 484| Indentation - Check indentation for class and method 
   |
|| declarations, and initial statements.
   |
++-+
| 482| Unnecessar

Re: Enable SOAP web services

[Michael Brohl]

Hi Jesús,

the SOAP client engine is disabled by default for security reasons, see 
https://lists.apache.org/thread/w9y9f72q4q2yr8hohryt7osmtx2xtpnz


You can reenable it by commenting in the engine in serviceengine.xml.

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 08.06.22 um 17:18 schrieb Jesús Fernández:

Hello everyone

I want to use SOAP web services.
I enable the services by putting export="true" in the xml of the services
that interest me, and then it is enabled to see the WSDL within the Ofbiz
web.
When I use the SoapUI for the endpoint:
"http://localhost:8080/webtools/control/SOAPService";
It gives me a 500 error and in the log "Unknown request [SOAPService]; this
request does not exist or cannot be called directly."
In the browser, the same thing happens when I call "
http://localhost:8080/webtools/control/SOAPService?wsdl";
It happens to me with 18.12 and with 20.01.
What have I forgotten to do?

Thanks in advance.

Re: [OFBIZ-10552] Remove AP AR webapps from accounting component - ASF JIRA

[Michael Brohl]

Hi Jacques,

I would be more favor of having the functionality in the accounting 
application, but being customizable/configurable to match the users needs.


(disclaimer: I am no accounting expert, though)

Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 24.04.22 um 10:42 schrieb Jacques Le Roux:

Hi,

Do we really want to do that?

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

Jacques

Re: Automating to get latest versions of js scripts with npm?

[Michael Brohl]

Hi Jacques,

the drawback of using latest is that things can break all of a sudden.

I would be in favor of using specified versions for ALL js libraries 
like we do it for the Java libraries in build.gradle.


Updating the JS libraries should be done explicitly together with 
necessary tests.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 08.04.22 um 16:49 schrieb Jacques Le Roux:

Hi,

Currently we load specific versions of js scripts (dependencies) with 
npm (see package.json)


npm has a "latest" option that allows to automatically load the latest 
versions of a js script.


We had only 3 js scripts versions that are not the latest. I changed 
all to load latest versions.


After checking things seem to work.

Does somebody see a problem with committing this change?

It should be transparent for users and if a committer see a change he 
can commit.


Jacques

Re: [NOTICE] Dependabot Updates enabled for all projects

[Michael Brohl]

Hi Jacques,

IMO it depends on what those PR's disclose openly.

If those PR's disclose significant vulnerabilities I would prefer to not 
use this. Maybe we should first investigate how Dependabot really works 
before we use it.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 05.04.22 um 09:31 schrieb Jacques Le Roux:

Hi Team,

If nobody see a problem with that I'll create a Jira for that in 3 
days, ie Friday morning


Thanks

Jacques

Le 05/04/2022 à 06:30, Chris Lambertus a écrit :

Hi folks,

Infra is pleased to announce that GitHub’s Dependabot service has 
been approved for use by ASF Legal and Infra, and is now enabled for 
all repos.  Dependabot will create PRs in your repo with recommended 
security updates for your project. It is entirely up to the project 
to accept or reject these PRs.


Dependabot Alerts can also be configured per-project, but currently 
the notifications go to Org Admins only. If your project wishes to 
receive Dependabot Alerts via email, please open an Infra Jira ticket 
so that we can add your committer team to the alerts.


-Chris
ASF Infra

Re: [INFRA-22722] Restart the ofbiz-vm3 demos server

[Michael Brohl]

I think we should think about supporting JDK 17 and maybe skip JDK 11. It is 
LTS also and will have longer support.

Thoughts?

Michael 



> Am 23.03.2022 um 17:58 schrieb Jacques Le Roux :
> 
> BTW,
> 
> Is there someone who is already using Java 11 with 18.12?
> 
> TIA
> 
> Jacques
> 
>> Le 23/03/2022 à 16:24, Jacques Le Roux a écrit :
>> Hi Michael,
>> 
>> I don't remember clearly why I had that in mind. I have just tried to run 
>> current 18.12 with Java 11 and so far it seems OK. I'll check that better...
>> 
>> Nevertheless, I'll already ask to install both Java 8 and 11 on the new VM 
>> (nothing started yet).
>> 
>> Thanks for the suggestion.
>> 
>> Jacques
>> 
>>> Le 18/03/2022 à 12:55, Jacques Le Roux a écrit :
>>> Hi Michael,
>>> 
>>> I suggest to tackle that, including the necessary on the VM, when we will 
>>> effectively switch 22.01 to JDK 11
>>> 
>>> Jacques
>>> 
>>> Le 18/03/2022 à 12:03, Michael Brohl a écrit :
>>>> Hi Jacques,
>>>> 
>>>> should we not also have a VM supporting Java 11 for the 22.01 release 
>>>> branch?
>>>> 
>>>> +1 for the rest of the specifications
>>>> 
>>>> Thanks,
>>>> 
>>>> Michael Brohl
>>>> 
>>>> ecomify GmbH - www.ecomify.de
>>>> 
>>>> 
>>>> Am 18.03.22 um 11:46 schrieb Jacques Le Roux:
>>>>> Hi,
>>>>> 
>>>>> Good news, demos will soon be back :).
>>>>> 
>>>>> Greg asked me to provide specs for a new OFBIZ-VM, I guess OFBIZ-VM4.
>>>>> 
>>>>> If nobody is against Monday I'll ask for the same than OFBIZ-VM3 (JDK 8, 
>>>>> 8GB RAM, letsencrypt). I guess it will be Ubuntu again.
>>>>> 
>>>>> JDK8 because it will still need to support 18.12 branch, 8GM RAM has 
>>>>> proven to be good enough for 3 demos so far.
>>>>> 
>>>>> What will change is the replacement of
>>>>> https://demo-old.ofbiz.apache.org/
>>>>> by
>>>>> https://demo-next.ofbiz.apache.org/
>>>>> 
>>>>> https://demo-stable.ofbiz.apache.org/
>>>>> and
>>>>> https://demo-trunk.ofbiz.apache.org/
>>>>> will stay of course.
>>>>> 
>>>>> I have things almost ready at 
>>>>> https://github.com/apache/ofbiz-tools/tree/master/demo-backup
>>>>> 
>>>>> Jacques
>>>>> 

Re: Welcome to Nicola Mazzoni and Giulio Speri as new committers

[Michael Brohl]

Congratulations and welcome, Nicola and Giulio!

Regards,

Michael

Am 21.03.22 um 21:26 schrieb Jacopo Cappellato:

The OFBiz PMC has invited Nicola Mazzoni and Giulio Speri as new
committers and we are glad to announce that they have accepted the
nomination.

On behalf of the OFBiz PMC, welcome on board!

Re: [INFRA-22722] Restart the ofbiz-vm3 demos server

[Michael Brohl]

Hi Jacques,

should we not also have a VM supporting Java 11 for the 22.01 release 
branch?


+1 for the rest of the specifications

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 18.03.22 um 11:46 schrieb Jacques Le Roux:

Hi,

Good news, demos will soon be back :).

Greg asked me to provide specs for a new OFBIZ-VM, I guess OFBIZ-VM4.

If nobody is against Monday I'll ask for the same than OFBIZ-VM3 (JDK 
8, 8GB RAM, letsencrypt). I guess it will be Ubuntu again.


JDK8 because it will still need to support 18.12 branch, 8GM RAM has 
proven to be good enough for 3 demos so far.


What will change is the replacement of
https://demo-old.ofbiz.apache.org/
by
https://demo-next.ofbiz.apache.org/

https://demo-stable.ofbiz.apache.org/
and
https://demo-trunk.ofbiz.apache.org/
will stay of course.

I have things almost ready at 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup


Jacques

Re: New proposal on Jira to drop support for derby and use docker instead

[Michael Brohl]

Hi,

inline...

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 08.03.22 um 19:11 schrieb Development:

I just don't see the necessity to drop Derby support and exclude those people 
who do not want to use Docker (for whatever reason) or need the current OOTB 
behaviour.
"need the current OOTB behaviour" is a interesting point.  Like even though 
ofbiz documentation says to not use derby in production, it's possible that people 
actually are.  I had not thought of that.
Do we have any way to figure out if people are actually doing that?


The advantage of the embedded Derby is that the database is wiped and 
rebuild/loaded with data fast and easy because the database files are 
simply deleted and rebuild. No extra dependency on another database, 
configuration or external container.


There are several scenarios where it is used, mostly during development 
and release management:


- OFBiz standard development (I always develop/test against the latest 
code incl. the latest demo data).


- continuous build/tests (buildbot, Jenkins etc.)

- check of the dist files for a new release 
(download/unzip/build/testIntegration)


- quick check of the latest trunk/release branch version with the 
original load data


- OFBiz demo instances, which are reset every night

- ...

I do not speak about production use and as far as I understand, you were 
talking about providing a demo for new users.


So providing a Docker demo might help to get new users started easily. 
This can be achieved without changing the OOTB behaviour and dropping 
Derby support as proposed.

Re: New proposal on Jira to drop support for derby and use docker instead

[Michael Brohl]

Please see my responses inline...

Regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 07.03.22 um 18:44 schrieb Development:

So let me try to summarize your response:

#1. The only reason to *keep* derby that you see is that we disagree on the relative difficultly of 
getting a "simple build and run" going using docker vs the difficulty of using the 
traditional "install java and follow the current instructions" way
#2. You'd like me to start going through the list of all the issues that I 
expect will end up as a derby constraint.

Is that correct?


I don't think I have said anything like that.

What I said was that it is not necessary to drop Derby support to 
provide the additional option for a Docker image.



  * Perhaps we are differing in how difficult we believe it is to install 
docker.  I have not used docker on windows.  Is docker difficult to install on 
windows?


I am not using Windows so I cannot tell. I'm using Docker on Mac.

As you can see in https://issues.apache.org/jira/browse/OFBIZ-10407 , I 
have provided a Docker image to be used so I'm familiar with Docker and 
see it as a good additional way to provide a demo system for interested 
users.


I just don't see the necessity to drop Derby support and exclude those 
people who do not want to use Docker (for whatever reason) or need the 
current OOTB behaviour.



As for my first issue that I expect will end up as a derby constraint, I'll 
start with my most recent issue that I run into regularly:
Before that, I should mention that I don't actually use derby so may be blaming some things are derby that are undue, 
by misunderstanding some of its abilities.  So I'll state it as a question.  It that relates to the table names being 
mangled.  For example: searching the list of tables on "employ" (to match either "employee" or 
"employment") misses the tables containing employee position because is is called "empl_position".
So my question is:  are table names mangled like that because we have the 
convention that index and constraint names include the tablename as a prefix, 
and that not mangling the names would have exceeded a derby limit on number of 
characters in a name?


I do not know exactly why each table has his name. But in your example, 
I would simply search for "empl" and would find what I need...

Re: New proposal on Jira to drop support for derby and use docker instead

[Michael Brohl]

Hi ? (no name given),

I don't see a reason to DROP the derby support in OFBiz and replace it 
with docker. What we can and should do is to offer is a docker demo 
besides this. There are already initiatives to do this.


In our experience, users already have problems with the simple build and 
run OFBiz offers, it is not reasonable to make this more difficult for 
them by having to install and run docker and OFBiz within.


Derby is not for production use, we state this clearly in the README's 
and production setup guides. It is for demo purposes and easily 
repeatable cleanAll/load scenarios which are also uses by buildbot for 
the official demos..


If you not just want to have a brief look at the Demos, you'll have to 
install Java anyway.


To use and load data into OFBiz, there is nothing more to do than 
configuration in the entityengine.xml file as for any other database. 
Derby is just the default.


Best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 06.03.22 um 23:20 schrieb Development:

I added a new proposal on Jira .  It is a proposal to drop support for derby 
and use docker instead (You'll need to read the issue/proposal for that to make 
sense)  The issue is at: https://issues.apache.org/jira/browse/OFBIZ-12588


This is a copy of the proposal:

Derby is unique in the list of supported databases in that it lacks many 
features that normal databases support, leading to Jira issues like: 
https://issues.apache.org/jira/browse/OFBIZ-6138 . If you need specific 
examples just ask.


Derby is already not recommended for production systems (which is good).   I'm going to 
speculate that the reason derby is supported is to have a easy way for people to download 
ofbiz and "just run it" to get the demo running.  Unfortunately this is not the 
case now as java is often not installed anymore, and when it is installed, it's often the 
wrong version of java for ofbiz.


I propose that we drop support for Derby and instead allow people to get the 
demo easily running by making a official docker demo of the current stable 
version that just comes with postgres in the docker image. (docker image is 
being worked on here https://issues.apache.org/jira/browse/OFBIZ-10407 ).  
Instead of requiring java to be installed, it would require docker to be 
installed, but I believe the odds of success for a user are higher with docker 
then dealing with the java version incompatibilities.

If you can think of a reason to keep derby after demos can be done through 
docker, please add your comments.



CONFIDENTIALITY NOTICE: This message is intended only for the use of the person 
or organization to which it is addressed or was intended to be addressed, and 
may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the 
intended recipient, or responsible for delivering the message to the intended 
recipient, you are hereby notified that any dissemination, distribution or 
copying of this communication is strictly prohibited. If you have received this 
communication in error, please notify the sender immediately by email and 
delete the original message immediately . The sender, its subsidiaries and 
affiliates, do not accept liability for any errors, omissions, corruption or 
virus in the contents of this message or any attachments that arise as a result 
of e-mail transmission. Thank you.

Re: [GitHub] [ofbiz-framework] mbrohl commented on pull request #496: Improved: List and Grid (OFBIZ-11345)

[Michael Brohl]

You don't get the point, Pierre.

You are actively REMOVING elements others have contributed and put 
effort in.


Shouldn't be too hard to understand.

Michael


Am 07.02.22 um 16:52 schrieb Pierre Smits:

*Re: Other contributors have taken their time to structure the code into
readable blocks and comment them.*
Other contributors have taken their time to provide clean code without

[...]