Hello Mathieu,
I did not know that it was you who changed it nor am I implying
"sneaking" anything. I'm just analyzing the reason for the dependency
on classes sticking in the code base and did not check who / why out
of laziness. I appreciate your understanding and hope you don't
personalize
Mathieu Lirzin writes:
> If people want to be in charge of the compilation and execution
> lifecycles, they are free to use Gradle to build an artifact and run
> OFBiz outside of their build tool like in the following example:
>
> ```
> $ ./gradlew jar
> $ java -jar build/libs/ofbiz &
> $ java
Hello,
Taher Alkhateeb writes:
> I think I understand the reason why this is happening. Someone changed
> the implementation of createOfbizCommandTask to depend on the classes
> directly instead of depending on the generated Jar. I'm not sure why
> but I personally do not prefer this approach.
or another approach is again to have another if condition to say if
the task is shutdown, then depend on the jar, else depend on the
classes although that would be messy IMO and might increase the
technical debt due to inconsistencies
On Wed, Feb 26, 2020 at 6:36 PM Taher Alkhateeb
wrote:
>
> I
I think I understand the reason why this is happening. Someone changed
the implementation of createOfbizCommandTask to depend on the classes
directly instead of depending on the generated Jar. I'm not sure why
but I personally do not prefer this approach.
The solution is to revert to the original
Hi Taher,
the configuration in your patch is executed correctly, I logged it with
this code enhancement:
if (!(taskName ==~ /^ofbiz.*(--shutdown|-d).*/)) {
println taskName + ' dependsOn classes'
dependsOn classes
} else {
println taskName +
Hi Michael,
I could be mistaken, but I think perhaps you're trying to remove the
dependency during the execution phase instead of the configuration
phase?
Would a patch like the below not work?
diff --git a/build.gradle b/build.gradle
index e5bfb3e9c9..96dcb53a01 100644
--- a/build.gradle
+++
Hi Taher,
thanks for your feedback!
It seems that removing a dependency from a task is deprecated and should
not be used:
"Do not remove a task dependency from a Task instance. This behaviour
has been deprecated and is scheduled to be removed in Gradle 6.0."
Given this depracation, do you
Hi Michael,
The idea is fine but I think we can improve the implementation. All that
you need is to remove the dependsOn declaration if it is a shutdown command
which would probably result in less code than in the proposed patch.
Cheers
On Tue, Feb 25, 2020, 1:32 PM Michael Brohl
wrote:
>
Oops, just realized I already asked in
https://lists.apache.org/thread.html/rf88ce5eb1a3842471ddb8239bb5f08b71c107c4b0d3863b3c13e54fe%40%3Cdev.ofbiz.apache.org%3E
Better respond there, thanks!
Michael
Am 25.02.20 um 11:29 schrieb Michael Brohl:
Hi devs,
any objections to get this into the
Hi devs,
any objections to get this into the codebase (and backporting to
17.12./18.12)?
See https://issues.apache.org/jira/browse/OFBIZ-10168
Thanks for your feedback,
Michael Brohl
ecomify GmbH - www.ecomify.de
smime.p7s
Description: S/MIME Cryptographic Signature
11 matches
Mail list logo