You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2016/08/19 15:40:29 UTC
Wiki documentation update with respect to Gradle
Hi,
I have done some wiki documentation update with respect to Gradle recently. Today I got issues with Confluence which broke my working flow on the
Apache OFBiz Technical Production Setup Guide <https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+Production+Setup+Guide> page
more than once. So I'd appreciate reviews, not only on this page but on all recently changed pages. If you follow Confluence changes, you should be
aware of them.
Thanks
Jacques
Re: Wiki documentation update with respect to Gradle
Posted by "jleroux@apache.org" <jl...@apache.org>.
Agreed, good idea
Jacques
Le 19/08/2016 � 22:34, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> Okay based on your feedback I would suggest to create a special page /
> section in the documentation that has the title "Deploying OFBiz on offline
> servers" or something like that. I would rather hide this information from
> a "standard" normal system setup and keep the corner cases away. What you
> are mentioning is less common scenarios that are rather rare in this age
> where cloud computing is the norm. This way, you keep things easy for our
> new users while providing more information for those with special
> deployment needs.
>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Aug 19, 2016 at 11:10 PM, jleroux@apache.org <jl...@apache.org>
> wrote:
>
>> Taher
>>
>> Actually I though more about it, we really need something like that.
>>
>> Actually we need to help our users when they are in a situation like I
>> crossed once and reported here http://markmail.org/message/li
>> vdricudqdj6tmi :
>>
>> "Also, as Pierre outlined, there are situations were you can't use Gradle
>> but on dev machines. I experienced that, no servers were allowed to connect
>> to the Internet at all..."
>>
>> When I say that we need to help our users I mean that we need to lead them
>> to a solution, and even if possible provide an easy way for them to build
>> one.
>>
>> In other words, if you have no access to Internet on production servers,
>> and still want to use Gradle as it comes OOTB, you need to create an use
>> your own repository.
>>
>> This is what we are currently missing in the documentation. We don't need
>> to provide the mean, but at least to document how to do it. If we could
>> facilitate the needed work in this case it would be even better...
>>
>> Jacques
>>
>>
>>
>> Le 19/08/2016 � 18:22, Taher Alkhateeb a �crit :
>>
>>> Hi Jacques,
>>>
>>> I think there should be an added value beyond "because it used to be
>>> there". What is the purpose of keeping it with disclaimers in your
>>> opinion?
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Hi Taher,
>>>> I'd not be against (still in the lean way), but should we not keep at
>>>> least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
>>>> precaution)?
>>>>
>>>> What are other opinions?
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 19/08/2016 � 17:50, Taher Alkhateeb a �crit :
>>>>
>>>> Hi Jacques,
>>>>> On a quick skim through, I highly recommend removing completely any
>>>>> traces
>>>>> of "java -jar". The reason for my recommendation is that gradle
>>>>> automates
>>>>> the build process. Exposing end-users to how things happen means
>>>>> exposing
>>>>> them to implementation details. This has the following negative
>>>>> outcomes:
>>>>>
>>>>> - Users need to be aware of JVM arguments to properly execute commands
>>>>> - Changes we might decide to do in the future would break existing
>>>>> systems
>>>>> because users are exposed to the details of how the system is
>>>>> constructed.
>>>>> - The ofbiz.jar which is constructed from gradle has hardcoded library
>>>>> paths that depend on each user's computer setup. Any changes to the
>>>>> setup
>>>>> would not be reflected correctly using raw java commands. This would
>>>>> probably confuse people a lot and debugging would be a pain. If you let
>>>>> Gradle take over the whole thing then you minimize the confusion.
>>>>> - The syntax for java -jar is more complex
>>>>>
>>>>> So my recommendation is to replace every occurence of java -jar with
>>>>> ./gradlew "ofbiz --whatever-commands-here".
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> I have done some wiki documentation update with respect to Gradle
>>>>>> recently. Today I got issues with Confluence which broke my working
>>>>>> flow
>>>>>> on
>>>>>> the Apache OFBiz Technical Production Setup Guide <
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>>>>>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>>>>>> appreciate reviews, not only on this page but on all recently changed
>>>>>> pages. If you follow Confluence changes, you should be aware of them.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
Re: Wiki documentation update with respect to Gradle
Posted by "jleroux@apache.org" <jl...@apache.org>.
Indirectly it was the repository, they should not accept things breaking other things down the flow ;)
This said I agree it's totally unrelated to exposing our users to Java.
Jacques
Le 19/08/2016 � 22:38, Taher Alkhateeb a �crit :
> I would also like to mention that the issue you reported on the thread you
> mentioned ( http://markmail.org/message/livdricudqdj6tmi ) turned out not
> to have anything todo with repositories or Gradle. Instead it was an
> exposed version of a library with a wrong header. Gradle was very stable
> before and after fixing this issue that was transient only for a few days
> until we discovered what was wrong (apache shiro exposed wrong version due
> to change in dependencies).
>
> So I would exclude that thread as a necessary reason for exposing our users
> directly to Java.
>
> On Fri, Aug 19, 2016 at 11:34 PM, Taher Alkhateeb <
> slidingfilaments@gmail.com> wrote:
>
>> Hi Jacques,
>>
>> Okay based on your feedback I would suggest to create a special page /
>> section in the documentation that has the title "Deploying OFBiz on offline
>> servers" or something like that. I would rather hide this information from
>> a "standard" normal system setup and keep the corner cases away. What you
>> are mentioning is less common scenarios that are rather rare in this age
>> where cloud computing is the norm. This way, you keep things easy for our
>> new users while providing more information for those with special
>> deployment needs.
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Fri, Aug 19, 2016 at 11:10 PM, jleroux@apache.org <jl...@apache.org>
>> wrote:
>>
>>> Taher
>>>
>>> Actually I though more about it, we really need something like that.
>>>
>>> Actually we need to help our users when they are in a situation like I
>>> crossed once and reported here http://markmail.org/message/li
>>> vdricudqdj6tmi :
>>>
>>> "Also, as Pierre outlined, there are situations were you can't use Gradle
>>> but on dev machines. I experienced that, no servers were allowed to connect
>>> to the Internet at all..."
>>>
>>> When I say that we need to help our users I mean that we need to lead
>>> them to a solution, and even if possible provide an easy way for them to
>>> build one.
>>>
>>> In other words, if you have no access to Internet on production servers,
>>> and still want to use Gradle as it comes OOTB, you need to create an use
>>> your own repository.
>>>
>>> This is what we are currently missing in the documentation. We don't need
>>> to provide the mean, but at least to document how to do it. If we could
>>> facilitate the needed work in this case it would be even better...
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 19/08/2016 � 18:22, Taher Alkhateeb a �crit :
>>>
>>>> Hi Jacques,
>>>>
>>>> I think there should be an added value beyond "because it used to be
>>>> there". What is the purpose of keeping it with disclaimers in your
>>>> opinion?
>>>>
>>>> Regards,
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Hi Taher,
>>>>> I'd not be against (still in the lean way), but should we not keep at
>>>>> least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
>>>>> precaution)?
>>>>>
>>>>> What are other opinions?
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 19/08/2016 � 17:50, Taher Alkhateeb a �crit :
>>>>>
>>>>> Hi Jacques,
>>>>>> On a quick skim through, I highly recommend removing completely any
>>>>>> traces
>>>>>> of "java -jar". The reason for my recommendation is that gradle
>>>>>> automates
>>>>>> the build process. Exposing end-users to how things happen means
>>>>>> exposing
>>>>>> them to implementation details. This has the following negative
>>>>>> outcomes:
>>>>>>
>>>>>> - Users need to be aware of JVM arguments to properly execute commands
>>>>>> - Changes we might decide to do in the future would break existing
>>>>>> systems
>>>>>> because users are exposed to the details of how the system is
>>>>>> constructed.
>>>>>> - The ofbiz.jar which is constructed from gradle has hardcoded library
>>>>>> paths that depend on each user's computer setup. Any changes to the
>>>>>> setup
>>>>>> would not be reflected correctly using raw java commands. This would
>>>>>> probably confuse people a lot and debugging would be a pain. If you let
>>>>>> Gradle take over the whole thing then you minimize the confusion.
>>>>>> - The syntax for java -jar is more complex
>>>>>>
>>>>>> So my recommendation is to replace every occurence of java -jar with
>>>>>> ./gradlew "ofbiz --whatever-commands-here".
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>>
>>>>>> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>> I have done some wiki documentation update with respect to Gradle
>>>>>>> recently. Today I got issues with Confluence which broke my working
>>>>>>> flow
>>>>>>> on
>>>>>>> the Apache OFBiz Technical Production Setup Guide <
>>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>>>>>>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>>>>>>> appreciate reviews, not only on this page but on all recently changed
>>>>>>> pages. If you follow Confluence changes, you should be aware of them.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
Re: Wiki documentation update with respect to Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
I would also like to mention that the issue you reported on the thread you
mentioned ( http://markmail.org/message/livdricudqdj6tmi ) turned out not
to have anything todo with repositories or Gradle. Instead it was an
exposed version of a library with a wrong header. Gradle was very stable
before and after fixing this issue that was transient only for a few days
until we discovered what was wrong (apache shiro exposed wrong version due
to change in dependencies).
So I would exclude that thread as a necessary reason for exposing our users
directly to Java.
On Fri, Aug 19, 2016 at 11:34 PM, Taher Alkhateeb <
slidingfilaments@gmail.com> wrote:
> Hi Jacques,
>
> Okay based on your feedback I would suggest to create a special page /
> section in the documentation that has the title "Deploying OFBiz on offline
> servers" or something like that. I would rather hide this information from
> a "standard" normal system setup and keep the corner cases away. What you
> are mentioning is less common scenarios that are rather rare in this age
> where cloud computing is the norm. This way, you keep things easy for our
> new users while providing more information for those with special
> deployment needs.
>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Aug 19, 2016 at 11:10 PM, jleroux@apache.org <jl...@apache.org>
> wrote:
>
>> Taher
>>
>> Actually I though more about it, we really need something like that.
>>
>> Actually we need to help our users when they are in a situation like I
>> crossed once and reported here http://markmail.org/message/li
>> vdricudqdj6tmi :
>>
>> "Also, as Pierre outlined, there are situations were you can't use Gradle
>> but on dev machines. I experienced that, no servers were allowed to connect
>> to the Internet at all..."
>>
>> When I say that we need to help our users I mean that we need to lead
>> them to a solution, and even if possible provide an easy way for them to
>> build one.
>>
>> In other words, if you have no access to Internet on production servers,
>> and still want to use Gradle as it comes OOTB, you need to create an use
>> your own repository.
>>
>> This is what we are currently missing in the documentation. We don't need
>> to provide the mean, but at least to document how to do it. If we could
>> facilitate the needed work in this case it would be even better...
>>
>> Jacques
>>
>>
>>
>> Le 19/08/2016 à 18:22, Taher Alkhateeb a écrit :
>>
>>> Hi Jacques,
>>>
>>> I think there should be an added value beyond "because it used to be
>>> there". What is the purpose of keeping it with disclaimers in your
>>> opinion?
>>>
>>> Regards,
>>>
>>> Taher Alkhateeb
>>>
>>> On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Hi Taher,
>>>>
>>>> I'd not be against (still in the lean way), but should we not keep at
>>>> least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
>>>> precaution)?
>>>>
>>>> What are other opinions?
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :
>>>>
>>>> Hi Jacques,
>>>>>
>>>>> On a quick skim through, I highly recommend removing completely any
>>>>> traces
>>>>> of "java -jar". The reason for my recommendation is that gradle
>>>>> automates
>>>>> the build process. Exposing end-users to how things happen means
>>>>> exposing
>>>>> them to implementation details. This has the following negative
>>>>> outcomes:
>>>>>
>>>>> - Users need to be aware of JVM arguments to properly execute commands
>>>>> - Changes we might decide to do in the future would break existing
>>>>> systems
>>>>> because users are exposed to the details of how the system is
>>>>> constructed.
>>>>> - The ofbiz.jar which is constructed from gradle has hardcoded library
>>>>> paths that depend on each user's computer setup. Any changes to the
>>>>> setup
>>>>> would not be reflected correctly using raw java commands. This would
>>>>> probably confuse people a lot and debugging would be a pain. If you let
>>>>> Gradle take over the whole thing then you minimize the confusion.
>>>>> - The syntax for java -jar is more complex
>>>>>
>>>>> So my recommendation is to replace every occurence of java -jar with
>>>>> ./gradlew "ofbiz --whatever-commands-here".
>>>>>
>>>>> Taher Alkhateeb
>>>>>
>>>>> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> I have done some wiki documentation update with respect to Gradle
>>>>>> recently. Today I got issues with Confluence which broke my working
>>>>>> flow
>>>>>> on
>>>>>> the Apache OFBiz Technical Production Setup Guide <
>>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>>>>>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>>>>>> appreciate reviews, not only on this page but on all recently changed
>>>>>> pages. If you follow Confluence changes, you should be aware of them.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
Re: Wiki documentation update with respect to Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
Okay based on your feedback I would suggest to create a special page /
section in the documentation that has the title "Deploying OFBiz on offline
servers" or something like that. I would rather hide this information from
a "standard" normal system setup and keep the corner cases away. What you
are mentioning is less common scenarios that are rather rare in this age
where cloud computing is the norm. This way, you keep things easy for our
new users while providing more information for those with special
deployment needs.
Regards,
Taher Alkhateeb
On Fri, Aug 19, 2016 at 11:10 PM, jleroux@apache.org <jl...@apache.org>
wrote:
> Taher
>
> Actually I though more about it, we really need something like that.
>
> Actually we need to help our users when they are in a situation like I
> crossed once and reported here http://markmail.org/message/li
> vdricudqdj6tmi :
>
> "Also, as Pierre outlined, there are situations were you can't use Gradle
> but on dev machines. I experienced that, no servers were allowed to connect
> to the Internet at all..."
>
> When I say that we need to help our users I mean that we need to lead them
> to a solution, and even if possible provide an easy way for them to build
> one.
>
> In other words, if you have no access to Internet on production servers,
> and still want to use Gradle as it comes OOTB, you need to create an use
> your own repository.
>
> This is what we are currently missing in the documentation. We don't need
> to provide the mean, but at least to document how to do it. If we could
> facilitate the needed work in this case it would be even better...
>
> Jacques
>
>
>
> Le 19/08/2016 à 18:22, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> I think there should be an added value beyond "because it used to be
>> there". What is the purpose of keeping it with disclaimers in your
>> opinion?
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Hi Taher,
>>>
>>> I'd not be against (still in the lean way), but should we not keep at
>>> least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
>>> precaution)?
>>>
>>> What are other opinions?
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :
>>>
>>> Hi Jacques,
>>>>
>>>> On a quick skim through, I highly recommend removing completely any
>>>> traces
>>>> of "java -jar". The reason for my recommendation is that gradle
>>>> automates
>>>> the build process. Exposing end-users to how things happen means
>>>> exposing
>>>> them to implementation details. This has the following negative
>>>> outcomes:
>>>>
>>>> - Users need to be aware of JVM arguments to properly execute commands
>>>> - Changes we might decide to do in the future would break existing
>>>> systems
>>>> because users are exposed to the details of how the system is
>>>> constructed.
>>>> - The ofbiz.jar which is constructed from gradle has hardcoded library
>>>> paths that depend on each user's computer setup. Any changes to the
>>>> setup
>>>> would not be reflected correctly using raw java commands. This would
>>>> probably confuse people a lot and debugging would be a pain. If you let
>>>> Gradle take over the whole thing then you minimize the confusion.
>>>> - The syntax for java -jar is more complex
>>>>
>>>> So my recommendation is to replace every occurence of java -jar with
>>>> ./gradlew "ofbiz --whatever-commands-here".
>>>>
>>>> Taher Alkhateeb
>>>>
>>>> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> I have done some wiki documentation update with respect to Gradle
>>>>> recently. Today I got issues with Confluence which broke my working
>>>>> flow
>>>>> on
>>>>> the Apache OFBiz Technical Production Setup Guide <
>>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>>>>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>>>>> appreciate reviews, not only on this page but on all recently changed
>>>>> pages. If you follow Confluence changes, you should be aware of them.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>>
Re: Wiki documentation update with respect to Gradle
Posted by "jleroux@apache.org" <jl...@apache.org>.
Taher
Actually I though more about it, we really need something like that.
Actually we need to help our users when they are in a situation like I crossed once and reported here http://markmail.org/message/livdricudqdj6tmi :
"Also, as Pierre outlined, there are situations were you can't use Gradle but on dev machines. I experienced that, no servers were allowed to connect
to the Internet at all..."
When I say that we need to help our users I mean that we need to lead them to a solution, and even if possible provide an easy way for them to build one.
In other words, if you have no access to Internet on production servers, and still want to use Gradle as it comes OOTB, you need to create an use your
own repository.
This is what we are currently missing in the documentation. We don't need to provide the mean, but at least to document how to do it. If we could
facilitate the needed work in this case it would be even better...
Jacques
Le 19/08/2016 � 18:22, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> I think there should be an added value beyond "because it used to be
> there". What is the purpose of keeping it with disclaimers in your opinion?
>
> Regards,
>
> Taher Alkhateeb
>
> On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi Taher,
>>
>> I'd not be against (still in the lean way), but should we not keep at
>> least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
>> precaution)?
>>
>> What are other opinions?
>>
>> Jacques
>>
>>
>>
>> Le 19/08/2016 � 17:50, Taher Alkhateeb a �crit :
>>
>>> Hi Jacques,
>>>
>>> On a quick skim through, I highly recommend removing completely any traces
>>> of "java -jar". The reason for my recommendation is that gradle automates
>>> the build process. Exposing end-users to how things happen means exposing
>>> them to implementation details. This has the following negative outcomes:
>>>
>>> - Users need to be aware of JVM arguments to properly execute commands
>>> - Changes we might decide to do in the future would break existing systems
>>> because users are exposed to the details of how the system is constructed.
>>> - The ofbiz.jar which is constructed from gradle has hardcoded library
>>> paths that depend on each user's computer setup. Any changes to the setup
>>> would not be reflected correctly using raw java commands. This would
>>> probably confuse people a lot and debugging would be a pain. If you let
>>> Gradle take over the whole thing then you minimize the confusion.
>>> - The syntax for java -jar is more complex
>>>
>>> So my recommendation is to replace every occurence of java -jar with
>>> ./gradlew "ofbiz --whatever-commands-here".
>>>
>>> Taher Alkhateeb
>>>
>>> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Hi,
>>>> I have done some wiki documentation update with respect to Gradle
>>>> recently. Today I got issues with Confluence which broke my working flow
>>>> on
>>>> the Apache OFBiz Technical Production Setup Guide <
>>>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>>>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>>>> appreciate reviews, not only on this page but on all recently changed
>>>> pages. If you follow Confluence changes, you should be aware of them.
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
Re: Wiki documentation update with respect to Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
I think there should be an added value beyond "because it used to be
there". What is the purpose of keeping it with disclaimers in your opinion?
Regards,
Taher Alkhateeb
On Fri, Aug 19, 2016 at 7:19 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi Taher,
>
> I'd not be against (still in the lean way), but should we not keep at
> least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of
> precaution)?
>
> What are other opinions?
>
> Jacques
>
>
>
> Le 19/08/2016 à 17:50, Taher Alkhateeb a écrit :
>
>> Hi Jacques,
>>
>> On a quick skim through, I highly recommend removing completely any traces
>> of "java -jar". The reason for my recommendation is that gradle automates
>> the build process. Exposing end-users to how things happen means exposing
>> them to implementation details. This has the following negative outcomes:
>>
>> - Users need to be aware of JVM arguments to properly execute commands
>> - Changes we might decide to do in the future would break existing systems
>> because users are exposed to the details of how the system is constructed.
>> - The ofbiz.jar which is constructed from gradle has hardcoded library
>> paths that depend on each user's computer setup. Any changes to the setup
>> would not be reflected correctly using raw java commands. This would
>> probably confuse people a lot and debugging would be a pain. If you let
>> Gradle take over the whole thing then you minimize the confusion.
>> - The syntax for java -jar is more complex
>>
>> So my recommendation is to replace every occurence of java -jar with
>> ./gradlew "ofbiz --whatever-commands-here".
>>
>> Taher Alkhateeb
>>
>> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Hi,
>>>
>>> I have done some wiki documentation update with respect to Gradle
>>> recently. Today I got issues with Confluence which broke my working flow
>>> on
>>> the Apache OFBiz Technical Production Setup Guide <
>>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>>> appreciate reviews, not only on this page but on all recently changed
>>> pages. If you follow Confluence changes, you should be aware of them.
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>
>
Re: Wiki documentation update with respect to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Taher,
I'd not be against (still in the lean way), but should we not keep at least "java -jar build/libs/ofbiz.jar ?" (with disclaimer words of precaution)?
What are other opinions?
Jacques
Le 19/08/2016 � 17:50, Taher Alkhateeb a �crit :
> Hi Jacques,
>
> On a quick skim through, I highly recommend removing completely any traces
> of "java -jar". The reason for my recommendation is that gradle automates
> the build process. Exposing end-users to how things happen means exposing
> them to implementation details. This has the following negative outcomes:
>
> - Users need to be aware of JVM arguments to properly execute commands
> - Changes we might decide to do in the future would break existing systems
> because users are exposed to the details of how the system is constructed.
> - The ofbiz.jar which is constructed from gradle has hardcoded library
> paths that depend on each user's computer setup. Any changes to the setup
> would not be reflected correctly using raw java commands. This would
> probably confuse people a lot and debugging would be a pain. If you let
> Gradle take over the whole thing then you minimize the confusion.
> - The syntax for java -jar is more complex
>
> So my recommendation is to replace every occurence of java -jar with
> ./gradlew "ofbiz --whatever-commands-here".
>
> Taher Alkhateeb
>
> On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Hi,
>>
>> I have done some wiki documentation update with respect to Gradle
>> recently. Today I got issues with Confluence which broke my working flow on
>> the Apache OFBiz Technical Production Setup Guide <
>> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
>> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
>> appreciate reviews, not only on this page but on all recently changed
>> pages. If you follow Confluence changes, you should be aware of them.
>>
>> Thanks
>>
>> Jacques
>>
>>
Re: Wiki documentation update with respect to Gradle
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques,
On a quick skim through, I highly recommend removing completely any traces
of "java -jar". The reason for my recommendation is that gradle automates
the build process. Exposing end-users to how things happen means exposing
them to implementation details. This has the following negative outcomes:
- Users need to be aware of JVM arguments to properly execute commands
- Changes we might decide to do in the future would break existing systems
because users are exposed to the details of how the system is constructed.
- The ofbiz.jar which is constructed from gradle has hardcoded library
paths that depend on each user's computer setup. Any changes to the setup
would not be reflected correctly using raw java commands. This would
probably confuse people a lot and debugging would be a pain. If you let
Gradle take over the whole thing then you minimize the confusion.
- The syntax for java -jar is more complex
So my recommendation is to replace every occurence of java -jar with
./gradlew "ofbiz --whatever-commands-here".
Taher Alkhateeb
On Fri, Aug 19, 2016 at 6:40 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Hi,
>
> I have done some wiki documentation update with respect to Gradle
> recently. Today I got issues with Confluence which broke my working flow on
> the Apache OFBiz Technical Production Setup Guide <
> https://cwiki.apache.org/confluence/display/OFBIZ/Apache+
> OFBiz+Technical+Production+Setup+Guide> page more than once. So I'd
> appreciate reviews, not only on this page but on all recently changed
> pages. If you follow Confluence changes, you should be aware of them.
>
> Thanks
>
> Jacques
>
>
Re: Wiki documentation update with respect to Gradle
Posted by Jacques Le Roux <ja...@les7arts.com>.
I put a list of the main changed pages at https://issues.apache.org/jira/browse/OFBIZ-7677?focusedCommentId=15428381
Jacques
Le 19/08/2016 � 17:40, Jacques Le Roux a �crit :
> Hi,
>
> I have done some wiki documentation update with respect to Gradle recently. Today I got issues with Confluence which broke my working flow on the
> Apache OFBiz Technical Production Setup Guide <https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+Production+Setup+Guide> page
> more than once. So I'd appreciate reviews, not only on this page but on all recently changed pages. If you follow Confluence changes, you should be
> aware of them.
>
> Thanks
>
> Jacques
>
>