/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ /* * This file is part of the LibreOffice project. * * This Source Code Form is subject to the terms of the Mozilla Public * License, v. 2.0. If a copy of the MPL was not distributed with this * file, You can obtain one at http://mozilla.org/MPL/2.0/. * * This file incorporates work covered by the following license notice: * * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed * with this work for additional information regarding copyright * ownership. The ASF licenses this file to you under the Apache * License, Version 2.0 (the "License"); you may not use this file * except in compliance with the License. You may obtain a copy of * the License at http://www.apache.org/licenses/LICENSE-2.0 . */ #ifndef INCLUDED_SC_INC_UNOREFLIST_HXX #define INCLUDED_SC_INC_UNOREFLIST_HXX #include #include #include "rangelst.hxx" struct ScUnoRefEntry { sal_Int64 nObjectId; ScRangeList aRanges; ScUnoRefEntry( sal_Int64 nId, const ScRangeList& rOldRanges ) : nObjectId( nId ), aRanges( rOldRanges ) { } }; /** List of RefUpdate changes made to UNO objects during ScUpdateRefHint broadcast. */ class ScUnoRefList { private: ::std::vector aEntries; public: ScUnoRefList(); ~ScUnoRefList(); void Add( sal_Int64 nId, const ScRangeList& rOldRanges ); void Undo( ScDocument* pDoc ); bool IsEmpty() const { return aEntries.empty(); } }; /** Hint to restore a UNO object to its old state (used during undo). */ class ScUnoRefUndoHint : public SfxHint { ScUnoRefEntry aEntry; public: ScUnoRefUndoHint( const ScUnoRefEntry& rRefEntry ); virtual ~ScUnoRefUndoHint() override; sal_Int64 GetObjectId() const { return aEntry.nObjectId; } const ScRangeList& GetRanges() const { return aEntry.aRanges; } }; #endif /* vim:set shiftwidth=4 softtabstop=4 expandtab: */ o/core/commit/?id=ae855bf48163ff64d94cfc34aff8e37abdb5518d'/> ae855bf48163ff64d94cfc34aff8e37abdb5518d 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> 
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>