Re: [OFBIZ-12935] Test 2.3.33 FreeMarker release - ASF JIRA

[Jacques Le Roux]

Hi Nicolas,

No thank you, I just wait for the Freemarker vote to pass...

I have also created 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap

HTH

Jacques

Le 14/05/2024 à 17:20, Nicolas Malin a écrit :

Hello Jacques,

Do you need some help to move forward on this subject ?

Nicolas

Le 28/03/2024 à 10:05, Jacques Le Roux a écrit :

Hi,

Without negative answer this week, I'll set the 2.3.33 version on trunk next 
week

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

TIA (for your tests see also the patch in OFBIZ-12934)

Jacques

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

[Jacques Le Roux]

Le 09/05/2024 à 13:21, Jacques Le Roux a écrit :

Hi Michael,

Inline again

Le 08/05/2024 à 21:00, Jacques Le Roux a écrit :


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.


I'm unsure that these changes are not complete for every component and even if 
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a 
big deal to fix them once freezed.


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.


So you speak about other known issues than 
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you, 
not a big deal.

To complete, I guess you speak about 
https://issues.apache.org/jira/browse/OFBIZ-12928.
A large majority is completely done and resolved when needed (thanks to trunk 
demo logs)

Only 3 (on 46)  are pending:
https://issues.apache.org/jira/browse/OFBIZ-12951. I let a bit of time to 
Pierre. If it's still pending when we want to Freeze we should revert.
https://issues.apache.org/jira/browse/OFBIZ-12978. Nothing done there yet.
https://issues.apache.org/jira/browse/OFBIZ-13042. Waiting for a fix before 
pushing.

As ever with Pierre, we disagree about 
https://issues.apache.org/jira/browse/OFBIZ-13068.
As I said there, and knowing how it gets in such cases, I prefer to "keep this issue 
reopened and I'll not close your PR."

I have created 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap

Unrelated : I also plan to close a lot of old pending Jira soon...

Jacques


There is also https://issues.apache.org/jira/browse/OFBIZ-13049. But that's out 
of scope for the moment.

Re: Cleaning site repo

[Jacques Le Roux]

OK, make sense, let's wait

Le 09/05/2024 à 12:43, michael.br...@ecomify.de a écrit :

-1

I propose to wait until we have finished the move to the Hugo based website, 
review and then link to the corresponding confluence pages.

We are almost finished with Hugo, one of our students (Nurhak) takes care of 
it. He is currently at University and returns end of June to finish his work.

Best regards,

Michael



Am 09.05.2024 um 10:48 schrieb Jacques Le Roux :

Hi,

The pages

https://ofbiz.apache.org/user-stories.html
https://ofbiz.apache.org/service-providers.html
https://ofbiz.apache.org/about-ofbiz.html
https://ofbiz.apache.org/blog/ (It's only a link)

exists but are not maintained. I propose to remove them from the repo.
The News menu also would be now useless, so to be removed.

Opinions?

Jacques

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

[Jacques Le Roux]

Hi Michael,

Inline again

Le 08/05/2024 à 21:00, Jacques Le Roux a écrit :


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.


I'm unsure that these changes are not complete for every component and even if 
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a 
big deal to fix them once freezed.


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.


So you speak about other known issues than 
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you, 
not a big deal.

To complete, I guess you speak about 
https://issues.apache.org/jira/browse/OFBIZ-12928.
A large majority is completely done and resolved when needed (thanks to trunk 
demo logs)

Only 3 (on 46)  are pending:
https://issues.apache.org/jira/browse/OFBIZ-12951. I let a bit of time to 
Pierre. If it's still pending when we want to Freeze we should revert.
https://issues.apache.org/jira/browse/OFBIZ-12978. Nothing done there yet.
https://issues.apache.org/jira/browse/OFBIZ-13042. Waiting for a fix before 
pushing.

As ever with Pierre, we disagree about 
https://issues.apache.org/jira/browse/OFBIZ-13068.
As I said there, and knowing how it gets in such cases, I prefer to "keep this issue 
reopened and I'll not close your PR."

I have created 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+24.xx+Roadmap

Unrelated : I also plan to close a lot of old pending Jira soon...

Jacques

Cleaning site repo

[Jacques Le Roux]

Hi,

The pages

https://ofbiz.apache.org/user-stories.html
https://ofbiz.apache.org/service-providers.html
https://ofbiz.apache.org/about-ofbiz.html
https://ofbiz.apache.org/blog/ (It's only a link)

exists but are not maintained. I propose to remove them from the repo.
The News menu also would be now useless, so to be removed.

Opinions?

Jacques

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

[Jacques Le Roux]

Ah, last but not least: I think we should at least wait for Freemarker 2.3.33 that we successfully tested on demo. The vote should be soon, hence the 
release.


Le 08/05/2024 à 20:47, Jacques Le Roux a écrit :

Thanks to clarify Michael,

Inline when needed...

Le 08/05/2024 à 13:59, Michael Brohl a écrit :

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


I guess you speak about https://issues.apache.org/jira/browse/OFBIZ-12995 ?




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.


I'm unsure that these changes are not complete for every component and even if 
it's the case it should not block the creation of a release branch.
And if ever issues remain (not necessarily related to these changes) it's not a 
big deal to fix them once freezed.


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.


So you speak about other known issues than 
https://issues.apache.org/jira/browse/OFBIZ-12995.
Have you a clear view about them ? Else my answer to 4. should be reassure you, 
not a big deal.
What helped me a lot in this recent experience is to review the demos logs 
(stable and trunk).
I remember a project I worked on and was the last person to leave because they 
needed me to scrutinise the logs :)




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.

That would be good, we used roadmaps in the past. Not all among them were 
successful or even followed.

IIRW the 1st one was mostly successful: 
https://cwiki.apache.org/confluence/display/OFBIZ/4.x+Proposed+Roadmap+Items

Others maybe less, just search "roadmap" in the wiki. Most were created by Sharan. Just to give an idea, here is one roadmap seriously discussed 
(most others were less).

https://cwiki.apache.org/confluence/display/OFBIZ/Roadmap+Diagrams+-+In+Progress

We also need to plan the time we want to give to fix the release branch before 
releasing. We use to finish it in the current year.
From my OFBiz experience, it's just a plan anyway, ie it can be shorter or 
longer.




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.


Yes, thanks

Jacques



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 lat

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

[Jacques Le Roux]

elease 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,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the

trunk

branch.

Instead we take the approach of creating a new branch from trunk,

named

something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the

release-24.05

branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira,

and

once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release

branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford




--
Daniel Watford

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

[Jacques Le Roux]

Thanks for confirming

Le 08/05/2024 à 15:45, Pranay Pandey a écrit :

Hi Jacques,

Yeah, I wanted to say that. As long as we are sure of test coverage, all
the critical paths are working.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 22:11, Jacques Le Roux 
wrote:


Ha sorry Pranay,

I did not get your point, I guess you were discussing before frezzing the
release branch, right?
Then of course we can't guarantee to have fixed all known bugs.
Only blocker bugs (decided by the reporter and discussed if needed) and of
course security bugs are blocking a release.

Jacques

Le 07/05/2024 à 17:42, Jacques Le Roux a écrit :

Hi Pranay,

OK, but then only that? So far we backported any bug. So we would

release a branch with bugs in?

Le 07/05/2024 à 16:42, Pranay Pandey a écrit :

Hi Jacques,

what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the

process

level.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 19:48, Jacques Le Roux <

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

wrote:


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,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually

are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the

trunk

branch.

Instead we take the approach of creating a new branch from trunk,

named

something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the

release-24.05

branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira,

and

once addressed the release would be made public. A suitable tag -

e.g.

release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development

community/PMC

decide when would be an appropriate time to create a new release

branch.

It seems like the major project undertakings - such as the movement

of

Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

CVE-2024-32113: Apache OFBiz: Path traversal leading to RCE

[Jacques Le Roux]

Severity: important

Affected versions:

- Apache OFBiz before 18.12.13

Description:

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') 
vulnerability in Apache OFBiz.This issue affects Apache OFBiz: before 18.12.13.

Users are recommended to upgrade to version 18.12.13, which fixes the issue.

Credit:

Qiyi Zhang (RacerZ) @secsys from Fudan (finder)

References:

https://ofbiz.apache.org/download.html
https://ofbiz.apache.org/security.html
https://issues.apache.org/jira/browse/OFBIZ-13006
https://lists.apache.org/thread/np8vgzr06z6cwm3tz7cs3609bdrj8526
https://ofbiz.apache.org/
https://www.cve.org/CVERecord?id=CVE-2024-32113

Re: [VOTE] [RESULT] Apache OFBiz 18.12.13

[Jacques Le Roux]

OK, thanks Jacopo

Le 08/05/2024 à 13:50, Jacopo Cappellato a écrit :

Yes, it is normal because that is the dev distribution folder: as soon
as the release becomes official the files are moved to the official
distribution folder: https://downloads.apache.org/ofbiz/

Jacopo

On Tue, May 7, 2024 at 4:07 PM Jacques Le Roux
 wrote:

Hi Jacopo,

I see only KEYS

TIA

Jacqued

Le 07/05/2024 à 11:41, Jacopo Cappellato a écrit :

The vote is successful with seven positive votes (all binding) and no
negative votes.
I am going to publish and announce the release soon.

Jacopo

On Tue, Apr 30, 2024 at 5:06 PM Jacopo Cappellato
 wrote:

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

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

[Jacques Le Roux]

I totally agree, our enemy is regression and we should be very sure to avoid it.

Le 07/05/2024 à 17:19, Pranay Pandey a écrit :

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,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the

trunk

branch.

Instead we take the approach of creating a new branch from trunk,

named

something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the

release-24.05

branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira,

and

once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above des

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

[Jacques Le Roux]

Ha sorry Pranay,

I did not get your point, I guess you were discussing before frezzing the 
release branch, right?
Then of course we can't guarantee to have fixed all known bugs.
Only blocker bugs (decided by the reporter and discussed if needed) and of 
course security bugs are blocking a release.

Jacques

Le 07/05/2024 à 17:42, Jacques Le Roux a écrit :

Hi Pranay,

OK, but then only that? So far we backported any bug. So we would release a 
branch with bugs in?

Le 07/05/2024 à 16:42, Pranay Pandey a écrit :

Hi Jacques,

what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the process
level.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 19:48, Jacques Le Roux 
wrote:


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,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the trunk
branch.

Instead we take the approach of creating a new branch from trunk, named
something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the release-24.05
branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and
once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

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

[Jacques Le Roux]

Le 07/05/2024 à 17:01, Daniel Watford a écrit :

Hi Jacques,

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


Simple, what is the process so far?

We freeze the trunk into a release branch, says 24.xx in our case
.05 seems short to me, though possible, as we need to check the situation for 
important things to be complete (or not), like OFBIZ-9350
I see the recent good will of Nicolas about that. We should not put the 
pression on anybody. Errors come from such situations.

Then improvements are of course allowed in trunk but not in 24.xx apart 
exceptions agreed with a consensus (lazy or not, ie with a vote)
As we use the CTR (Commit Then Review) mode it's always possible to revert 
before releasing, here 24.xx. So no known damage is theoretically possible.

Blocker bugs are used to prevent a release as long as not fixed, as mentioned 
at :
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
There is no strict definition for a blocker bug. The reporter decides. It can 
be then discussed.
Of course security is blocking, but we don't publish any information about it 
before releasing. Else it's a zero day for attackers.



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 just try to explain that the current process is OK.
We never feature-freezed the trunk but the upcoming release, again with very 
rare exceptions.
So I'd like to know what should be changed if any.



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 agree about that. We have never been able to fix all bugs. Just blocker bugs 
block the release and that can be discussed.
For blocker bugs, if we don't agree in Jira or PR we discuss it on dev ML to 
tend to a consensus. That can be a lazy one (no vote) if nobody is against.



I personally would want to avoid backporting changes from trunk to a
release branch without good reason since I view this as duplicate work.


Only bugs are backported, except (very rare) exceptions



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.


And if everybody is OK. A veto can block a commit (not a release) but that must 
be justified:
https://www.apache.org/foundation/voting.html



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.


Yes that's it. We could maybe slightly change this sentence to explain that 
very important improvements may be rarely backported.



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


Exactly, the devil is in the details and we get sometimes lost.




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?


That need to be discussed IMO. With clear cases, like OFBIZ-9350 but not only.
We still need to find and agree about possible other cases I guess, hence 3 
weeks being short to me.



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?


I prefer that we openly discuss that here (dev ML) before allowing improvements 
in release branches.

I hope I'm clear :)

Thanks

Jacques




Thanks,

Dan.

On Tue, 7 May 2024 at 15:20, Jacques Le Roux
wrote:


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 'rel

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

[Jacques Le Roux]

Hi Pranay,

OK, but then only that? So far we backported any bug. So we would release a 
branch with bugs in?

Le 07/05/2024 à 16:42, Pranay Pandey a écrit :

Hi Jacques,

what is a blocker bug, only security?
I think it should also include anything broken on the UI or at the process
level.

Best regards,
Pranay Pandey


On Tue, 7 May 2024 at 19:48, Jacques Le Roux 
wrote:


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,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are

in

this thread. I think this is because the differences are minor and we

are

probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it

seems

there is a desire to NOT impose any sort of feature freeze on the trunk
branch.

Instead we take the approach of creating a new branch from trunk, named
something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming

OFBiz

release. New features would not normally be applied to the release-24.05
branch, but exceptions to this rule would be considered on a

case-by-case

basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and
once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to

denote

the commit that was publicly released.

I believe the above describes how the OFBiz project has managed

releases in

the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now

might

be a good time to go ahead and create the release-24.05 branch from

trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux <

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

wrote:


Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

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

[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,

Pranay Pandey


On Tue, 7 May 2024 at 13:36, Daniel Watford  wrote:


Hello all,

I'm a little confused by what the differences in opinions actually are in
this thread. I think this is because the differences are minor and we are
probably close to an agreement on how to proceed.

Although there are not many of us involved in this conversation, it seems
there is a desire to NOT impose any sort of feature freeze on the trunk
branch.

Instead we take the approach of creating a new branch from trunk, named
something like 'release-24.05'. The purpose of this new branch is to
address any issues that might be considered blockers for an upcoming OFBiz
release. New features would not normally be applied to the release-24.05
branch, but exceptions to this rule would be considered on a case-by-case
basis.

Issues blocking an OFBiz 24.05.xx release would be tracked in Jira, and
once addressed the release would be made public. A suitable tag - e.g.
release-24.05.01 - would be applied to the release-24.05 branch to denote
the commit that was publicly released.

I believe the above describes how the OFBiz project has managed releases in
the past.

The discussions around a road map are orthogonal to the above release
process, but would definitely help the OFBiz development community/PMC
decide when would be an appropriate time to create a new release branch.

It seems like the major project undertakings - such as the movement of
Groovy Scripts within the source tree - have been completed, so now might
be a good time to go ahead and create the release-24.05 branch from trunk.

Thanks,

Dan.

On Mon, 6 May 2024 at 18:01, Jacques Le Roux 
Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :

BTW, to avoid to speak in the void. Again, what are those tasks

precisely? And that are their situations?

BTW, to avoid to speak in the void. Again, what are those tasks

precisely?

And WHAT are their situations?

Sorry, typo



--
Daniel Watford

Re: [VOTE] [RESULT] Apache OFBiz 18.12.13

[Jacques Le Roux]

Hi Jacopo,

I see only KEYS

TIA

Jacqued

Le 07/05/2024 à 11:41, Jacopo Cappellato a écrit :

The vote is successful with seven positive votes (all binding) and no
negative votes.
I am going to publish and announce the release soon.

Jacopo

On Tue, Apr 30, 2024 at 5:06 PM Jacopo Cappellato
 wrote:

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

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

[Jacques Le Roux]

Le 06/05/2024 à 18:35, Jacques Le Roux a écrit :
BTW, to avoid to speak in the void. Again, what are those tasks precisely? And that are their situations? 


BTW, to avoid to speak in the void. Again, what are those tasks precisely? And 
WHAT are their situations?

Sorry, typo

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

[Jacques Le Roux]

BTW, to avoid to speak in the void. Again, what are those tasks precisely? And 
that are their situations?

Le 06/05/2024 à 18:24, Jacques Le Roux a écrit :

Hi Stephen,

As I can see it, because of the number of people really involved in such tasks.

Jacques

Le 06/05/2024 à 17:45, Stephen Davidson a écrit :

Good afternoon.

Maybe I am missing something, but why can't WIP be executed finished & 
stabilized on the Release Branch and then merged to Trunk?

Regards,
Steve

On 5/6/24 04:07, Jacques Le Roux wrote:

Hi,

We should 1st clearly identify WIPs in trunk and at which stage they are each.

We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


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

ecomi

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

[Jacques Le Roux]

Hi Stephen,

As I can see it, because of the number of people really involved in such tasks.

Jacques

Le 06/05/2024 à 17:45, Stephen Davidson a écrit :

Good afternoon.

Maybe I am missing something, but why can't WIP be executed finished & 
stabilized on the Release Branch and then merged to Trunk?

Regards,
Steve

On 5/6/24 04:07, Jacques Le Roux wrote:

Hi,

We should 1st clearly identify WIPs in trunk and at which stage they are each.

We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


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: [PROPOSAL] freeze trunk for new features in favor of a release 24.x branch preparation / future roadmap

[Jacques Le Roux]

Hi,

We should 1st clearly identify WIPs in trunk and at which stage they are each.

We can't wait and complicate the situation before that.

Jacques

Le 06/05/2024 à 10:36, gil.portenseigne a écrit :

Hi,

I feel like Michael, when there are 'in progress' work in trunk, when we
create a release branch for stabilisation, the remaining work of such
task will only be in trunk (since those are improvements).

But delaying release is not good when we look at the name of our last
release that show the 2018 year.

The concession we could agree on should be to identify such tasks to let
user know the partial improvements contained in the release.

i.e. creating release branch + roadmap :)

WDYT ?

Gil
On 22/04/24 04:12, Jacques Le Roux wrote:

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


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: [VOTE] [RELEASE] Apache OFBiz 18.12.13

[Jacques Le Roux]

Thanks Jacopo,

<<./verify-ofbiz-release.sh -a apache-ofbiz-18.12.13>> works perfectly on 
Ubuntu 20.04

+1

Jacques

Le 30/04/2024 à 17:06, Jacopo Cappellato a écrit :

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

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

[Jacques Le Roux]

Le 22/04/2024 à 16:12, Jacques Le Roux a écrit :

Without getting into details, I tend to disagree with your propositions.

I start writing that. Maybe I should rather have started by saying that I don't 
understand why we should change our (simple) way of doing.

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

[Jacques Le Roux]

Hi Guys,

Without getting into details, I tend to disagree with your propositions. I 
can't see why we would change our very simple way of doing.

When we freeze a branch, the activity can continue on trunk. It does not 
interfere with the new release branch.
The only variable is the period we allow before releasing the branch. Then, 
that depends on the breaking changes (or not) we recently made.

Why should we change? I fear it will rather introduce complications. Please 
keep it simple.

TIA for your explanations on simple reasons to change : what is wrong with our 
current way of doing?

Jacques

Le 22/04/2024 à 09:37, Daniel Watford a écrit :

Hi Michael,

I'm broadly in favour of your proposal, but perhaps with a slightly
different 'shape' to the approach.

I too was hoping that we could freeze trunk before creating a 24.x release
branch as I was concerned about the about of duplicate work (backporting)
that might need to be done if we took a 24.x release branch earlier in the
year, but alas trunk marches on and I think it will be difficult to
mandate a period of release-related-only changes in trunk.

Instead I think, as Deepak mentioned, we should take a new 24.x branch to
use for stabilisation - with tags denoting the actual releases along that
branch. It feels that the large projects - such as groovy-scripts migration
- have completed which should reduce the amount of rework that would have
to take place simultaneously on trunk and the 24.x release branch.

>From your comments I infer that you may be suggesting yearly releases. I
think this is a good idea as it will allow the introduction of major new
functionalities in trunk without needing to wait years for them to become
generally accessible. Without more frequent releases we will have the
temptation to port major functionality into already existing release
branches which might take a large amount of effort and could introduce
instability between minor releases. I hope my inference reflects your
intended proposal! :)

Yes to a roadmap.

Thanks,

Dan.


On Sun, 21 Apr 2024 at 14:50, Michael Brohl 
wrote:


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: (ofbiz-framework) branch trunk updated: Improved: FACILITY- Move from hard-coded menu location to parameterized (OFBIZ-12976) (#758)

[Jacques Le Roux]

Hi,

Just FYI: I inadvertently pushed /webapp/common-theme/js/package-lock.json 
which was part of Pierre's PR. It uses lockfileVersion 3.

So it was build with npm 9* which is "Backwards compatible to npm v7." Actually it's also "Backwards compatible to v1 lockfiles as I experienced 
(using Win7 I stuck with Node.js v13.14.0 hence npm 8.1.0)


* https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json

Jacques

Le 17/04/2024 à 17:24, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch trunk
in repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/trunk by this push:
  new 98d2b78bec Improved: FACILITY- Move from hard-coded menu location to 
parameterized (OFBIZ-12976) (#758)
98d2b78bec is described below

commit 98d2b78bece10ac2ddea7e75bcb66dd4aa7276fc
Author: Pierre Smits
AuthorDate: Wed Apr 17 17:24:49 2024 +0200

 Improved: FACILITY- Move from hard-coded menu location to parameterized 
(OFBIZ-12976) (#758)
 
 Improved: FACILITY- Move from hard-coded menu location to parameterized (OFBIZ-12976)
 
 Move the menu location in the various facility screens from hard-coded to parameterized.
 
 modified: CommonScreens.xml, FacilityGroupScreens.xml, FacilityScreens.xml

 changed location of various menus from hard-coded to parameterized
 
 modified:

 - FacilitiesMenus.xml: added menus re shipment
 - ShipmentScreens.xml: changed location of menus from hard-coded to 
parameterized
 
 Improved: Move the menu location in the various facility screens from hard-coded to parameterized. (OFBIZ-12976)
 
 removed: ShipmentMenus.xml

---
  .../product/widget/facility/FacilityMenus.xml  | 128 +
  .../facility/ShipmentGatewayConfigScreens.xml  |   2 +-
  .../product/widget/facility/ShipmentMenus.xml  | 152 -
  .../product/widget/facility/ShipmentScreens.xml|   4 +-
  .../webapp/common-theme/js/package-lock.json   |  81 ---
  5 files changed, 191 insertions(+), 176 deletions(-)

diff --git a/applications/product/widget/facility/FacilityMenus.xml 
b/applications/product/widget/facility/FacilityMenus.xml
index 2661f121fc..b97e881d06 100644
--- a/applications/product/widget/facility/FacilityMenus.xml
+++ b/applications/product/widget/facility/FacilityMenus.xml
@@ -318,5 +318,133 @@ under the License.
  
  
  
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
  
  
diff --git 
a/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml 
b/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml
index 7b3f2a812e..2458d9f385 100644
--- a/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml
+++ b/applications/product/widget/facility/ShipmentGatewayConfigScreens.xml
@@ -29,7 +29,7 @@ under the License.
  
  
  
-
+
  
  
  
diff --git 

Re: (ofbiz-framework) branch CharlesNereide-seo-improvements created (now d272bbf512)

[Jacques Le Roux]

I no longer maintain the 22.01 branch, but use "git push all" when backporting to 18.12 Not sure what happened there, we can neglect it anyway : "No 
new revisions were added by this update."


Jacques

Le 11/04/2024 à 11:14, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a change to branch CharlesNereide-seo-improvements
in repositoryhttps://gitbox.apache.org/repos/asf/ofbiz-framework.git


   at d272bbf512 Improved: Remove duplicate create trigger from catalog 
main template (OFBIZ-12953) (#738)

No new revisions were added by this update.

Re: Discussion on OFBiz Tomcat upgrade

[Jacques Le Roux]

Hi,

There is yet no specified EOL for Tomcat 9. We can expect 2027: 
https://lists.apache.org/thread/qlzpscgoqct9wspkj5qjkm34s66jswj0

I guess Daniel thought about freezed (for 24.xx) rather than released. I guess 
we all agree on that.

Gaetan can of course start to work on the Tomcat 10 migration and even on 
Prometheus plugin idea as own forks.
Maybe we could even create framework and plugins feature branches. But I doubt 
there will be much help for now.

Jacques

Le 11/04/2024 à 09:09, Michael Brohl a écrit :

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: UEL migration

[Jacques Le Roux]

Le 10/04/2024 à 09:45, Florian Motteau a écrit :
Sure, I just question the fact that this important discussion (updating tomcat, which leads to a lot of work/implications) occurs via a remote task. 
It may need its own thread (updating tomcat : yes ? no ? why ? how ? people insights about this subject). 


+1

Jacques

Re: Any ideas on how to make demo-site logs accessible and whether it is safe to do so?

[Jacques Le Roux]

Hi Daniel, Team,

For 3 days now I have collected trunk demo errors in error.log.

I have created https://issues.apache.org/jira/browse/OFBIZ-13005 for that

Jacques

Le 29/02/2024 à 16:15, Daniel Watford a écrit :

Hello,

I was just checking the demo-stable logs - accessible on ofbiz-vm1 at
/home/ofbizdocker/demo-stable/logs - and found plenty of interesting stack
traces that would be good candidates for investigation.

Given that the demo sites use well known administrator passwords and should
not contain any sensitive information, how would the project's members feel
about making these logs automatically accessible to any interested parties?

If it is deemed appropriate to make the logs publicly accessible, we then
need to figure out how we could technically do so.

One approach I can think of is to add some Alias directives (
https://httpd.apache.org/docs/current/mod/mod_alias.html#alias) to the
Apache HTTP Server configuration to map relevant paths to the logs
directory of each demo site. For example, to the demo-trunk 
configuration, we could add:

Alias "/logs" "/home/ofbizdocker/demo-trunk/logs"

Similarly, to the demo-stable  configuration we would add:

Alias "/logs" "/home/ofbizdocker/demo-stable/logs"

We would then configure directory listings in Apache HTTP Server for those
log directory locations allowing access via a web browser.

There is some pre-existing functionality in Web Tools to access logs, but
it does require interaction through the OFBiz UI. The ability to retrieve
demo-site logs via an unauthenticated HTTP(S) get request might offer some
opportunities to automatically scan for a particular class of error and
might make it easier for ofbiz developers to check on the demo logs from
time to time.

Thanks,

Dan.

Re: Groovy integration tests

[Jacques Le Roux]

Hi Gil, Nicolas,

I agree it was a good thing to do. We just missed some information and 
documentation.
I have added some at OFBIZ-12320

I have also replaced all groovy-test-suite by junit-test-suite in OOTB code.

I still wonder why Eclipse proposes but does not accept groovy-test-suite as a 
right token and shows this message:

   <>

when in https://ofbiz.apache.org/dtds/test-suite.xsd 
 there is no important
differences between junit-test-suite and groovy-test-suite definitions

Actually it's not too bad for committers. It makes you wonder and read the documentation. So learn that groovy-test-suite should better not used in 
production.


TIA

Jacques

Le 09/09/2021 à 09:43, Nicolas Malin a écrit :

I endorse the words,

I currently implement some new test for
https://issues.apache.org/jira/browse/OFBIZ-6988, and after 3 hours to
build ofbiz, it's really boring without clear most valuable.

If for technical best practice it's better to keep test compile, it's
possible when you test write is terminate to move the groovy-test-suite
to junit-test-suite, so no reason to remove the possibility to write
test as script.

Nicolas

On 08/09/2021 15:30, Gil Portenseigne wrote:

Hello,

Currently using release 18.12 for some project we got the habit to
develop using integration test while developing in groovy.

For that usage we use mainly :
 groovy-test-suite

That allow coding tests in groovy script that do not need to be compiled
for their execution and executing them from webtools [1] (small
improvement will be contributed soon), there is no need to reboot the
local dev OFBiz instance for each modification in that test.

But these type of test has been removed with OFBIZ-11165 [2], while I
thinks that these resources are better compiled, during development
process, not having to restart OFBiz is nice.

So if nobody is against, I will reintroduce it in trunk with a note
explaining the `dev` usage.

WDYT

Regards,

Gil

[1]https://localhost:8443/webtools/control/TestSuiteInfo
[2]https://issues.apache.org/jira/browse/OFBIZ-11165

Re: Buildbot failure in on ofbizTrunkFramework

[Jacques Le Roux]

WIP with https://issues.apache.org/jira/browse/OFBIZ-12995

Le 04/04/2024 à 19:13, build...@apache.org a écrit :

Build status: BUILD FAILED: failed './gradlew --no-daemon ...' (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/49/builds/843
Blamelist: Jacques Le Roux 
Build Text: failed './gradlew --no-daemon ...' (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] d559ea8ca1ce4d93fe38ac0099137f9c238252e7


Steps:

   worker_preparation: 0

   git: 0

   build: 0

   loadAll: 0

   testIntegration: 2


-- ASF Buildbot

Re: Groovy tests fails in trunk (OK in 18.12)

[Jacques Le Roux]

Sorry for the buzz (and multiple description editions), it seems easier than I 
thought...

Le 01/04/2024 à 12:55, Jacques Le Roux a écrit :

Hi,

Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985

TIA

Jacques

Groovy tests fails in trunk (OK in 18.12)

[Jacques Le Roux]

Hi,

Please have a look at https://issues.apache.org/jira/browse/OFBIZ-12985

TIA

Jacques

[OFBIZ-12935] Test 2.3.33 FreeMarker release - ASF JIRA

[Jacques Le Roux]

Hi,

Without negative answer this week, I'll set the 2.3.33 version on trunk next 
week

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

TIA (for your tests see also the patch in OFBIZ-12934)

Jacques

Re: Shiro and Maven

[Jacques Le Roux]

It was that.

In Gradle I used
org.apache.shiro:shiro-crypto:2.0.0
instead of
org.apache.shiro:shiro-crypto-cipher:2.0.0
I started from https://mvnrepository.com/artifact/org.apache.shiro using core 
then switched to crypto, forgoting cipher.

I don't work how that worked in a situation (w/ OFBiz plugins) and not another 
(w/o OFBiz plugins).
As you suggested (pulling in the old version somewhere unexpectedly) maybe the 
reason.
Though I tried with Gradle --no-cache-build. Anyway who cares now ;)

Remains an issue with HashRequest. I'll have a look at 
https://github.com/apache/shiro/issues/1022
And https://www.google.fr/search?q=%22shiro+2.0.0%22+Hash=UTF-8 globally
It's time for us to envisage argon or such...

Thanks again

Jacques

Le 24/03/2024 à 17:35, le...@flowlogix.com a écrit :

Make sure to look at the dependency tree, I bet you are pulling in the old 
version somewhere unexpectedly.


On Mar 24, 2024, at 11:32 AM, Jacques Le Roux  
wrote:

Thanks Lenny,

Oops, indeed it should be 2.0.0 everywhere. Else nothing would work ;)

I did not want to repeat all what's in links, that why I just put links.

Anyway, I'll have a look at Crypto classes’ package names, easier than anything 
else.
I'm though surprised that it works with current names when we have the 3 
org.apereo.cas packages in the classpath.

Maybe we miss something else...

Jacques

Le 24/03/2024 à 15:54,le...@flowlogix.com  <mailto:le...@flowlogix.com>  a 
écrit :

I am not quite sure that there enough information here to help…
First, you mention shiro-core 2.2.0 (vs. 2.0.0) are you sure you have the 
correct version?

Crypto classes’ package names have changed. All you would need to do is change 
Java source to reflect this.


On Mar 24, 2024, at 3:51 AM, Jacques Le Roux  
<mailto:jacques.le.r...@les7arts.com>  wrote:

Hi,

We (the Apache OFBiz project) use Shiro mostly for ciphering.
We use Gradle and refer to Maven for dependencies.

We recently upgraded from 1.13.0 to 2.0.0
https://issues.apache.org/jira/browse/OFBIZ-12961  
<https://issues.apache.org/jira/browse/OFBIZ-12961>  
<https://issues.apache.org/jira/browse/OFBIZ-12961>  
<https://issues.apache.org/jira/browse/OFBIZ-12961>
As we we had only this dependency, I started by replacing shiro-core:1.13.0 by 
shiro-core:2.2.0
It did not work (mostly AesCipherService creation compile errors).

I then tried only shiro-crypto:2.0.0 and It worked.

Then (thanks to our CI) we discovered that there was other dependencies related 
to org.apereo.cas:cas-server
https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>

So I added them withhttps://github.com/apache/ofbiz-framework/commit/61f5831400  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>

This morning I removed them and tried to add shiro-core:2.2.0, to no avail.

If it's possible, could you please give us more information to get read of the 
org.apereo.cas:cas-server  dependencies?

Thanks in advance

Jacques

Re: Shiro and Maven

[Jacques Le Roux]

Thanks Lenny,

Oops, indeed it should be 2.0.0 everywhere. Else nothing would work ;)

I did not want to repeat all what's in links, that why I just put links.

Anyway, I'll have a look at Crypto classes’ package names, easier than anything else. I'm though surprised that it works with current names when we 
have the 3 org.apereo.cas packages in the classpath.


Maybe we miss something else...

Jacques

Le 24/03/2024 à 15:54, le...@flowlogix.com a écrit :

I am not quite sure that there enough information here to help…
First, you mention shiro-core 2.2.0 (vs. 2.0.0) are you sure you have the 
correct version?

Crypto classes’ package names have changed. All you would need to do is change 
Java source to reflect this.


On Mar 24, 2024, at 3:51 AM, Jacques Le Roux  
wrote:

Hi,

We (the Apache OFBiz project) use Shiro mostly for ciphering.
We use Gradle and refer to Maven for dependencies.

We recently upgraded from 1.13.0 to 2.0.0
https://issues.apache.org/jira/browse/OFBIZ-12961  
<https://issues.apache.org/jira/browse/OFBIZ-12961>
As we we had only this dependency, I started by replacing shiro-core:1.13.0 by 
shiro-core:2.2.0
It did not work (mostly AesCipherService creation compile errors).

I then tried only shiro-crypto:2.0.0 and It worked.

Then (thanks to our CI) we discovered that there was other dependencies related 
to org.apereo.cas:cas-server
https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz  
<https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz>

So I added them withhttps://github.com/apache/ofbiz-framework/commit/61f5831400  
<https://github.com/apache/ofbiz-framework/commit/61f5831400>

This morning I removed them and tried to add shiro-core:2.2.0, to no avail.

If it's possible, could you please give us more information to get read of the 
org.apereo.cas:cas-server  dependencies?

Thanks in advance

Jacques

Shiro and Maven

[Jacques Le Roux]

Hi,

We (the Apache OFBiz project) use Shiro mostly for ciphering.
We use Gradle and refer to Maven for dependencies.

We recently upgraded from 1.13.0 to 2.0.0
https://issues.apache.org/jira/browse/OFBIZ-12961

As we we had only this dependency, I started by replacing shiro-core:1.13.0 by 
shiro-core:2.2.0
It did not work (mostly AesCipherService creation compile errors).

I then tried only shiro-crypto:2.0.0 and It worked.

Then (thanks to our CI) we discovered that there was other dependencies related 
to org.apereo.cas:cas-server
https://lists.apache.org/thread/cszft6134oon9tx0xy0wn3hgvh4ogbpz

So I added them with https://github.com/apache/ofbiz-framework/commit/61f5831400 This morning I removed them and tried to add shiro-core:2.2.0, to no 
avail.


If it's possible, could you please give us more information to get read of the 
org.apereo.cas:cas-server dependencies? Thanks in advance

Jacques

Re: [FYI] No relation longer between Git commits and Jira comments

[Jacques Le Roux]

Fixed

Le 23/03/2024 à 07:23, Jacques Le Roux a écrit :

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

Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0

[Jacques Le Roux]

After completely removing LDAP, adding this works too:

diff --git a/dependencies.gradle b/dependencies.gradle
index b1a2e29..bb89c2e 100644
--- a/dependencies.gradle
+++ b/dependencies.gradle
@@ -83,0 +84,3 @@
+    implementation 'org.apereo.cas:cas-server-core-api-authentication:5.0.10'
+    implementation 'org.apereo.cas:cas-server-core-util:5.0.10'
+    implementation 'org.apereo.cas:cas-server-support-ldap-core:5.0.10'

Still not sure what to do yet anyway

Jacques

Le 23/03/2024 à 12:11, Jacques Le Roux a écrit :

Thanks Daniel for the quick answer :)

Maybe in the meantime we could simply "comment out" the ldap plugin, not sure 
how yet...

Jacques

Le 23/03/2024 à 11:56, Daniel Watford a écrit :

Hi Jacques,

Here's the cause of the failure for the docker-image github workflow:

#31 31.81 > Task :buildSrc:build
#31 60.80
#31 60.80 > Task :compileJava
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:43:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.AesCipherService;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:44:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.OperationMode;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:45:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.PaddingScheme;

Whichever module provides org.apache.shiro.crypto is missing. But it's odd
that the gradle github workflow doesn't have a problem...

The difference between the two is that the gradle github workflow includes
the plugins, whereas the failing part of the docker-image workflow does not.

I confirmed the behaviour with some local builds:
- without plugins: Build fails
- with plugins: Build succeeds.

We can use './gradlew dependencies' to review the dependency tree.
Searching the tree for shiro we find:
- org.apache.shiro:shiro-core:1.3.2
- - > org.apereo.cas:cas-server-core-api-authentication:5.0.10
- - - > org.apereo.cas:cas-server-core-util:5.0.10
- - - - > org.apereo.cas:cas-server-support-ldap-core:5.0.10
- - - - - > project :plugins:ldap

So the missing dependency is getting brought in through the ldap plugin.

The above suggests we should consider removing the plugins from the gradle
github workflow, or at least consider creating two workflows, one with and
one without plugins.

Thanks,

Dan.





On Sat, 23 Mar 2024 at 10:28, Jacques Le Roux 
wrote:


Hi,

I'd appreciate confirmations about local build.
And, before reverting, if you have an idea don't hesitate :)

TIA

Jacques

Le 23/03/2024 à 11:23, Jacques Le Roux (Jira) a écrit :

  [
https://issues.apache.org/jira/browse/OFBIZ-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830052#comment-17830052 


]

Jacques Le Roux commented on OFBIZ-12961:
-

There are currently some, for now, incomprehensible issues while

building.

It works locally on both Win7 and Ubuntu 20.04:


{noformat}
C:\projectsASF\Git\ofbiz-framework>gradlew --no-daemon clean build

--no-build-cache

To honour the JVM settings for this build a single-use Daemon process

will be forked. See
https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon
.

Daemon will be stopped at the end of the build

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :clean UP-TO-DATE
Task :plugins:example:clean UP-TO-DATE
Task :themes:common-theme:nodeSetup UP-TO-DATE
Task :themes:common-theme:npmSetup SKIPPED
Task :plugins:projectmgr:nodeSetup UP-TO-DATE
Task :plugins:projectmgr:npmSetup SKIPPED
Task :plugins:example:nodeSetup UP-TO-DATE
Task :plugins:example:npmSetup SKIPPED
Task :plugins:example:npmInstall NO-SOURCE
Task :plugins:example:assemble UP-TO-DATE
Task :plugins:example:check UP-TO-DATE
Task :plugins:example:build UP-TO-DATE
Task :themes:common-theme:npmInstall UP-TO-DATE
Task :themes:common-theme:assemble

Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0

[Jacques Le Roux]

Thanks Daniel for the quick answer :)

Maybe in the meantime we could simply "comment out" the ldap plugin, not sure 
how yet...

Jacques

Le 23/03/2024 à 11:56, Daniel Watford a écrit :

Hi Jacques,

Here's the cause of the failure for the docker-image github workflow:

#31 31.81 > Task :buildSrc:build
#31 60.80
#31 60.80 > Task :compileJava
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:43:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.AesCipherService;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:44:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.OperationMode;
#31 60.80   ^
#31 60.80
/builder/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityCrypto.java:45:
error: package org.apache.shiro.crypto does not exist
#31 60.80 import org.apache.shiro.crypto.PaddingScheme;

Whichever module provides org.apache.shiro.crypto is missing. But it's odd
that the gradle github workflow doesn't have a problem...

The difference between the two is that the gradle github workflow includes
the plugins, whereas the failing part of the docker-image workflow does not.

I confirmed the behaviour with some local builds:
- without plugins: Build fails
- with plugins: Build succeeds.

We can use './gradlew dependencies' to review the dependency tree.
Searching the tree for shiro we find:
- org.apache.shiro:shiro-core:1.3.2
- - > org.apereo.cas:cas-server-core-api-authentication:5.0.10
- - - > org.apereo.cas:cas-server-core-util:5.0.10
- - - - > org.apereo.cas:cas-server-support-ldap-core:5.0.10
- - - - - > project :plugins:ldap

So the missing dependency is getting brought in through the ldap plugin.

The above suggests we should consider removing the plugins from the gradle
github workflow, or at least consider creating two workflows, one with and
one without plugins.

Thanks,

Dan.





On Sat, 23 Mar 2024 at 10:28, Jacques Le Roux 
wrote:


Hi,

I'd appreciate confirmations about local build.
And, before reverting, if you have an idea don't hesitate :)

TIA

Jacques

Le 23/03/2024 à 11:23, Jacques Le Roux (Jira) a écrit :

  [

https://issues.apache.org/jira/browse/OFBIZ-12961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830052#comment-17830052
]

Jacques Le Roux commented on OFBIZ-12961:
-

There are currently some, for now, incomprehensible issues while

building.

It works locally on both Win7 and Ubuntu 20.04:


{noformat}
C:\projectsASF\Git\ofbiz-framework>gradlew --no-daemon clean build

--no-build-cache

To honour the JVM settings for this build a single-use Daemon process

will be forked. See
https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon
.

Daemon will be stopped at the end of the build

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :clean UP-TO-DATE
Task :plugins:example:clean UP-TO-DATE
Task :themes:common-theme:nodeSetup UP-TO-DATE
Task :themes:common-theme:npmSetup SKIPPED
Task :plugins:projectmgr:nodeSetup UP-TO-DATE
Task :plugins:projectmgr:npmSetup SKIPPED
Task :plugins:example:nodeSetup UP-TO-DATE
Task :plugins:example:npmSetup SKIPPED
Task :plugins:example:npmInstall NO-SOURCE
Task :plugins:example:assemble UP-TO-DATE
Task :plugins:example:check UP-TO-DATE
Task :plugins:example:build UP-TO-DATE
Task :themes:common-theme:npmInstall UP-TO-DATE
Task :themes:common-theme:assemble UP-TO-DATE
Task :themes:common-theme:check UP-TO-DATE
Task :themes:common-theme:build UP-TO-DATE
Task :plugins:projectmgr:npmInstall UP-TO-DATE
Task :plugins:projectmgr:assemble UP-TO-DATE
Task :plugins:projectmgr:check UP-TO-DATE
Task :plugins:projectmgr:build UP-TO-DATE
Task :compileJava

C:\projectsASF\Git\ofbiz-framework\framework\common\src\main\java\org\apache\ofbiz\common\authentication\AuthHelper.java:132:
warning: [removal] AccessController in java.security has been deprecated
and marked for removal

  retur

Re: [jira] [Commented] (OFBIZ-12961) Upgrade Apache Shiro from 1.13.0 to 2.0.0

[Jacques Le Roux]

Hi,

I'd appreciate confirmations about local build.
And, before reverting, if you have an idea don't hesitate :)

TIA

Jacques

Le 23/03/2024 à 11:23, Jacques Le Roux (Jira) a écrit :

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

Jacques Le Roux commented on OFBIZ-12961:
-

There are currently some, for now, incomprehensible issues while building.
It works locally on both Win7 and Ubuntu 20.04:


{noformat}
C:\projectsASF\Git\ofbiz-framework>gradlew --no-daemon clean build 
--no-build-cache
To honour the JVM settings for this build a single-use Daemon process will be 
forked. See 
https://docs.gradle.org/7.6/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :clean UP-TO-DATE
Task :plugins:example:clean UP-TO-DATE
Task :themes:common-theme:nodeSetup UP-TO-DATE
Task :themes:common-theme:npmSetup SKIPPED
Task :plugins:projectmgr:nodeSetup UP-TO-DATE
Task :plugins:projectmgr:npmSetup SKIPPED
Task :plugins:example:nodeSetup UP-TO-DATE
Task :plugins:example:npmSetup SKIPPED
Task :plugins:example:npmInstall NO-SOURCE
Task :plugins:example:assemble UP-TO-DATE
Task :plugins:example:check UP-TO-DATE
Task :plugins:example:build UP-TO-DATE
Task :themes:common-theme:npmInstall UP-TO-DATE
Task :themes:common-theme:assemble UP-TO-DATE
Task :themes:common-theme:check UP-TO-DATE
Task :themes:common-theme:build UP-TO-DATE
Task :plugins:projectmgr:npmInstall UP-TO-DATE
Task :plugins:projectmgr:assemble UP-TO-DATE
Task :plugins:projectmgr:check UP-TO-DATE
Task :plugins:projectmgr:build UP-TO-DATE
Task :compileJava

C:\projectsASF\Git\ofbiz-framework\framework\common\src\main\java\org\apache\ofbiz\common\authentication\AuthHelper.java:132:
 warning: [removal] AccessController in java.security has been deprecated and 
marked for removal
 return AccessController.doPrivileged(
^
C:\projectsASF\Git\ofbiz-framework\framework\testtools\src\main\java\org\apache\ofbiz\testtools\GroovyScriptTestCase.java:29:
 warning: [deprecation] GroovyTestCase in groovy.util has been deprecated
public class GroovyScriptTestCase extends GroovyTestCase {
   ^
2 warnings


Task :compileGroovy
Task :processResources
Task :classes
Task :jar
Task :startScripts
Task :distTar
Task :distZip
Task :assemble
Task :compileTestJava
Task :compileTestGroovy
Task :processTestResources
Task :testClasses

The Cobertura XML file [null] is not accessible; skipping this rule

Task :checkstyleMain
Task :checkstyleTest
Task :codenarcMain

The Cobertura XML file [null] is not accessible; skipping this rule

Task :codenarcTest
Task :test

OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader 
classes because bootstrap classpath has been appended


Task :check
Task :build

BUILD SUCCESSFUL in 4m 56s
33 actionable tasks: 15 executed, 18 up-to-date
C:\projectsASF\Git\ofbiz-framework>
{noformat}

{noformat}
jacques@jacques-VirtualBox:~/ofbiz-framework$ ./gradlew clean build 
--no-build-cache

Task :buildSrc:extractPluginRequests UP-TO-DATE
Task :buildSrc:generatePluginAdapters UP-TO-DATE
Task :buildSrc:compileJava UP-TO-DATE
Task :buildSrc:compileGroovy NO-SOURCE
Task :buildSrc:compileGroovyPlugins UP-TO-DATE
Task :buildSrc:pluginDescriptors UP-TO-DATE
Task :buildSrc:processResources UP-TO-DATE
Task :buildSrc:classes UP-TO-DATE
Task :buildSrc:jar UP-TO-DATE
Task :buildSrc:assemble UP-TO-DATE
Task :buildSrc:compileTestJava NO-SOURCE
Task :buildSrc:compileTestGroovy NO-SOURCE
Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
Task :buildSrc:processTestResources NO-SOURCE
Task :buildSrc:testClasses UP-TO-DATE
Task :buildSrc:test NO-SOURCE
Task :buildSrc:validatePlugins UP-TO-DATE
Task :buildSrc:check UP-TO-DATE
Task :buildSrc:build UP-TO-DATE
Task :plugins:example:cleanBuildReactApp UP-TO-DATE
Task :clean
Task :plugins:example:clean UP-TO-DATE
Task :plugins:projectmgr:clean UP-TO-DATE
Task :themes:common-theme:clean UP-TO-DATE
Task :compileJava

/home/j

[FYI] No relation longer between Git commits and Jira comments

[Jacques Le Roux]

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

Re: [apache/ofbiz-framework] Run failed: Scorecard supply-chain security - trunk (a9a3d13)

[Jacques Le Roux]

Happens: 
https://www.google.com/search?q=GitHub+Actions+has+encountered+an+internal+error

Le 18/03/2024 à 07:41, Jacques Le Roux a écrit :

[apache/ofbiz-framework] Run failed: Scorecard supply-chain security - trunk 
(a9a3d13)

GitHub


[apache/ofbiz-framework] Scorecard supply-chain security workflow run


  Scorecard supply-chain security: All jobs have failed

View workflow run 
<https://github.com/apache/ofbiz-framework/actions/runs/8322326563>


Scorecard analysis  

*Scorecard supply-chain security* / Scorecard analysis
Failed in 0 seconds

annotations for Scorecard supply-chain security / Scorecard analysis 1 
<https://github.com/apache/ofbiz-framework/actions/runs/8322326563>

—
You are receiving this because you are subscribed to this thread.
Manage your GitHub Actions notifications 
<https://github.com/settings/notifications>

GitHub, Inc. ・88 Colin P Kelly Jr Street ・San Francisco, CA 94107

Fwd: [jira] [Created] (OFBIZ-12934) Test next FreeMarker release

[Jacques Le Roux]

Hi Team,

I created this Jira in order to test next FreeMarker release.

Of course everyone is called to test

TIA

Jacques

 Message transféré 
Sujet : [jira] [Created] (OFBIZ-12934) Test next FreeMarker release
Date :  Sat, 9 Mar 2024 16:18:00 + (UTC)
De :Jacques Le Roux (Jira) 
Répondre à :dev@ofbiz.apache.org
Pour :  notificati...@ofbiz.apache.org



Jacques Le Roux created OFBIZ-12934:
---

Summary: Test next FreeMarker release Key: OFBIZ-12934
URL: https://issues.apache.org/jira/browse/OFBIZ-12934
Project: OFBiz
Issue Type: Task
Components: Freemarker
Affects Versions: Upcoming Branch
Reporter: Jacques Le Roux


{color:#FF8B00}This issue is a "reusable" one.{color}.

It's intended to test the next FreeMarker releases [as requested by the 
FreeMarker 
team|https://lists.apache.org/thread/t4c9z7wkcp3dbdokmnjd32fcptq8h9tz]

As it's not an as simple change, here I attach a patch as an exemple based on 
the test requested above:



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

Re: Apache Project Website Checks

[Jacques Le Roux]

Hi,

Forgot to say that this has been done as suggested below and can be easily seen 
on site

Jacques

Le 21/02/2024 à 09:56, Jacques Le Roux a écrit :

Le 19/02/2024 à 09:55, Jacques Le Roux a écrit :

Le 18/02/2024 à 20:05, Jacques Le Roux a écrit :

Le 13/02/2024 à 09:35, Jacques Le Roux a écrit :

Hi,

Now that it's soon 3 years that we did not Tweet anything, I think we should 
follow this advice

https://whimsy.apache.org/site/project/ofbiz

Jacques

Actually there is more than that: Linkedin and Facebook.
Both need you to sign in, hence to give up your personal data.

I believe it's not to Apache OFBiz to propose that.
So we should remove all social networks from the site.
Even if whimsy did not spot those 2.

Jacques

I did not speak about Youtube. I'd say it's still apart, you don't need yet to 
sign in to see things. And you can refuse cookies.
X is the same but it seems we no longer use it. Apart to refer to our blog... 
that we don't use anymore.

According to https://privacy.apache.org/faq/committers.html anyway Facebook and X are 
"forbidden".
We should also change Google Maps, YouTube and Vimeo a bit.

Finally, maybe we should have a look at https://github.com/heiseonline/shariff

Please share you thoughts

TIA


Hi,

Next week I'll apply necessary changes

Jacques

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

[Jacques Le Roux]

Pierre's help was successful: 
https://github.com/apache/ofbiz-framework/actions/runs/8122898106

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

Hi Daniel,

I don't know what to do with that. I locally tried "gradlew --console plain 
distTar"  and it works. But when I rebuild on GH it does not.

Jacques

Le 01/03/2024 à 21:24, GitBox a écrit :

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

Head commit for run:
7d3a069b36d60fa9b049be5cbdbda2c24af8c6a8 / Pierre Smits 

Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924) (#717)

* Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924)

Currently the libraries needed by ofbiz are defined in the build.gradle file. These should reside in a separate dependencies.gradle file that is 
referenced in the build.gradle file, like the common.gradle. As is common practice in other projects/solutions that work with dependencies on 
external libraries.


modified:

build.gradle: removed implementation, testImplementation and runtimeOnly 
library dependencies added:
dependencies.gradle, having the implementation, testImplementation and 
runtimeOnly library dependencies

* adding 'apply from' regarding dependencies

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

With regards,
GitHub Actions via GitBox

Re: Any ideas on how to make demo-site logs accessible and whether it is safe to do so?

[Jacques Le Roux]

Hi Dan,

About the logs in Webtools it's also limited to "OFBiz logs".
I mean you can't see the access_logs. They are sometime very useful too.

So yes I agree this would be something we could do.

Jacques

Le 29/02/2024 à 16:15, Daniel Watford a écrit :

Hello,

I was just checking the demo-stable logs - accessible on ofbiz-vm1 at
/home/ofbizdocker/demo-stable/logs - and found plenty of interesting stack
traces that would be good candidates for investigation.

Given that the demo sites use well known administrator passwords and should
not contain any sensitive information, how would the project's members feel
about making these logs automatically accessible to any interested parties?

If it is deemed appropriate to make the logs publicly accessible, we then
need to figure out how we could technically do so.

One approach I can think of is to add some Alias directives (
https://httpd.apache.org/docs/current/mod/mod_alias.html#alias) to the
Apache HTTP Server configuration to map relevant paths to the logs
directory of each demo site. For example, to the demo-trunk 
configuration, we could add:

Alias "/logs" "/home/ofbizdocker/demo-trunk/logs"

Similarly, to the demo-stable  configuration we would add:

Alias "/logs" "/home/ofbizdocker/demo-stable/logs"

We would then configure directory listings in Apache HTTP Server for those
log directory locations allowing access via a web browser.

There is some pre-existing functionality in Web Tools to access logs, but
it does require interaction through the OFBiz UI. The ability to retrieve
demo-site logs via an unauthenticated HTTP(S) get request might offer some
opportunities to automatically scan for a particular class of error and
might make it easier for ofbiz developers to check on the demo logs from
time to time.

Thanks,

Dan.

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

[Jacques Le Roux]

Hi Daniel,

I don't know what to do with that. I locally tried "gradlew --console plain 
distTar"  and it works. But when I rebuild on GH it does not.

Jacques

Le 01/03/2024 à 21:24, GitBox a écrit :

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

Head commit for run:
7d3a069b36d60fa9b049be5cbdbda2c24af8c6a8 / Pierre Smits 

Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924) (#717)

* Improved: Have library dependencies moved to a dependencies.gradle file 
(OFBIZ-10924)

Currently the libraries needed by ofbiz are defined in the build.gradle file. 
These should reside in a separate dependencies.gradle file that is referenced 
in the build.gradle file, like the common.gradle. As is common practice in 
other projects/solutions that work with dependencies on external libraries.

modified:

build.gradle: removed implementation, testImplementation and runtimeOnly 
library dependencies added:
dependencies.gradle, having the implementation, testImplementation and 
runtimeOnly library dependencies

* adding 'apply from' regarding dependencies

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

With regards,
GitHub Actions via GitBox

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Hi,

@committers: I don't remember if I already told you so: in case BB fails and it works locally, you can rebuild in BB by login with you complete a.o 
email address (eg: jler...@apache.org) and your ASF password


Jacques

Le 29/02/2024 à 20:09, build...@apache.org a écrit :

Build status: BUILD FAILED: failed './gradlew --no-daemon ...' (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/698
Blamelist: Daniel Watford 
Build Text: failed './gradlew --no-daemon ...' (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] c438302149830cd5f8153dab8e58e623915b21cf


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: 0

   generateReadmeFiles: 0

   Copy readme: 0

   generateOfbizDocumentation: 0

   Copy OfbizDocumentation: 0

   generateAllPluginsDocumentation: 0

   Copy AllPluginsDocumentation: 0

   javadoc: 0

   Copy javadoc: 0

   loadAll: 0

   testIntegration: 2

   clean things: 0


-- ASF Buildbot

CVE-2024-25065: Apache OFBiz: Path traversal allowing authentication bypass.

[Jacques Le Roux]

Severity: critical

Affected versions:

- Apache OFBiz before 18.12.12

Description:

Possible path traversal in Apache OFBiz allowing authentication bypass.
Users are recommended to upgrade to version 18.12.12, that fixes the issue.

Credit:

YunPeng - 郭 运鹏  (finder)

References:

https://ofbiz.apache.org/download.html
https://ofbiz.apache.org/security.html
https://ofbiz.apache.org/release-notes-18.12.12.html
https://issues.apache.org/jira/browse/OFBIZ-12887
https://ofbiz.apache.org/
https://www.cve.org/CVERecord?id=CVE-2024-25065

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

[Jacques Le Roux]

Thanks Michael,

I agree, I see this error message for long in Git Bash (WIn7). When you compare 
it's OK.
I thought got a real compare Issue in WIn7. I did not reproduce in Ubuntu 20.04. I also get there the checksum error message with the script where the 
values compare well.


Another issue is the Jacopo's signature that I reproduce everywhere. We ever 
got a message in the security ML about that.
Jacopo don't reproduce this issue. Maybe because he is the author? Do you 
reproduce the issue?

Jacques

Le 26/02/2024 à 12:27, Michael Brohl a écrit :

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: Apache Project Website Checks

[Jacques Le Roux]

Le 19/02/2024 à 09:55, Jacques Le Roux a écrit :

Le 18/02/2024 à 20:05, Jacques Le Roux a écrit :

Le 13/02/2024 à 09:35, Jacques Le Roux a écrit :

Hi,

Now that it's soon 3 years that we did not Tweet anything, I think we should 
follow this advice

https://whimsy.apache.org/site/project/ofbiz

Jacques

Actually there is more than that: Linkedin and Facebook.
Both need you to sign in, hence to give up your personal data.

I believe it's not to Apache OFBiz to propose that.
So we should remove all social networks from the site.
Even if whimsy did not spot those 2.

Jacques

I did not speak about Youtube. I'd say it's still apart, you don't need yet to 
sign in to see things. And you can refuse cookies.
X is the same but it seems we no longer use it. Apart to refer to our blog... 
that we don't use anymore.

According to https://privacy.apache.org/faq/committers.html anyway Facebook and X are 
"forbidden".
We should also change Google Maps, YouTube and Vimeo a bit.

Finally, maybe we should have a look at https://github.com/heiseonline/shariff

Please share you thoughts

TIA


Hi,

Next week I'll apply necessary changes

Jacques

Re: Request for Guidance on Upgrading Customized Apache OFBiz 16 to 18.12.12

[Jacques Le Roux]

Hi Vivek,

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

Please subscribe to the *user ML* for such questions and then use your email 
client.
See why here http://ofbiz.apache.org/mailing-lists.html.

You will get a better support, people can answer you on the ML.
The wider the audience the better the answers you might get.

Also it's more work for moderators who have to accept your messages as long as 
you have not subscribed.
I'll personally no longer accept them (other moderators still could).

TIA

This said, OFBiz is now mature. So with the transition from 16 to 18 you should 
not cross an impossible situation, notably with your data.
You can refer to 
https://cwiki.apache.org/confluence/display/OFBIZ/Revisions+Requiring+Data+Migration+-+upgrade+ofbiz
 about data migration if needed.
Of course this entails that you have not done (much) core (OOTB) code changes 
and has used plugins to put in your specific code.

HTH

Jacques

Le 21/02/2024 à 07:28, Vivek Kumar Prasad a écrit :


Dear Apache OFBiz Team,

Hope this email finds you well.

We have been using *Apache OFBiz* since version *16*, where we are
very satisfied with the features provided for small and medium businesses,
and have implemented several *customizations* tailored to our business
needs.

We are writing to seek *guidance* on the process of *upgrading* our
*customized* version from the Apache OFBiz version 16 to the latest
version. We want to ensure a smooth transition without losing the data,
custom configurations and features that we have implemented in our current
environment.

Thank you for your time and support. We look forward to hearing from you
soon.

Best regards,
[image:https://brrsoftwares.com/careers.html]


  [image: brr.softwares]   [image:
brrsoftwares]  [image:
BRRSoftwareSys]

*Vivek Kumar Prasad *

Sr. Software Engineer

#652, Amrutha Nilayam
,
B - Block,

Sriramnagar, Kondapur, Hyderabad-500081

  +91 9650427648

  https://brrsoftwares.com

Re: Apache Project Website Checks

[Jacques Le Roux]

Le 18/02/2024 à 20:05, Jacques Le Roux a écrit :

Le 13/02/2024 à 09:35, Jacques Le Roux a écrit :

Hi,

Now that it's soon 3 years that we did not Tweet anything, I think we should 
follow this advice

https://whimsy.apache.org/site/project/ofbiz

Jacques

Actually there is more than that: Linkedin and Facebook.
Both need you to sign in, hence to give up your personal data.

I believe it's not to Apache OFBiz to propose that.
So we should remove all social networks from the site.
Even if whimsy did not spot those 2.

Jacques

I did not speak about Youtube. I'd say it's still apart, you don't need yet to 
sign in to see things. And you can refuse cookies.
X is the same but it seems we no longer use it. Apart to refer to our blog... 
that we don't use anymore.

According to https://privacy.apache.org/faq/committers.html anyway Facebook and X are 
"forbidden".
We should also change Google Maps, YouTube and Vimeo a bit.

Finally, maybe we should have a look at https://github.com/heiseonline/shariff

Please share you thoughts

TIA

Re: Apache Project Website Checks

[Jacques Le Roux]

Le 13/02/2024 à 09:35, Jacques Le Roux a écrit :

Hi,

Now that it's soon 3 years that we did not Tweet anything, I think we should 
follow this advice

https://whimsy.apache.org/site/project/ofbiz

Jacques


Actually there is more than that: Linkedin and Facebook.
Both need you to sign in, hence to give up your personal data.

I believe it's not to Apache OFBiz to propose that.
So we should remove all social networks from the site.
Even if whimsy did not spot those 2.

Jacques

Re: PDF files with AsciiDoc

[Jacques Le Roux]

Hi Michael,

No need, my bad, I confused System requirements and Security sections.

A bit tired while cleaning obsolete documentation files in nightlies, I was very surprised that this commit change 
https://github.com/apache/ofbiz-framework/commit/11ae98b9983c2ff9808e680791da6380df43f7a4 was not visible in the "System requirements" section in the 
PDF but was visible in HTML5. Of course it was the wrong section :/


So no need to change anything. The only diff is that, in PDF, SVG files are not 
loaded despite https://issues.apache.org/jira/browse/INFRA-25480

It seems SVG images in PDF is not an easy task: 
https://docs.asciidoctor.org/pdf-converter/latest/image-paths-and-formats/

Anyway it's only about 2 badges images, the badges links being OK.

Better forget it, in my experience installing prawn-gmagick under Ubuntu 20.04 
is a pain!

Jacques

. Le 17/02/2024 à 18:19, michael.br...@ecomify.de a écrit :


Hi Jaques,

I‘ll check when I‘m back,
Regards,
Michael




Am 17.02.2024 um 06:55 schrieb Jacques Le Roux:

Hi,

I think we can't generate correct PDF files with AsciiDoc even on *nix OSs.

When you compare the contents of the AsciiDoc generated HTML and PDF files, 
it's clear that some parts are missing in PDF.
And I don't speak only about issues with some images files like SVG.

I suggest to stop generating them.

Opinions?

Jacques

PDF files with AsciiDoc

[Jacques Le Roux]

Hi,

I think we can't generate correct PDF files with AsciiDoc even on *nix OSs.

When you compare the contents of the AsciiDoc generated HTML and PDF files, 
it's clear that some parts are missing in PDF.
And I don't speak only about issues with some images files like SVG.

I suggest to stop generating them.

Opinions?

Jacques

Re: Do we want to upgrade node.js ?

[Jacques Le Roux]

Le 15/02/2024 à 10:08, Jacques Le Roux a écrit :

Hi,

After installing Scorecard as a GH actions (OFBIZ-12899), we got a suggestion 
to upgrade node.js from 16 to 20 version.

Do we want to do that?

TIA

Jacques


node.js 16 is EOL: https://github.com/nodejs/Release/#end-of-life-releases

Do we want to upgrade node.js ?

[Jacques Le Roux]

Hi,

After installing Scorecard as a GH actions (OFBIZ-12899), we got a suggestion 
to upgrade node.js from 16 to 20 version.

Do we want to do that?

TIA

Jacques

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

[Jacques Le Roux]

Hi,

And this is what get on Ubuntu 20.04, better for SHA512 (but not right it seems), weird for GPG. All that was working before, notably with last 
versions of apache-ofbiz-18.12.12.


jacques@jacques-VirtualBox:~/ofbiz-tools$ ./verify-ofbiz-release.sh -v 
apache-ofbiz-18.12.12  2>&1 | tee verify.log
Processing files for release: apache-ofbiz-18.12.12...
Verifying files...
sha check of file: apache-ofbiz-18.12.12.zip
Using sha file: apache-ofbiz-18.12.12.zip.sha512
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

sha sums mismatch!

GPG verification output
gpg: Signature made jeu. 08 févr. 2024 11:03:49 CET
gpg:    using RSA key 3545C5E31CC2D029B2CCAD067A580908847AF9E0
gpg: Can't check signature: No public key

Done processing files for release apache-ofbiz-18.12.12

"sha sums mismatch!" sounds weird to me as the two lines compare

Also I don't understand what's going on with GPG since I have both KEYS and 
apache-ofbiz-18.12.12.zip.asc

Do I miss something?

Jacques


Le 13/02/2024 à 14:09, Jacques Le Roux a écrit :

Since I'm on win7 using PowerShell:

   PS C:\projectsASF\Git\ofbiz-framework\tools> Get-Filehash 
apache-ofbiz-18.12.12.zip -a SHA512
   Algorithm Hash Path
   -  
   SHA512 
D6CC35969BD53A4C34E267A9221AE76AF416E2A0D442A2195B16227F2A431B2CBDC... 
C:\projectsASF\Git\ofbiz-framework\tools\apache-ofbiz-18.12.12.zip

   PS C:\projectsASF\Git\ofbiz-framework\tools> Get-Filehash 
apache-ofbiz-18.12.12.zip.sha512 -a SHA512
   Algorithm Hash Path
   -  
   SHA512 EB5E9CEAF1250D1D78BE0ADC9F729BCDBB90646EBFC7434F47EAEE73BCF5008...
C:\projectsASF\Git\ofbiz-framework\tools\apache-ofbiz-18.12.12.zip.sha512

Not sure why it's different from verify-ofbiz-release.sh result :/

Le 13/02/2024 à 13:51, Jacques Le Roux a écrit :

Hi Jacopo,

It seems there is at least a hash issue:

sha check of file: apache-ofbiz-18.12.12.zip
Using sha file: apache-ofbiz-18.12.12.zip.sha512
apache-ofbiz-18.12.12.zip: D6CC3596 9BD53A4C 34E267A9 221AE76A F416E2A0 D442A219 5B16227F 2A431B2C BDCB0E05 87C334C6 19DB5EE4 ED0D1F21 5EC90253 
88AB6487 DC5B71E7 5BA97A17
apache-ofbiz-18.12.12.zip: 67AA5932 53FFF35F 3AA89DC9 73951B33 8396F95D ECF26EBD 1DB58C66 50EE37E5 D053CD02 C9CB3FC4 B06D8CCC 747FAAA1 45B251CA 
5F95A606 B1CC6C1A A8CBC42C

sha sums mismatch!

Thanks

Jacques

Le 13/02/2024 à 09:34, Jacopo Cappellato a écrit :

This is the vote thread, third 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: [VOTE] [RELEASE] Apache OFBiz 18.12.12 - third attempt

[Jacques Le Roux]

Since I'm on win7 using PowerShell:

   PS C:\projectsASF\Git\ofbiz-framework\tools> Get-Filehash 
apache-ofbiz-18.12.12.zip -a SHA512
   Algorithm Hash Path
   -  
   SHA512 
D6CC35969BD53A4C34E267A9221AE76AF416E2A0D442A2195B16227F2A431B2CBDC... 
C:\projectsASF\Git\ofbiz-framework\tools\apache-ofbiz-18.12.12.zip

   PS C:\projectsASF\Git\ofbiz-framework\tools> Get-Filehash 
apache-ofbiz-18.12.12.zip.sha512 -a SHA512
   Algorithm Hash Path
   -  
   SHA512 EB5E9CEAF1250D1D78BE0ADC9F729BCDBB90646EBFC7434F47EAEE73BCF5008...
   C:\projectsASF\Git\ofbiz-framework\tools\apache-ofbiz-18.12.12.zip.sha512

Not sure why it's different from verify-ofbiz-release.sh result :/

Le 13/02/2024 à 13:51, Jacques Le Roux a écrit :

Hi Jacopo,

It seems there is at least a hash issue:

sha check of file: apache-ofbiz-18.12.12.zip
Using sha file: apache-ofbiz-18.12.12.zip.sha512
apache-ofbiz-18.12.12.zip: D6CC3596 9BD53A4C 34E267A9 221AE76A F416E2A0 D442A219 5B16227F 2A431B2C BDCB0E05 87C334C6 19DB5EE4 ED0D1F21 5EC90253 
88AB6487 DC5B71E7 5BA97A17
apache-ofbiz-18.12.12.zip: 67AA5932 53FFF35F 3AA89DC9 73951B33 8396F95D ECF26EBD 1DB58C66 50EE37E5 D053CD02 C9CB3FC4 B06D8CCC 747FAAA1 45B251CA 
5F95A606 B1CC6C1A A8CBC42C

sha sums mismatch!

Thanks

Jacques

Le 13/02/2024 à 09:34, Jacopo Cappellato a écrit :

This is the vote thread, third 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: [VOTE] [RELEASE] Apache OFBiz 18.12.12 - third attempt

[Jacques Le Roux]

Hi Jacopo,

It seems there is at least a hash issue:

sha check of file: apache-ofbiz-18.12.12.zip
Using sha file: apache-ofbiz-18.12.12.zip.sha512
apache-ofbiz-18.12.12.zip: D6CC3596 9BD53A4C 34E267A9 221AE76A F416E2A0 D442A219 5B16227F 2A431B2C BDCB0E05 87C334C6 19DB5EE4 ED0D1F21 5EC90253 
88AB6487 DC5B71E7 5BA97A17
apache-ofbiz-18.12.12.zip: 67AA5932 53FFF35F 3AA89DC9 73951B33 8396F95D ECF26EBD 1DB58C66 50EE37E5 D053CD02 C9CB3FC4 B06D8CCC 747FAAA1 45B251CA 
5F95A606 B1CC6C1A A8CBC42C

sha sums mismatch!

Thanks

Jacques

Le 13/02/2024 à 09:34, Jacopo Cappellato a écrit :

This is the vote thread, third 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

Apache Project Website Checks

[Jacques Le Roux]

Hi,

Now that it's soon 3 years that we did not Tweet anything, I think we should 
follow this advice

https://whimsy.apache.org/site/project/ofbiz

Jacques

Re: Add CHANGELOG.md file

[Jacques Le Roux]

Hi Guys,

Sorry to resurrect this thread.

With https://issues.apache.org/jira/browse/INFRA-25484 I have cleaned the 
useless and misleading files remaining at nigthlies.

I missed one at https://nightlies.apache.org/ofbiz/trunk/readme/html5/ : CHANGELOG.html 
<https://nightlies.apache.org/ofbiz/trunk/readme/html5/CHANGELOG.html>


Now, I wonder if we could not use this file somehow by linking https://ofbiz.apache.org/download.html#tabs-2 (though getting to "Release Notes" tab 
does not work this way)

Of course, that would be only for the stable version.

What do you think ? Does it worth it ?

Jacques

Le 17/01/2022 à 13:38, Jacques Le Roux a écrit :

Done

Le 14/01/2022 à 18:58, Jacques Le Roux a écrit :

Hi,

If nobody is against I'll remove this file Monday. Note that it will still be 
available in Git history/log...

Jacques

Le 09/01/2022 à 09:17, Jacques Le Roux a écrit :

But if we don't do anything about it, why keep this misleading file until we 
really start?

Le 21/12/2021 à 12:33, Jacques Le Roux a écrit :

Exactly...

Le 21/12/2021 à 12:30, Michael Brohl a écrit :

I think we'll need a process to fill it, the file alone will obviously not be 
sufficient.

Michael


Am 21.12.21 um 11:46 schrieb Jacques Le Roux:

Hi All,

OK we have a CHANGELOG file now for 10 months, but nothing in it, so?

Jacques

Le 19/06/2020 à 12:19, Deepak Dixit a écrit :

Here is the link for task
https://issues.apache.org/jira/browse/OFBIZ-11839

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


On Thu, Jun 18, 2020 at 10:22 AM Swapnil M Mane
wrote:


+1

- Best regards,
Swapnil M Mane,
ofbiz.apache.org



On Wed, Jun 17, 2020 at 11:23 AM Deepak Dixit  wrote:


Hi Dev,

As we have already moved to git for the version control system, I propose
to add a changelog file to maintain the changelogs[1].
What is a changelog?

A changelog is a file which contains a curated, chronologically ordered
list of notable changes for each version of a project.
Why keep a changelog?

To make it easier for users and contributors to see precisely what

notable

changes have been made between each release (or version) of the project.
Who needs a changelog?

People do. Whether consumers or developers, the end users of software are
human beings who care about what's in the software. When the software
changes, people want to know why and how.

We can have our own process to generate changelog, It may be either

manual

entries, or some tool or using git log. We can discuss this

independently.

https://keepachangelog.com/en/1.0.0/

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

Recommending JDK 11 for 18.12

[Jacques Le Roux]

Hi,

In several msg for "[VOTE] [RELEASE] Apache OFBiz 18.12.12 - second attempt", I 
see that JDK 11 is used.
I still use JDK 8 but I wonder if we should not recommend JDK 11 in the README ?

Jacques

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

[Jacques Le Roux]

Thanks Jacopo,

All works as expected Win7

+1

Jacques

Le 08/02/2024 à 14:29, Jacopo Cappellato a écrit :

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!

[Jacques Le Roux]

Hi,

With https://ci2.apache.org/#/builders/46/builds/647 I tried to remove a file 
from nightlies but that does not work anyway:
<>
So seems you can copy but not remove a file.

Anyway, I have put back the previous ofbiz.py version (BB config) and rebuilt 
again.
I have asked Infra to remove this deprecated file: 
https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html

Jacques

Le 05/02/2024 à 15:18, Jacques Le Roux a écrit :

I pushed a fix but BB is still blocked

Le 05/02/2024 à 15:02, Michael Brohl a écrit :

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: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Hi Michael,

Don't worry, this is me mucking around with BB. It's OK now.

Jacques

Le 06/02/2024 à 17:13, 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/647
Blamelist: Michael Brohl 
Build Text: failed Codenarc copied. (failure)
Status Detected: failed build
Build Source Stamp: [branch trunk] c156ab44141ff166f6620e754ac01df00d5e8a1f


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: [GH] (ofbiz-framework): Workflow run "Java CI with Gradle" failed!

[Jacques Le Roux]

I pushed a fix but BB is still blocked

Le 05/02/2024 à 15:02, Michael Brohl a écrit :

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!

[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: Demos log in Docker

[Jacques Le Roux]

Thanks Daniel!

Le 05/02/2024 à 09:07, Daniel Watford a écrit :

Hi Jacques - https://issues.apache.org/jira/browse/OFBIZ-12889 created for
this

On Fri, 2 Feb 2024 at 10:51, Jacques Le Roux 
wrote:


Hi Daniel,

I know how to use docker compose logs --tail="1000" on demos

But how to see logs contents like
access_log
ofbiz.log
error.log
etc.

in Docker ?

TIA

Jacques

Re: Demos log in Docker

[Jacques Le Roux]

Hi Daniel,

Any idea?

TIA

Jacques

Le 02/02/2024 à 11:50, Jacques Le Roux a écrit :

Hi Daniel,

I know how to use docker compose logs --tail="1000" on demos

But how to see logs contents like
access_log
ofbiz.log
error.log
etc.

in Docker ?

TIA

Jacques

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

Hi Michael,

I forgot this email and only reapply the initial one. I have just completed the 
task. The PR can be closed.

TIA

Jacques

Le 04/02/2024 à 11:54, Michael Brohl a écrit :

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

[Jacques Le Roux]

Cool, thanks!

Le 04/02/2024 à 11:26, Michael Brohl a écrit :

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

[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

[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: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

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

Demos log in Docker

[Jacques Le Roux]

Hi Daniel,

I know how to use docker compose logs --tail="1000" on demos

But how to see logs contents like
access_log
ofbiz.log
error.log
etc.

in Docker ?

TIA

Jacques

Re: [VOTE] Release Apache OFBiz 18.12.12

[Jacques Le Roux]

+1

All works as expected on Win7

Jacques

Le 13/01/2024 à 20:17, Jacopo Cappellato a écrit :

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: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Le 05/01/2024 à 09:25, Daniel Watford a écrit :

git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git  plugins


Hi Daniel,

It needs also --single-branch:
    git clone --depth 1 --single-branch --branch $branch 
https://github.com/apache/ofbiz-plugins.git plugins

It's really fast and sparse

Thanks for the tip

Jacques

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Thanks Daniel,

I'll try that, did not know for the --$branch option

Jacques

Le 05/01/2024 à 09:25, Daniel Watford a écrit :

Hi Jacques,

I note your point about avoiding reply-all when replying to mailing lists.
Gmail seems to have reply-all as the default option - I'll try to avoid it
in future.

When you tried the "--depth=1" option to git clone, did you also include
the "--branch $branch" command line option?

The "--branch $branch" option will retrieve the branch that you are
interested in, avoiding the need for the subsequent. Presumably git clone
will default to the trunk branch if not other branch is specified, and
depth=1 will cause git clone to only retrieve enough data to provide a
single commit of that branch.

Please give the following a try to see if it will download the desired
branch, using the minimum possible data retrieval, in one step:

git clone --depth 1 --branch $branch
https://github.com/apache/ofbiz-plugins.git plugins



On Fri, 5 Jan 2024 at 07:21, Jacques Le Roux 
wrote:


Hi Daniel,

I understand that it easier to be alerted when you receive an email
directly to your email address (inbox).
For Thunderbird msg filtering convenience, and in general for other
reasons*, I prefer to answer only to the ML.
   This is true also for @Eugen, please don't send email directly to me,
TIA to both of you :)

* If you are interested about a previous (long and argumented) discussion
here you go: https://s.apache.org/556a0

This said, I tried with depth=1, and there is an issue. It does not switch
to the current branch. You get, eg "fatal: invalid reference: release22.01"
It works well when using --filter=tree:0 and you download only 6Mb vs 7Mb
with depth=1.

BTW "weirdly" (I have no idea about that) we don't get the depth=1 issue
when using sparse-checkout as in pullPluginSource.
Still I'll rather use --filter=tree:0 since it download a bit less of
data. So I'll push that for both scripts.

I must say that I did not completely read nor watched the article**, only
the the "Quick Summary"
I also only considered the download aspect. I think it's OK. If you have
more indications please tell us, TIA

**
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

Thanks for initiating this thread (to Eugen in Jira too)

Jacques

Le 04/01/2024 à 19:19, Jacques Le Roux a écrit :

Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll

change that tmrw :)

Le 04/01/2024 à 18:57, Daniel Watford a écrit :

Hi Jacques,

Using depth=1 means you only download the data you actually need,

rather than retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around

7MB of data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not

introduce too much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux <

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

 Hi Daniel,

 Reviews are always appreciated :)

 Inline...

 Le 04/01/2024 à 09:23, Daniel Watford a écrit :

 Hi Jacques,

 Sorry for not reviewing earlier, but for the

pullAllPluginsSource.sh you might consider simplifying a little with:

 # Whatever, create anew if [ -d"plugins" ]
  then rm -rf plugins
 fi # Get the branch used by the framework branch=$(git branch

--show-current) git clone --depth1 --branch$branch

https://github.com/apache/ofbiz-plugins.git  plugins

 # remove .git, in this case it's big useless information rm -rf

plugins/.git

 The above avoids creating the temp.txt file to detect the current

branch, and avoids changing directories.

 I'll commit that after your answer below about  depth=1



 FYI, pushd and popd are useful alternatives to cd in scripts -

https://en.wikipedia.org/wiki/Pushd_and_popd

 Thanks for the info, did not know it existed in cmd.exe.



 The git clone command has been altered to select the branch to

clone, and the depth=1 command line argument reduces the size of the clone
to

 the minimum needed for that single branch.

 I'm not sure it's useful because anyway I remove .git, don't you

think so?

 TIA

 Jacques


 Dan.

 On Wed, 3 Jan 2024 at 18:11, Eugen Stan 

wrote:

 Hi Jacques,

 I missed this thread for some reason (was collapsed in TB) and

only saw

 it now.

 I read the thread.
 Glad to see progress on fixing the SVN issue.

 Also inline:

 La 24.12.2023 13:05, Jacques Le Roux a scris:
 > Hi Eugen,
 >
 > I tend to agree with your vision that sounds quite

promising. I'm sorry

 > I got no time to review your PR yet. I hope to do so during

next year...

 It's good that it gets some attention.
 Even if the PR does not get merged as is b

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Le 05/01/2024 à 08:20, Jacques Le Roux a écrit :

* If you are interested about a previous (long and argumented) discussion here 
you go: https://s.apache.org/556a0


TL;DR, in that email are my principal reasons: 
https://lists.apache.org/thread/o73vxotkd2qgvmctoz6wxn1y05zdb1c5

TIA

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel,

I understand that it easier to be alerted when you receive an email directly to 
your email address (inbox).
For Thunderbird msg filtering convenience, and in general for other reasons*, I 
prefer to answer only to the ML.
 This is true also for @Eugen, please don't send email directly to me, TIA to 
both of you :)

* If you are interested about a previous (long and argumented) discussion here 
you go: https://s.apache.org/556a0

This said, I tried with depth=1, and there is an issue. It does not switch to the current 
branch. You get, eg "fatal: invalid reference: release22.01"
It works well when using --filter=tree:0 and you download only 6Mb vs 7Mb with 
depth=1.

BTW "weirdly" (I have no idea about that) we don't get the depth=1 issue when 
using sparse-checkout as in pullPluginSource.
Still I'll rather use --filter=tree:0 since it download a bit less of data. So 
I'll push that for both scripts.

I must say that I did not completely read nor watched the article**, only the the 
"Quick Summary"
I also only considered the download aspect. I think it's OK. If you have more 
indications please tell us, TIA

** 
https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/

Thanks for initiating this thread (to Eugen in Jira too)

Jacques

Le 04/01/2024 à 19:19, Jacques Le Roux a écrit :

Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll change 
that tmrw :)

Le 04/01/2024 à 18:57, Daniel Watford a écrit :

Hi Jacques,

Using depth=1 means you only download the data you actually need, rather than 
retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around 7MB of 
data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not introduce too 
much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux  
wrote:

    Hi Daniel,

    Reviews are always appreciated :)

    Inline...

    Le 04/01/2024 à 09:23, Daniel Watford a écrit :

    Hi Jacques,

    Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you 
might consider simplifying a little with:

    # Whatever, create anew if [ -d"plugins" ]
 then rm -rf plugins
    fi # Get the branch used by the framework branch=$(git branch --show-current) git clone --depth1 --branch$branch 
https://github.com/apache/ofbiz-plugins.git  plugins


    # remove .git, in this case it's big useless information rm -rf plugins/.git

    The above avoids creating the temp.txt file to detect the current branch, 
and avoids changing directories.


    I'll commit that after your answer below about  depth=1




    FYI, pushd and popd are useful alternatives to cd in scripts - 
https://en.wikipedia.org/wiki/Pushd_and_popd


    Thanks for the info, did not know it existed in cmd.exe.




    The git clone command has been altered to select the branch to clone, and 
the depth=1 command line argument reduces the size of the clone to
    the minimum needed for that single branch.


    I'm not sure it's useful because anyway I remove .git, don't you think so?

    TIA

    Jacques



    Dan.

    On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

    Hi Jacques,

    I missed this thread for some reason (was collapsed in TB) and only saw
    it now.

    I read the thread.
    Glad to see progress on fixing the SVN issue.

    Also inline:

    La 24.12.2023 13:05, Jacques Le Roux a scris:
    > Hi Eugen,
    >
    > I tend to agree with your vision that sounds quite promising. I'm 
sorry
    > I got no time to review your PR yet. I hope to do so during next 
year...

    It's good that it gets some attention.
    Even if the PR does not get merged as is but is used as example for the
    idea the PR is meant for.

    > Of course, this architecture will need to be discussed more and
    > especially will not be part of the next release branch (24.01 ? 18.12
    > becoming really old).

    That is ok with me since I plan to use trunk anyway.
    So I guess the sooner we have OFBiz 24.01 the better :D .
    Are there otehr blockers for 24.01 besides the SVN issue?

    >
    > This said I was reading
    > 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
    > and stumbled upon
    > 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
    >
    > Obviously some parts are obsolete since we rely now on Docker for 
demos.
    > Could you please review and possibly amend?

    Is this for me or for Daniel?
    I assume it's for Daniel (as I read in your next emails).

    > Last but not least, I guess we will need very soon to change something
    > in Docker config fo

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Yes you are right Daniel, I remember having seen 7.62 Mb for trunk. I'll change 
that tmrw :)

Le 04/01/2024 à 18:57, Daniel Watford a écrit :

Hi Jacques,

Using depth=1 means you only download the data you actually need, rather than 
retrieving lots of data that is then immediately deleted.

I can't check right now, but from memory I think with depth=1, around 7MB of 
data was retrieved, compared to around 160MB without depth=1.

We should try and only retrieve needed data if doing so does not introduce too 
much complexity.

Thanks,

Dan.

On Thu, 4 Jan 2024 at 09:43, Jacques Le Roux  
wrote:

Hi Daniel,

Reviews are always appreciated :)

Inline...

Le 04/01/2024 à 09:23, Daniel Watford a écrit :

Hi Jacques,

Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you 
might consider simplifying a little with:

# Whatever, create anew if [ -d"plugins" ]
 then rm -rf plugins
fi # Get the branch used by the framework branch=$(git branch 
--show-current) git clone --depth1 --branch$branch 
https://github.com/apache/ofbiz-plugins.git  plugins

# remove .git, in this case it's big useless information rm -rf plugins/.git

The above avoids creating the temp.txt file to detect the current branch, 
and avoids changing directories.


I'll commit that after your answer below about  depth=1




FYI, pushd and popd are useful alternatives to cd in scripts - 
https://en.wikipedia.org/wiki/Pushd_and_popd


Thanks for the info, did not know it existed in cmd.exe.




The git clone command has been altered to select the branch to clone, and 
the depth=1 command line argument reduces the size of the clone to
the minimum needed for that single branch.


I'm not sure it's useful because anyway I remove .git, don't you think so?

TIA

Jacques



Dan.

On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw
it now.

I read the thread.
Glad to see progress on fixing the SVN issue.

Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:
> Hi Eugen,
>
> I tend to agree with your vision that sounds quite promising. I'm 
sorry
> I got no time to review your PR yet. I hope to do so during next 
year...

It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the
idea the PR is meant for.

> Of course, this architecture will need to be discussed more and
> especially will not be part of the next release branch (24.01 ? 18.12
> becoming really old).

That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?

>
> This said I was reading
> 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> and stumbled upon
> 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
>
> Obviously some parts are obsolete since we rely now on Docker for 
demos.
> Could you please review and possibly amend?

Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

> Last but not least, I guess we will need very soon to change something
> in Docker config for demos ; since pullAllPluginsSource relies on soon
> not usable SvnCheckout plugin?
>
> TIA
>
> Jacques
>
> Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
>> Hi Jacques,
>>
>> Regarding the plugin workflow, the PR that I posted can offer
>> alternative ways to develop and consume plugins / components.
>> This would make plugin development by pulling sources in ofbiz
>> optional / obsolete even (a choice).
>>
>> If we move to have libraries that are published as jar files, then it
>> would be possible to develop plugins by depending on the specific
>> OFBiz bits.
>> It would also be possible to publish plugins / components as regular
>> java jars and consume them the same way.
>> So, in the future a custom OFBiz build could look something like 
this:
>>
>> build.gradle
>>
>> dependencies {
>>   implementation 'org.apache.ofbiz:entity-engine:24.0'
>>   implementation 'org.apache.ofbiz:service:24.0'
>>   implementation 'org.apache.ofbiz:accounting:24.0'
>>   implementation 'com.example:my-plugi

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen,

Inline too...

Le 03/01/2024 à 19:10, Eugen Stan a écrit :

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw it now.

I read the thread.
Glad to see progress on fixing the SVN issue.


I think it's eventually done, with maybe some syntax improvements




Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:

Hi Eugen,

I tend to agree with your vision that sounds quite promising. I'm sorry I got 
no time to review your PR yet. I hope to do so during next year...


It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the idea 
the PR is meant for.

Of course, this architecture will need to be discussed more and especially will not be part of the next release branch (24.01 ? 18.12 becoming 
really old).


That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?


There is OFBIZ-12726 <https://issues.apache.org/jira/browse/OFBIZ-12726?src=confmacro> that I set as a blocker. I think we could continue with the 
workaround for now, the community to decide... 24.01 or such is now pressing...







This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md

Obviously some parts are obsolete since we rely now on Docker for demos. Could 
you please review and possibly amend?


Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not 
usable SvnCheckout plugin?


Yes indeed I confused, I finally handled Docker with the task 
https://issues.apache.org/jira/browse/OFBIZ-12876
For the READMEs it's more on my side than Daniel's. I'll clean the whole thing 
with https://issues.apache.org/jira/browse/OFBIZ-12863
For demos, we have now 
https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker

Jacques




TIA

Jacques

Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer alternative ways 
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional / 
obsolete even (a choice).

If we move to have libraries that are published as jar files, then it would be 
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars 
and consume them the same way.
So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for > 
that... WIP...
>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be >> 
usable after January 8, 2024.
>>
>> So we need a replacement and it's clearly suggested by GitHub in the >> link 
below
>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel,

Reviews are always appreciated :)

Inline...

Le 04/01/2024 à 09:23, Daniel Watford a écrit :

Hi Jacques,

Sorry for not reviewing earlier, but for the pullAllPluginsSource.sh you might 
consider simplifying a little with:

# Whatever, create anew if [ -d"plugins" ]
 then rm -rf plugins
fi # Get the branch used by the framework branch=$(git branch --show-current) 
git clone --depth1 --branch$branch https://github.com/apache/ofbiz-plugins.git  
plugins

# remove .git, in this case it's big useless information rm -rf plugins/.git

The above avoids creating the temp.txt file to detect the current branch, and 
avoids changing directories.


I'll commit that after your answer below about  depth=1




FYI, pushd and popd are useful alternatives to cd in scripts - 
https://en.wikipedia.org/wiki/Pushd_and_popd


Thanks for the info, did not know it existed in cmd.exe.




The git clone command has been altered to select the branch to clone, and the depth=1 command line argument reduces the size of the clone to the 
minimum needed for that single branch.


I'm not sure it's useful because anyway I remove .git, don't you think so?

TIA

Jacques



Dan.

On Wed, 3 Jan 2024 at 18:11, Eugen Stan  wrote:

Hi Jacques,

I missed this thread for some reason (was collapsed in TB) and only saw
it now.

I read the thread.
Glad to see progress on fixing the SVN issue.

Also inline:

La 24.12.2023 13:05, Jacques Le Roux a scris:
> Hi Eugen,
>
> I tend to agree with your vision that sounds quite promising. I'm sorry
> I got no time to review your PR yet. I hope to do so during next year...

It's good that it gets some attention.
Even if the PR does not get merged as is but is used as example for the
idea the PR is meant for.

> Of course, this architecture will need to be discussed more and
> especially will not be part of the next release branch (24.01 ? 18.12
> becoming really old).

That is ok with me since I plan to use trunk anyway.
So I guess the sooner we have OFBiz 24.01 the better :D .
Are there otehr blockers for 24.01 besides the SVN issue?

>
> This said I was reading
> 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
> and stumbled upon
> https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md
>
> Obviously some parts are obsolete since we rely now on Docker for demos.
> Could you please review and possibly amend?

Is this for me or for Daniel?
I assume it's for Daniel (as I read in your next emails).

> Last but not least, I guess we will need very soon to change something
> in Docker config for demos ; since pullAllPluginsSource relies on soon
> not usable SvnCheckout plugin?
>
> TIA
>
> Jacques
>
> Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :
>> Hi Jacques,
>>
>> Regarding the plugin workflow, the PR that I posted can offer
>> alternative ways to develop and consume plugins / components.
>> This would make plugin development by pulling sources in ofbiz
>> optional / obsolete even (a choice).
>>
>> If we move to have libraries that are published as jar files, then it
>> would be possible to develop plugins by depending on the specific
>> OFBiz bits.
>> It would also be possible to publish plugins / components as regular
>> java jars and consume them the same way.
>> So, in the future a custom OFBiz build could look something like this:
>>
>> build.gradle
>>
>> dependencies {
>>   implementation 'org.apache.ofbiz:entity-engine:24.0'
>>   implementation 'org.apache.ofbiz:service:24.0'
>>   implementation 'org.apache.ofbiz:accounting:24.0'
>>   implementation 'com.example:my-plugin:1.2.3'
>> }
>>
>>
    >>
>>
>> On 23.12.2023 17:06, Jacques Le Roux 
>> wrote:
>>> It's ready for review before pushing and testing with GH and BB
>>>
>>> TIA
>>>
>>> Jacques
    >>>
>>> Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
>>> > Hi,
>>> >
>>> > I have created https://issues.apache.org/jira/browse/OFBIZ-12868
>>> for > that... WIP...
>>> >
>>> > HTH
>>> >
>>> > Jacques
>>> >
>>> > Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>>> >> Hi,
>>> >>
>>> >> As you may have noticed*, the SvnCheckout Gradle plugin will not
>>> be >> usable after January 8, 2024.
>>> >>
>>> >> So we need a replacement and it's clearly suggested by GitHub in
>>> the >> link below
>>> >>
>>> >> Jacques
>>> >>
>>> >> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz
>>>
>>

-- 
Eugen Stan


+40770 941 271  / https://www.netdava.com



--
Daniel Watford

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel, All,

It's now used in necessary places: GH actions (Build, Docker and so Demos) and BB. So far all works as expected for all branches (18.12 being really a 
weight)


Note: with
https://github.com/apache/ofbiz-framework/commit/c7f606fe98621b8233d70e1c1f9793c525117c4c
I have updated AccountingDemoData.xml. Last time, in 2013, I put 10 years ahead.
This time, lazy, I put only 1 year, so it will need to be updated each new year 
(not needed in R18)...

There is still a minor issue with pullAllPluginsSource.sh when the releases 
branches don't exist. I'll fix it soon...

Jacques

Le 31/12/2023 à 11:41, Jacques Le Roux a écrit :

Hi Daniel,

There is a huge performance difference in favour of scripts and I found 
difficult to use the scripts from Gradle.
As you may have seen, I already crossed an issue (access denied) with BB I 
reported to Infra with https://issues.apache.org/jira/browse/INFRA-25327

This said it may certainly be possible to call the scripts from Gradle. I have 
tried that w/o success so far:

--

task pullPluginSource(group: ofbizPlugin, description: 'Download and install a 
plugin from source control') {

task pullPluginFromGit() {

if (project.hasProperty('pluginId')) {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullPluginSource.bat', "${pluginId}" }

} else {

exec { commandLine './pullPluginSource.sh', "${pluginId}" }

}

}

}

dependsOn pullPluginFromGit

doLast {

gradlewSubprocess(['installPlugin', "-PpluginId=${pluginId}"])

}

}

task pullAllPluginsSource(group: ofbizPlugin,

description: 'Download and install all plugins from source control. Warning! 
deletes existing plugins') {

task pullAllPluginsFromGit() {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullAllPluginsSource.bat' }

} else {

exec { commandLine './pullAllPluginsSource.sh' }

}

}

dependsOn pullAllPluginsFromGit

task installAllPlugins {

subdirs(file("${pluginsDir}"))

.filter(this.isComponentEnabled)

.filter { taskExistsInproject(":plugins:${it.name}", 'install') }

.forEach({ plugin ->

dependsOn ":plugins:${plugin.name}:install"

doLast { println "installed plugin ${plugin.name}" }

})

}

doLast {

gradlewSubprocess(['installAllPlugins'])

}

}

--

The scripts are at https://issues.apache.org/jira/browse/OFBIZ-12868

I know that "dependsOn" is no longer recommended with recent versions of 
Gradle, maybe the reason.

We have still a week before it will be a real blocker.

Jacques

Le 31/12/2023 à 11:13, Daniel Watford a écrit :

Hi Jacques,

Please could you confirm that the project's intention is to remove
the pullAllPluginsSource gradle task, rather than replace the components of
that task that fetch the source via SVN with something similar that fetches
via Git?

The reason for asking is that you mentioned in a comment on
https://issues.apache.org/jira/browse/OFBIZ-12868  that we might still use
the gradle tasks:


"To minimise the change, we could decide to still use the scripts but
called from Gradle... I have not yes tested the performance differences..."


If the intention is to keep the gradle tasks related to retrieving plugin
sources, but have those tasks call external scripts, then we should close
https://issues.apache.org/jira/browse/OFBIZ-12876  and have the docker image
builds continue to leverage gradle.

Thanks,

Dan.

On Tue, 26 Dec 2023 at 09:49, Jacques Le Roux
wrote:


Hi,

Though I believe we should get rid of the Gradle pullPluginSource and
pullAllPluginsSource tasks, this morning I tried to implement them using
the OS
scripts for pullPluginSource and pullAllPluginsSource w/o success.

If someone is interested I can put the diff at OFBIZ-12868

Juste let me know...

Jacques

Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :

Hi,

OK, we need more effort here because GH and BB will break at January 8,

2024 and we need to test the changes before... In other words we have at

most 2 weeks available...

I have one question. It seems to me that the Gradle "installPlugin"

task, called by the pullPluginSource and pullAllPluginsSource tasks, is not

implement in any OOTB plugin.

I ask this question because, if it eventually unused, it's quite easier

and especially efficient/faster to use simple OS scripts than Gradle tasks

for pullPluginSource and pullAllPluginsSource

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have createdhttps://issues.apache.org/jira/browse/OFBIZ-12868 for

that... WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin wi

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Daniel,

There is a huge performance difference in favour of scripts and I found 
difficult to use the scripts from Gradle.
As you may have seen, I already crossed an issue (access denied) with BB I 
reported to Infra with https://issues.apache.org/jira/browse/INFRA-25327

This said it may certainly be possible to call the scripts from Gradle. I have 
tried that w/o success so far:

--

task pullPluginSource(group: ofbizPlugin, description: 'Download and install a 
plugin from source control') {

task pullPluginFromGit() {

if (project.hasProperty('pluginId')) {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullPluginSource.bat', "${pluginId}" }

} else {

exec { commandLine './pullPluginSource.sh', "${pluginId}" }

}

}

}

dependsOn pullPluginFromGit

doLast {

gradlewSubprocess(['installPlugin', "-PpluginId=${pluginId}"])

}

}

task pullAllPluginsSource(group: ofbizPlugin,

description: 'Download and install all plugins from source control. Warning! 
deletes existing plugins') {

task pullAllPluginsFromGit() {

if (os.contains('windows')) {

exec { commandLine 'cmd', '/c', 'pullAllPluginsSource.bat' }

} else {

exec { commandLine './pullAllPluginsSource.sh' }

}

}

dependsOn pullAllPluginsFromGit

task installAllPlugins {

subdirs(file("${pluginsDir}"))

.filter(this.isComponentEnabled)

.filter { taskExistsInproject(":plugins:${it.name}", 'install') }

.forEach({ plugin ->

dependsOn ":plugins:${plugin.name}:install"

doLast { println "installed plugin ${plugin.name}" }

})

}

doLast {

gradlewSubprocess(['installAllPlugins'])

}

}

--

The scripts are at https://issues.apache.org/jira/browse/OFBIZ-12868

I know that "dependsOn" is no longer recommended with recent versions of 
Gradle, maybe the reason.

We have still a week before it will be a real blocker.

Jacques

Le 31/12/2023 à 11:13, Daniel Watford a écrit :

Hi Jacques,

Please could you confirm that the project's intention is to remove
the pullAllPluginsSource gradle task, rather than replace the components of
that task that fetch the source via SVN with something similar that fetches
via Git?

The reason for asking is that you mentioned in a comment on
https://issues.apache.org/jira/browse/OFBIZ-12868  that we might still use
the gradle tasks:


"To minimise the change, we could decide to still use the scripts but
called from Gradle... I have not yes tested the performance differences..."


If the intention is to keep the gradle tasks related to retrieving plugin
sources, but have those tasks call external scripts, then we should close
https://issues.apache.org/jira/browse/OFBIZ-12876  and have the docker image
builds continue to leverage gradle.

Thanks,

Dan.

On Tue, 26 Dec 2023 at 09:49, Jacques Le Roux
wrote:


Hi,

Though I believe we should get rid of the Gradle pullPluginSource and
pullAllPluginsSource tasks, this morning I tried to implement them using
the OS
scripts for pullPluginSource and pullAllPluginsSource w/o success.

If someone is interested I can put the diff at OFBIZ-12868

Juste let me know...

Jacques

Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :

Hi,

OK, we need more effort here because GH and BB will break at January 8,

2024 and we need to test the changes before... In other words we have at

most 2 weeks available...

I have one question. It seems to me that the Gradle "installPlugin"

task, called by the pullPluginSource and pullAllPluginsSource tasks, is not

implement in any OOTB plugin.

I ask this question because, if it eventually unused, it's quite easier

and especially efficient/faster to use simple OS scripts than Gradle tasks

for pullPluginSource and pullAllPluginsSource

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have createdhttps://issues.apache.org/jira/browse/OFBIZ-12868  for

that... WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be

usable after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the

link below

Jacques

*https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: Buildbot failure in on ofbizTrunkFrameworkPlugins

[Jacques Le Roux]

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

Jacques

Le 31/12/2023 à 10:21, build...@apache.org a écrit :

Build status: BUILD FAILED: failed 'bash -c ...' (failure)
Worker used: bb_worker4_ubuntu
URL: https://ci2.apache.org/#builders/46/builds/614
Blamelist: Jacques Le Roux 
Build Text: failed 'bash -c ...' (failure)
Status Detected: new failure
Build Source Stamp: [branch trunk] fd52ae3fe0bcc5edebff6f3fba939475f83c4a41


Steps:

   worker_preparation: 0

   git: 0

   pullAllPluginsSource: 2

   clean things: 0


-- ASF Buildbot

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi,

Though I believe we should get rid of the Gradle pullPluginSource and pullAllPluginsSource tasks, this morning I tried to implement them using the OS 
scripts for pullPluginSource and pullAllPluginsSource w/o success.


If someone is interested I can put the diff at OFBIZ-12868

Juste let me know...

Jacques

Le 23/12/2023 à 12:13, Jacques Le Roux a écrit :

Hi,

OK, we need more effort here because GH and BB will break at January 8, 2024 and we need to test the changes before... In other words we have at 
most 2 weeks available...


I have one question. It seems to me that the Gradle "installPlugin" task, called by the pullPluginSource and pullAllPluginsSource tasks, is not 
implement in any OOTB plugin.


I ask this question because, if it eventually unused, it's quite easier and especially efficient/faster to use simple OS scripts than Gradle tasks 
for pullPluginSource and pullAllPluginsSource


Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen,

Inline...

Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :

Hi Eugen,

This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md

Obviously some parts are obsolete since we rely now on Docker for demos. Could 
you please review and possibly amend?


Please forgot that, I'll handle it.

Jacques

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Thanks Daniel!

Jacques

Le 26/12/2023 à 08:17, Daniel Watford a écrit :

Hi Jacques,

Dropping the pullAllPluginsSource gradle task will have the benefit of
simplifying the building of docker images. Please see the comment on the
topic here:
https://github.com/apache/ofbiz-framework/blob/0530a58d3a912520b7f9e46c5ccde98fd3737bf5/.github/workflows/docker-image.yaml#L126

I'll create and work a ticket over the next few days to amend the docker
image build process to use a git clone/checkout of the ofbiz-plugins
repository rather than use the pullAllPluginsSoruce gradle task. The ticket
will apply to the trunk, release18.12 and release22.01 branches.

Thanks,

Dan.


On Mon, 25 Dec 2023 at 08:34, Jacques Le Roux 
wrote:


Hi Eugen, Daniel,

Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :

Last but not least, I guess we will need very soon to change something

in Docker config for demos ; since pullAllPluginsSource relies on soon not

usable SvnCheckout plugin?

Actually this last sentence was more directed to Daniel

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen, Daniel,

Le 24/12/2023 à 12:05, Jacques Le Roux a écrit :
Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not 
usable SvnCheckout plugin?

Actually this last sentence was more directed to Daniel

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi Eugen,

I tend to agree with your vision that sounds quite promising. I'm sorry I got 
no time to review your PR yet. I hope to do so during next year...

Of course, this architecture will need to be discussed more and especially will not be part of the next release branch (24.01 ? 18.12 becoming really 
old).


This said I was reading 
https://cwiki.apache.org/confluence/display/OFBIZ/Release+Management+Guide+for+OFBiz
and stumbled upon 
https://github.com/apache/ofbiz-tools/blob/master/demo-backup/README.md

Obviously some parts are obsolete since we rely now on Docker for demos. Could 
you please review and possibly amend?

Last but not least, I guess we will need very soon to change something in Docker config for demos ; since pullAllPluginsSource relies on soon not 
usable SvnCheckout plugin?


TIA

Jacques

Le 23/12/2023 à 20:43, eugen.s...@netdava.com a écrit :

Hi Jacques,

Regarding the plugin workflow, the PR that I posted can offer alternative ways 
to develop and consume plugins / components.
This would make plugin development by pulling sources in ofbiz optional / 
obsolete even (a choice).

If we move to have libraries that are published as jar files, then it would be 
possible to develop plugins by depending on the specific OFBiz bits.
It would also be possible to publish plugins / components as regular java jars 
and consume them the same way.
So, in the future a custom OFBiz build could look something like this:

build.gradle

dependencies {
  implementation 'org.apache.ofbiz:entity-engine:24.0'
  implementation 'org.apache.ofbiz:service:24.0'
  implementation 'org.apache.ofbiz:accounting:24.0'
  implementation 'com.example:my-plugin:1.2.3'
}




On 23.12.2023 17:06, Jacques Le Roux  wrote:

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :
> Hi,
>
> I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for > 
that... WIP...
>
> HTH
>
> Jacques
>
> Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :
>> Hi,
>>
>> As you may have noticed*, the SvnCheckout Gradle plugin will not be >> 
usable after January 8, 2024.
>>
>> So we need a replacement and it's clearly suggested by GitHub in the >> link 
below
>>
>> Jacques
>>
>> * https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

It's ready for review before pushing and testing with GH and BB

TIA

Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: SvnCheckout Gradle plugin soon no longer usable with GitHub

[Jacques Le Roux]

Hi,

OK, we need more effort here because GH and BB will break at January 8, 2024 and we need to test the changes before... In other words we have at most 
2 weeks available...


I have one question. It seems to me that the Gradle "installPlugin" task, called by the pullPluginSource and pullAllPluginsSource tasks, is not 
implement in any OOTB plugin.


I ask this question because, if it eventually unused, it's quite easier and especially efficient/faster to use simple OS scripts than Gradle tasks for 
pullPluginSource and pullAllPluginsSource


Jacques

Le 01/12/2023 à 11:18, Jacques Le Roux a écrit :

Hi,

I have created https://issues.apache.org/jira/browse/OFBIZ-12868 for that... 
WIP...

HTH

Jacques

Le 27/11/2023 à 13:41, Jacques Le Roux a écrit :

Hi,

As you may have noticed*, the SvnCheckout Gradle plugin will not be usable 
after January 8, 2024.

So we need a replacement and it's clearly suggested by GitHub in the link below

Jacques

* https://lists.apache.org/thread/08kwg2ovjt4qyfybhf1qzsvq42jsy2wz

Re: Migration from ci.a.o

[Jacques Le Roux]

Hi,

As you may know this is definitely replaced by a solution in the BB UI (I sent 
a message about that somewhere else)

Jacques

Le 10/07/2022 à 10:00, Jacques Le Roux a écrit :

Le 11/01/2022 à 17:54, Jacques Le Roux a écrit :

Also are missing, faculty to start a build from IRC and, more technical, the 
possibility to use several servers to launch builds.
We had all that before... 


Hi,

At least I have asked for faculty to start a build from IRC at 
https://issues.apache.org/jira/browse/INFRA-23471

Let's see...

Jacques

Re: Missing search options when using

[Jacques Le Roux]

Hi Ken,

Sorry I missed your message. Did you since find a way by yourself?

Jacques

Le 16/10/2023 à 16:15, Ken Mantle a écrit :

I see that in the widget-form.xsd file under  there are 
9 options for searching, but when I use a  in my forms I only have access to the 
following 4:
Begins With
Contains
Is Empty
Not Equal

I also noticed that these are the only 4 available in all of my Ofbiz. Is there a way to 
get access to the others, as I really need "equals" to work for my queries in 
the simple Associated Files plugin I made.

Many thanks!

Ken

Here is the code in widget-form.xsd I am referring to:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Re: [VOTE] Release Apache OFBiz 18.12.11

[Jacques Le Roux]

+1

All works as expected

Jacques

Le 16/12/2023 à 11:02, Jacopo Cappellato a écrit :

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: breaking ofbiz piece by piece - expose parts to outside

[Jacques Le Roux]

Le 06/12/2023 à 22:02, Eugen Stan a écrit :

Hi,

La 06.12.2023 18:01, Jacques Le Roux a scris:

Le 06/12/2023 à 15:32, Eugen Stan a écrit :

I need help with that one since I don't know how to run itests in IDE to debug


Hi Eugen,

I answered you at https://issues.apache.org/jira/browse/OFBIZ-12726



Merci Jacques :) .
It seems all integration tests are passing for my branch.

Please let me know your feedback and what will it take to have the PR merged.

Once that is done I would like to focus on fixing the tests for JDK17 and see 
what will it take to get OFBiz on JDK21.

Once the datafile is published (being optimistic) I would like to work on some CLI tooling to import data in OFBIz. Alternative to current gradle / 
WebTools tooling.



I'll have a look ASAP, ie not before next week...

Cheers

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

[Jacques Le Roux]

Le 06/12/2023 à 15:32, Eugen Stan a écrit :

I need help with that one since I don't know how to run itests in IDE to debug


Hi Eugen,

I answered you at https://issues.apache.org/jira/browse/OFBIZ-12726