1. 04 Agu, 2018 1 kayıt (commit)
  2. 30 Tem, 2018 1 kayıt (commit)
    • Gabor Kelemen's avatar
      Add missing sal/log.hxx headers · efdc775d
      Gabor Kelemen yazdı
      rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx> (and don't make use of it themselves), but many other files happen to depend on it.
      This is a continuation of commit 6ff2d84a to be able to remove those unneeded includes.
      
      This commit adds missing headers to every file found by:
      grep -FwL sal/log.hxx $(git grep -Elw 'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF|SAL_DETAIL_LOG_STREAM|SAL_WHERE|SAL_STREAM|SAL_DEBUG')
      to directories scripting, sd, sdext
      
      Change-Id: I47889cd889cf1d68353184229bfd4712f1528fbf
      Reviewed-on: https://gerrit.libreoffice.org/58220
      Tested-by: Jenkins
      Reviewed-by: 's avatarMiklos Vajna <vmiklos@collabora.co.uk>
      efdc775d
  3. 05 Tem, 2018 1 kayıt (commit)
  4. 15 Haz, 2018 2 kayıt (commit)
    • Stephan Bergmann's avatar
      Restore binary compatibility for ClassLoaderFactory · 1b897f16
      Stephan Bergmann yazdı
      As discussed in the mail thread starting at <http://mail-archives.apache.org/
      mod_mbox/openoffice-dev/201806.mbox/%3c651c8fee-b467-421c-eae1-a8710f41692c
      @apache.org%3e> "Just a little side note on the scripting framework ...",
      external code that uses the Java class
      com.sun.star.script.framework.provider.ClassLoaderFactory stopped working
      because LO changed that class in binary (and compile-time) incompatible ways
      over time.
      
      The class is not listed at
      <https://api.libreoffice.org/docs/java/ref/index.html> (and neither at
      <http://www.openoffice.org/api/docs/java/ref/overview-summary.html>), so it was
      not considered part of the stable URE interface.  But it is apparently used by
      external code, and it indeed seems to make sense that it is used by external
      code that implements scripting providers.  (A follow-up commit should therefore
      mark the class as part of the stable URE interface.  I keep that separate so
      that it is easier to backport this functional fix.)
      
      With ScriptProviderForooRexx.oxt from
      https://svn.code.sf.net/p/bsf4oorexx/code@r589 installed in LO, "Tools - Macros
      - Organize Macros - ooRexx... - My Macros - Create... - Library1 - OK -
      Create... - Macro1 - OK - Edit" failed due to
      
      > warn:cui.dialogs:21768:21768:cui/source/dialogs/scriptdlg.cxx:740: Caught exception trying to invoke N3com3sun4star3uno9ExceptionE msg: [jni_uno bridge error] UNO calling Java method invoke: non-UNO exception occurred: java.lang.NoSuchMethodError: com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader(Lcom/sun/star/script/framework/container/ScriptMetaData;)Ljava/lang/ClassLoader;
      > java stack trace:
      > java.lang.NoSuchMethodError: com.sun.star.script.framework.provider.ClassLoaderFactory.getURLClassLoader(Lcom/sun/star/script/framework/container/ScriptMetaData;)Ljava/lang/ClassLoader;
      > 	at com.sun.star.script.framework.provider.oorexx.ScriptEditorForooRexx.edit(ScriptEditorForooRexx.java:305)
      > 	at com.sun.star.script.framework.browse.ScriptBrowseNode.invoke(ScriptBrowseNode.java:200)
      
      cae57d2e "ClassLoader->URLClassLoader" (which
      this commit reverts) had changed the return type of the two getURLClassLoader
      overloads from ClassLoader to derived URLClassLoader (and ultimately only for
      cosmetic effect; it was leftover from a previous attempt at fixing a Coverity
      issue by using URLClassLoader.close(), but which is only available in Java 1.7,
      so the attempt had been reverted).  That caused the above failure.
      
      And 68cd011c "java: reduce scope, make some
      methods private" (which this commit also reverts) had changed the second
      getURLClassLoader overload (which is not called in the above scenario) from
      public to private, which is also a binary-incompatible change.
      
      Other commits removed throws clauses, which is only a compile-time issue but not
      a binary-incompatible change.  I left those changes in for now, but if need be
      they could also be reverted.
      
      Change-Id: I98f533d88c7c1580956c3c281e72a1c78fa3f56f
      Reviewed-on: https://gerrit.libreoffice.org/55871
      Tested-by: Jenkins
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      1b897f16
    • Arkadiy Illarionov's avatar
      tdf#96099 Remove some trivial std::vector iterator typedefs · 17745994
      Arkadiy Illarionov yazdı
      Change-Id: Iced10ed59c475dff4d33ff06151b2015a27a860b
      Reviewed-on: https://gerrit.libreoffice.org/55715
      Tested-by: Jenkins
      Reviewed-by: 's avatarTor Lillqvist <tml@collabora.com>
      17745994
  5. 12 Haz, 2018 1 kayıt (commit)
  6. 25 May, 2018 1 kayıt (commit)
  7. 09 May, 2018 1 kayıt (commit)
  8. 05 May, 2018 1 kayıt (commit)
  9. 04 May, 2018 1 kayıt (commit)
  10. 27 Nis, 2018 1 kayıt (commit)
  11. 24 Nis, 2018 2 kayıt (commit)
  12. 15 Nis, 2018 2 kayıt (commit)
  13. 03 Nis, 2018 1 kayıt (commit)
  14. 02 Nis, 2018 1 kayıt (commit)
  15. 28 Mar, 2018 5 kayıt (commit)
  16. 27 Mar, 2018 4 kayıt (commit)
  17. 22 Şub, 2018 1 kayıt (commit)
  18. 30 Ock, 2018 1 kayıt (commit)
    • Justin Luth's avatar
      tdf#63388: use SMTP_SSL for port 465 · 036b51db
      Justin Luth yazdı
      Thanks to Jurassic Pork and prrychr (tdf#99363) for the 2016 patch.
      I used smtp.gmail.com as my testing server.
      
      Port 587 is the "official" port to use for encrypted email.
      I confirmed that 587 CANNOT use SMTP_SSL [SSL: UNKNOWN_PROTOCOL],
      so I limited SMTP_SSL use to common TLS port 465 only.
      
      Port 465 was temporarily recommended, but OFFICIALLY has long
      since been abandoned. However, LOTS of documentation and ISPs still
      recommend it as the port to use. I confirmed that 465 DOES NOT
      support STARTTLS, so it is specifically excluded.
      
      So, technically the button should say use STARTTLS instead of SSL,
      but only for SMTP. IMAP/POP do use SSL, so terminology gets
      rather confusing. This patch forces SSL without STARTTLS for port 465
      regardless of the "use SSL" setting due to all the confusion.
      
      Currently we don't support ANY SSL/TLS connections. With this patch
      we now at least support the extremely common use case of port 465.
      
      Change-Id: I210cc307491157c1121cfffd70cbb94347ee2856
      Reviewed-on: https://gerrit.libreoffice.org/48210Tested-by: 's avatarJenkins <ci@libreoffice.org>
      Reviewed-by: 's avatarJustin Luth <justin_luth@sil.org>
      036b51db
  19. 27 Ock, 2018 1 kayıt (commit)
  20. 24 Ock, 2018 1 kayıt (commit)
  21. 12 Ock, 2018 1 kayıt (commit)
  22. 10 Ock, 2018 1 kayıt (commit)
  23. 02 Ock, 2018 1 kayıt (commit)
  24. 11 Ara, 2017 1 kayıt (commit)
  25. 05 Ara, 2017 1 kayıt (commit)
  26. 30 Kas, 2017 1 kayıt (commit)
  27. 13 Kas, 2017 1 kayıt (commit)
  28. 06 Kas, 2017 1 kayıt (commit)
  29. 23 Eki, 2017 2 kayıt (commit)