Method and system to determine component deprecation

A method and system of marking the deprecation status of components, such as services, processes, operations, and data types that may be used in a computing application, and displaying this status to developers within the computing application is provided. Components may be marked as deprecated, or they may include information reflecting a sunset policy, which consists of either a specific date or an upcoming version number of the application or programming language the computing application supports. The sunset policy determines when a component has reached its end of life and is either no longer supported or will be removed from the underlying product. Using this deprecation status information, the computing application may be configured to dynamically notify developers of when components will be deprecated. The computing application may further be configured to provide automated migration support by recommending alternative components and assisting in their configurations.

TECHNICAL FIELD

This disclosure relates generally to the technical field of interactive software development environments and, in one example embodiment, to a method and system to determine component deprecation in a computer application.

BACKGROUND

Today's enterprise-level programming environments offer access to thousands of libraries, classes, and services that are regularly updated, replaced, and deprecated. In computer software standards and documentation, the term deprecated is applied to software features that are superseded and should be avoided. Currently, these environments contain limited means to notify developers that they are using deprecated services, which makes the transition to a new version of an application programming interface (API) error prone and difficult. It is also unclear to users how long a deprecated service will remain supported and whether it can safely be used.

In the Java™ programming language, identifying deprecated classes requires a developer to read the Javadoc™ documentation. The maintainer of the class library must also manually update the documentation in order to communicate to the developers whenever a class is deprecated. The developer of a computing application must then perform any required changes manually if functionality being used in the application may no longer be available or compatible. This manual method also does not identify any information about when a class may be deprecated in the future or when a deprecated class will be removed altogether. Unless a developer learns from an outside source that a class is being deprecated, he or she may not learn of the deprecation until the day it happens in a version update.

DETAILED DESCRIPTION

A method and system of marking the deprecation status of components, such as services, processes, operations, and data types that may be used in a computer application, and displaying this status to developers within a computing application, such as an integrated development environment (IDE), is described. Components may be marked as deprecated, or they may include information reflecting a sunset policy, which consists of either a specific date or an upcoming version number of the application or programming language the computing application supports. The sunset policy determines when a component has reached its end of life and is either no longer supported or will be removed from the underlying product.

Using this deprecation status information, the computing application is able to dynamically notify developers if and when components will be deprecated within a computing application. This functionality allows deprecation data for components to be much more discoverable than searching through documentation, which makes updating and maintaining software easier for developers. The computing application can further provide automated software migration support by recommending alternative components and assisting in their configurations, for example, in order to ease transition between new product versions. Previous methods of showing deprecation only inform developers that they should no longer use a class or component and that it may be removed in the future.

An example computing application within which component deprecation may be determined is Adobe® LiveCycle® offered by Adobe Systems Incorporated (“LiveCycle®”). It will be noted that while embodiments of the deprecation system are described with reference to LiveCycle®, a deprecation manager may be utilized advantageously to manage deprecation information within any IDE or computing application with similar functionality. As one example implementation of determining component deprecation, the deprecation manager receives deprecation data, configures the component with the deprecation data, and stores the component in a format suitable for generating a visual representation of the component utilizing the deprecation data.

FIG. 1is a block diagram showing a network environment100within which a method and system to determine component deprecation may be implemented, in accordance with an example embodiment. The network environment100includes a client machine110which executes a computing application112(e.g., an IDE). In an example embodiment, the computing application112runs directly on the client machine110. In other embodiments, the computing application112may run on a remote server, and the client machine110may act as a thin client that receives input from a user and displays the application to the user, such as in a software as a service (SaaS) or cloud computing environment. The computing application112contains a deprecation manager114that determines and displays component deprecation information to a user. This deprecation information is stored along with its associated components in a component database116.

The client machine110, in an example embodiment, is connected to a server machine102via a network108. The network108may be a public network (e.g., the Internet, a wireless network, a public switched telephone network (PSTN), etc.) or a private network (e.g., a local area network, a wide area network, an intranet, etc.). The server machine102includes management applications104that interact with the computing application112and the deprecation manager114. For example, the management applications104may keep the deprecation information stored locally on the client machine110up to date if there are changes made by the server machine102or another master system on the network108. In an example embodiment, the server machine102also connects to a component repository106that holds a master set of components that may be accessed by the computing application112on the client machine110. AlthoughFIG. 1illustrates the client machine110as part of a networked environment100, other example embodiments include the ability for the client machine110to operate in a stand-alone environment without a network connection. In these cases, the computing application112only has access to locally stored components and deprecation information.

FIG. 2is a block diagram illustrating a system to determine component deprecation, in accordance with an example embodiment. Specifically,FIG. 2shows the modules of the deprecation manager114, which operates as part of the computing application112. The deprecation manager114includes a deprecation interface module202to receive deprecation data related to a component within the computing application from a user. The deprecation manager114also includes a component configuration module204to configure the component with the deprecation data and a storage module206to store the component in the component database116(shown inFIG. 1) or to send the component to the component repository106(shown inFIG. 1). The storage module206is configured to store the component in a format suitable for generating a visual representation of the component utilizing the deprecation data. The deprecation manager114further includes a selection interface module208to receive a selection request associated with the component from the user and a display module210to display the visual representation of the component to the user in response to the selection request. The visual representation of the component indicates to the user whether the component is deprecated or may display other deprecation data, such as a sunset date or a replacement component.

To manage replacement components, the deprecation manager114includes a replacement component identification module214to identify a replacement component associated with the deprecation data and a replacement component interface module216to receive replacement configuration data associated with the replacement component from a user. The deprecation manager114also includes a replacement component configuration module218to configure the replacement component with the replacement configuration data and a process template module212to update a process template by replacing the component with the replacement component.

Various operations performed by the deprecation manager114, according to an example embodiment, are discussed with reference toFIG. 3.

FIG. 3is a flow chart illustrating a method300to determine component deprecation, in accordance with an example embodiment. The method300may be performed by processing logic that may comprise hardware (e.g., dedicated logic, programmable logic, microcode, etc.), software (such as run on a general purpose computer system programmed to perform particular functions pursuant to instructions from program software or on a dedicated machine), or a combination of both. The processing logic, according to example embodiments, may reside in any of the modules shown inFIG. 2, which may be implemented as software, hardware, or a combination of both.

As shown inFIG. 3, the method300to determine component deprecation commences with operation302, where the deprecation manager114receives deprecation data. This deprecation data, in one example embodiment, is entered by a user through a user interface, either within the computing application112or through a separate tool. The deprecation data may also be received from the server machine102across the network108, or may be loaded from a file on the client machine110updated through other means, such as an extensible markup language (XML) editor. At operation304, the component configuration module204configures the component with the received deprecation data by modifying its attributes. In one example embodiment, these attributes are stored in a component XML file (shown in more detail inFIG. 7). At operation306, the storage module206stores the configured component in the component database116or, in another example embodiment, transmits the component to the server machine102to be stored in the component repository106. Various operations performed by modules illustrated inFIG. 2in order to display deprecated components may be discussed with reference toFIG. 4.

As shown inFIG. 4, a method400to display deprecated components and optionally replace the deprecated components with replacement components commences at operation402, where the selection interface module208of the deprecation manager114receives a selection request from a developer associated with a deprecated component (which may be done through the user interfaces shown inFIGS. 5 and 6). At operation404, the display module210displays a visual representation of the deprecated component (shown in more detail inFIG. 5). This visual representation may contain a warning to the developer of a sunset policy, which indicates that the chosen component is deprecated and may not be available at a later date. Depending on the time until the component is removed from the computing application112entirely, known as the sunset date, this warning may change in severity. For example, if a chosen application programming interface (API) is expected to be removed in a certain version (e.g., version 11.1) of the computing application112, the display module210may provide an explicit warning to the developer in a preceding version (e.g., version 10.0). In version 11.0, the display module210may switch the warning to an error informing the developer to remove the deprecated component entirely. The sunset policy may be based on an application version number, date, or other indication. Dates and version numbers for the sunset policy may be chosen by the author or maintainer of the application, then the deprecation manager114may create the sunset policy and associate it with the component.

If the developer chooses to replace the deprecated component at decision406, the replacement component identification module214identifies a replacement component at operation410. In an example embodiment, replacement components are listed as an attribute in the component XML. Generally, a replacement component will provide at least the same functionality as the component it is replacing, plus additional features. However, the replacement component may require additional configuration in order to utilize the additional features or to be compatible with the base functionality. For example, deprecated component A may have two string data types and an integer, but the component which replaces it, component B, may require two strings and two integers. Therefore, in order to replace component A with component B, component B needs an additional value for its extra integer data type.

The replacement component interface module216receives configuration data for the replacement component (if necessary from the user, or it may be automatically filled in an example embodiment) at operation412. This replacement configuration data, in one example embodiment, is solicited from the developer by the computing application112. The replacement component interface module216may display an interface that fills in known attributes and allows the developer to input values for the new attributes. In some instances, the replacement component configuration module218may be able to fill in default values or determine correct values for the replacement component attributes without prompting the developer. At operation414, the replacement component configuration module218configures the replacement component with the replacement configuration data, and at operation416, the process template module212updates a process template by replacing the deprecated component with the replacement component. The user interface is then updated to reflect the change. The method400terminates at end point408.

FIG. 5is a block diagram showing a process canvas500used in determining component deprecation, in accordance with an example embodiment. The process canvas500displays a process canvas with a number of activities and tasks. In the context of LiveCycle®, a process such as the one displayed in process canvas500is used to automate business processes, such as filling out paid time off forms. For example, an employee may fill out a form and submit the form to an automated process. The automated process queries an appropriate database to retrieve contact information, such as an email address, for the employee's manager, and then the process transmits the completed form to that manager. The illustrated process canvas allows a developer to design these business processes by combining activities in a process flow, and different variations on activities are possible with variables keyed on the activities. Furthermore, each of these activities can be deprecated and replaced with other activities.

The process canvas500example shown inFIG. 5includes a programmatic start point502which marks the beginning of execution on the canvas. The start new process arrow504indicates the starting point of a process, which has “activity0” block506as its first activity. Using the above example, activity0may control the form the employee fills out, such as presenting the correct form to the employee and receiving it after the employee has completed filling it out. After activity0is complete, the process assigns a task at block508, which is marked as deprecated to flag to the developer that the chosen task to be assigned is deprecated. This warning informs the developer than he or she may want to choose a replacement activity. The assign task2block510and activity1block512are also programmed to be performed after activity0is complete. Assign task2, for example, may involve the employee's manager reviewing the form, and activity1may be filing the form in a database or performing other indexing functions.

FIG. 6is a block diagram showing a user interface600that displays deprecated components, in accordance with an example embodiment. The user interface600displays an activity picker that a developer may use to choose activity components to be placed on the process canvas shown inFIG. 5. In an example embodiment, the activity includes a name602, such as activity0and activity1, and a service operation604. The activity picker also includes a search field606to narrow down a list of possible activity templates608, which include service, operation, and description. The activity picker also provides functionality to allow the developer to choose whether to display deprecated operations. In one example embodiment, this functionality is achieved through a checkbox610. The developer may add the defined activity using the OK button612or may cancel by pressing the cancel button614.

FIG. 7is a block of XML700showing components marked as deprecated and components marked as not deprecated, in accordance with an example embodiment. The component XML file shown inFIG. 7is a descriptor file that provides the workflow engine information about the services and operations declared in a component. That is, a service with each name includes the listed operations, and the XML file provides information about each one. The component XML example shown inFIG. 7bootstraps different classes that get called over the lifecycle of a component and defines which classes needed to be imported and exported. The component XML file also defines any extra, optional attributes for components. Component XML files, in an example embodiment, are generated automatically by code, such as an XML generation tool.

The component XML file here defines a first service named “DeprecatedService”. The deprecation manager114that processes the component XML file may read that the deprecated status is set to true, and therefore “DeprecatedService” is deprecated in the current version of the computing application112. The “replaced-by” attribute indicates the name of a replacement service that may be suggested to a developer as an alternative to the deprecated service. In this example, the replacement service is simply named “replacement service.” The component XML also defines the sunset clause with the “sunsetting-on” attribute, which indicates a date, software version number, or other indication of when the service will no longer be included in the computing application112. In this component XML file, “DeprecatedService” will sunset in version 10.1 of the computing application112. Furthermore, the “deprecated-since” attribute includes an indication of when the service was first deprecated, in this case version 9.1.

The component XML file shown inFIG. 7further defines a deprecated operation and an undeprecated service with an undeprecated operation. Additionally, in an example embodiment, these attributes cascade. If a service is deprecated, all operations under the service are automatically marked as deprecated as well.

The example computer system800includes a microprocessor802(e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory804and a static memory806, which communicate with each other via a bus808. The computer system800may further include a video display unit810(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system800also includes an alphanumeric input device812(e.g., a keyboard), a user interface (UI) cursor control device814(e.g., a mouse), a disk drive unit816, a signal generation device818(e.g., a speaker) and a network interface device820.

The disk drive unit816includes a computer-readable (or machine-readable) medium822on which is stored one or more sets of instructions and data structures (e.g., software824) embodying or utilized by any one or more of the methodologies or functions described herein. The software824may also reside, completely or at least partially, within the main memory804and/or within the microprocessor802during execution thereof by the computer system800, the main memory804and the microprocessor802also constituting machine-readable media.

The software824may further be transmitted or received over a network826via the network interface device820utilizing any one of a number of well-known transfer protocols (e.g., Hyper Text Transfer Protocol (HTTP)).

Thus, a method and system to determine component deprecation been described. The method and system are proposed to store a visual representation of components of a computing application. While some example approaches described herein may be used with a suite of Adobe® products, the techniques described herein may be utilized beneficially with various programs for determining the deprecation status of components within a product or a suite of products.

The embodiments described herein may be implemented in an operating environment comprising software installed on a computer, in hardware, or in a combination of software and hardware. Although embodiments have been described with reference to specific example embodiments, it is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.