summaryrefslogtreecommitdiff
path: root/bean/Jar_officebean.mk
AgeCommit message (Collapse)AuthorFilesLines
2020-05-06Move all public Java classes to libreoffice.jarSamuel Mehrbrodt1-2/+1
This moves the classes from juh.jar and ridl.jar to libreoffice.jar The goal is to have one single jar (and Java module, will be added later) which developers can include to work with LO. juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar on its classpath to keep backwards compatibility. This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d and a preparation to have Java 9 module support. Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-04tdf#117331 Merge jurt and unoil into ridlSamuel Mehrbrodt1-2/+0
jurt.jar and unoil.jar are kept as effectively empty jars, each with a Class-Path: ridl.jar in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or without also loading ridl.jar) will still have access to their content. Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi) are not part of the URE, but are now made available by URE's ridl.jar. This should probably not cause problems in practice. At least for now, we seal exactly those packages in ridl.jar that were originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now, but that would be mildly incompatible, as it would prevent 3rd-party code from introducing additional UNOIDL entities in the relevant namespaces (even if that is something we do not want 3rd-party code to do anyway). However, some JunitTest_jurt_* define classes in those sealed packages. In the past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt. Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets leave that for a follow-up clean up.) As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/. Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2014-09-30[API CHANGE] OfficeBean: remove deprecated com.sun.star.beans classesStephan Bergmann1-8/+0
<https://wiki.openoffice.org/wiki/Documentation/DevGuide/JavaBean/The_Internal_Office_Bean_API>: "Prior to OpenOffice.org 2.0 all Office Bean classes were in the com.sun.star.bean package. As of OpenOffice.org 2.0 the classes are contained in the com.sun.star.comp.bean package. The classes of the com.sun.star.bean package are still contained in the officebean.jar but they are deprecated. Further development and bug fixing will occur only in the com.sun.star.comp.bean package." Change-Id: I9421bfba941d9801a5cf8886ca971275740d178a
2014-09-16Revert bean part of "java: remove dead methods"Stephan Bergmann1-0/+1
...34bcf9b498bccb5c924f4cec850ff15d88df6f07; bean is a client API, not dead code. Change-Id: Iea17b6306152b9a4f2968bed550a44917803d9ec
2014-08-13java: remove dead methodsNoel Grandin1-1/+0
found by UCDetector Change-Id: I219caa8e680dba5a395541a778df6144841c4dde
2013-04-30Move to MPLv2 license headers, with ESC decision and author's permission.Michael Meeks1-23/+4
2012-08-17gbuild: register all jarsMichael Stahl1-4/+4
Change-Id: I9f49970e5e06d1afd3fc066a20d1671c93e262fc
2012-04-08gbuild: "use" vs. "add":Michael Stahl1-1/+1
Naming convention for gbuild methods: - "add" is used for stuff that is logically a part of the target (i.e. not registered at the Module, but defined in the target's makefile) - "use" is used for stuff that is logically a different target (i.e. it is registered at the Module, has it's own makefile, may be in a different module than the target)
2011-10-23no need for SRCDIR parameter hereMatúš Kukan1-1/+1
2011-09-18convert bean to gbuild and add to tail_buildPeter Foley1-0/+69