I think there is some functionality in the field of (product) content
management to automatically resize images.
Has this anyting to do with it?
Regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 19.04.23 um 08:17 schrieb Daniel Watford:
Thanks Jacques and Jacopo for your responses.
Hi Jacques,
I haven't found a way to selectively inhibit the failure state of a gradle
task.
However, I'm not sure we should take that approach otherwise we may find
ourselves in a situation where issues related to checkstyle and codenarc
are not addressed.
[ Side note: In this particular case,
Thanks Jacques and Jacopo for your responses.
Jacques, like you I found the path to the functionality through
controller.xml, but was not able to find any path through the UI that a
user would take to make use of the functionality.
This leads me to believe the Jcrop (and other associated)
Not quite sure why this happened (happens sometimes). I guess due to my use of
ToirtoiseGit. Anyway not a big deal, actually just a "void" message.
Le 19/04/2023 à 14:28, jler...@apache.org a écrit :
This is an automated email from the ASF dual-hosted git repository.
jleroux pushed a change
Hi Michael,
I couldn't find anything in the UI for product content that would allow
manipulation (cropping, rotating, resizing) of images.
It's not a well known area for me, hence wanting to check in with the
community.
I imagine the functionality was withdrawn from the UI at some point, but
Hi Daniel,
For now I have committed a change in BB config in order to generate a file at
https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html
It should appear with the next trunk commit.
I agree that should be enough. It's similar to what I did for checkstyle.
And indeed fixing new
Hi Michaek, All,
Yes that's also what I think and said in my answer to Daniel. But I did not
dig, more an intuition, like you.
Jacques
Le 19/04/2023 à 09:19, Michael Brohl a écrit :
I think there is some functionality in the field of (product) content
management to automatically resize
Everybody can now help by looking at
https://nightlies.apache.org/ofbiz/trunk/groovyScripts.html (only trunk for now)
Le 12/04/2023 à 17:24, Jacques Le Roux a écrit :
Hi Gil,
IMO better forget it, that's not a big deal and it looks good enough to me at
Hi All,
At OFBIZ-12801, we had a discussion with Daniel and Gil about the described
issue (last comments there)
We are unsure of the best solution, so this thread to discuss and decide.
As Gil reported, Jacopo's comment of the related commit* contains
<>
What would be your opinion about a
Hi everyone,
it seems that we have a solution for the Eclipse Java build and runtime
problems we faced with JDK 17 (not speaking of the Groovy build problems).
We removed some (transitive) dependencies in the build file and updated
some of them so that libraries are used from the JDK instead
Hi Michael,
That's surely the best and cleaner solution
Thanks
Jacques
Le 19/04/2023 à 15:52, Michael Brohl a écrit :
Hi everyone,
it seems that we have a solution for the Eclipse Java build and runtime
problems we faced with JDK 17 (not speaking of the Groovy build problems).
We removed
Hello,
In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the code was
called.
The untyped nature of Groovy had allowed a certain degree of flexibility in
12 matches
Mail list logo
