Re: Taking a decision on remaining Jars in OFBiz

Hi Jacques, Why not try to convince the people behind notsoserial to have them push the library to maven central and/or jpublish? In stead of this community doing the work? Best regards, Pierre Smits ORRTIZ.COM OFBiz based solutions & services OFBiz Extensions Marketpl

Re: Sharing the burden of maintaining documentation

Hi Jacques, I would suggest to make a distinction between two types of documentation: 1- short documentation for quick reference 2- long documentation bringing comprehensive explanations, examples, sections, etc. Taking this distinction into consideration, I would suggest: - definitely the best p

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org wrote: > ... > IMO we can delete the cmssite component jars they are only used in > extensions of Dockbook and AFAIK we don't use them > > +1 > > notsoserial-1.0-SNAPSHOT.jar we need to keep, maybe we could push it in > jcenter, but would be b

Re: Taking a decision on remaining Jars in OFBiz

On Sat, Aug 20, 2016 at 7:57 AM, jler...@apache.org wrote: > ... > ebaystore component we need to put in Attic? > Either attic or (quoting myself from a previous mail in this thread) "remove these jars, disable the component, add a README file to the component to explain how to download the jars

Re: Sharing the burden of maintaining documentation

IMO, we should not have this kind of documentation in the standard repository, as it creates bloatware in the application. Better would be to have it it in seperate repository. Best regards Pierre Smits ORRTIZ.COM OFBiz based solutions & services OFBiz Extensions Marketp

Re: Taking a decision on remaining Jars in OFBiz

Well done you Gil & Nicolas, great work. The framework is finally clean. Jacques I think requesting publishing in jcenter is a good idea. Worst case scenario might not be pretty (download and compile the jar ourselves as a subproject).

Re: Taking a decision on remaining Jars in OFBiz

Congrats for your work at r1756949 Gil and Nicolas! At r1756984 I have removed the base/lib and its reference in base ofbiz-component.xml So we have no longer any jars but - cmssite component - ebaystore component - the tools directory IMO we can delete the cmssite component jars they are on

Sharing the burden of maintaining documentation

Hi, Not so long ago Jacopo suggested that we use our versionning system (ie currently Subversion) to maintain the documentation. Or at least the most important or entry points of the documentation which will still stay on our wiki (ie Confluence) I think that by creating MarkDown files (or oth

Re: Wiki documentation update with respect to Gradle

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

Re: Wiki documentation update with respect to Gradle

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 i

Re: Wiki documentation update with respect to Gradle

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 a

Re: Wiki documentation update with respect to Gradle

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.

Re: Wiki documentation update with respect to Gradle

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 Gra

Re: Wiki documentation update with respect to Gradle

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.r...@les7arts.com> wrote: > Hi Taher, > > I'd not

Re: Wiki documentation update with respect to Gradle

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 re

Re: Wiki documentation update with respect to Gradle

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 whi

Re: Wiki documentation update with respect to Gradle

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

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 pa

Re: svn commit: r1756888 [1/2] - in /ofbiz/branches/release13.07: ./ framework/images/webapp/images/fieldlookup.js framework/images/webapp/images/selectall.js tools/security/dependency-check/dependenc

Mmm, the dependency-check-report.html inadvertently slipped in, I let it like that not a big deal: WIP... Le 19/08/2016 à 10:51, jler...@apache.org a écrit : Author: jleroux Date: Fri Aug 19 08:51:11 2016 New Revision: 1756888 URL: http://svn.apache.org/viewvc?rev=1756888&view=rev Log: "Appli