Peer-to-peer sharing in integrated development environment

The illustrative embodiments herein provide a computer implemented method for verifying code within an integrated development environment. A first data processing system identifies a code dependency within a first artifact located thereon. The code dependency depends on the second artifact located at the separate node of peer-to-peer network. Responsive to identifying the dependency within the first artifact, the first data processing system identifies a second data processing system within a peer-to-peer network that contains the second artifact. The first data processing system requests permission from the second data processing system to access the second artifact. Responsive to receiving permission to access the second artifact, the first data processing system accesses the second artifact on the second data processing system. The first data processing system then verifies a compatibility of the second artifact with the code dependency within the first artifact.

BACKGROUND

The disclosure relates generally to a computer implemented method, a computer program product, and a data processing system. More specifically, the disclosure relates to a computer implemented method, a computer program product, and a data processing system for peer-to-peer sharing in an integrated development environment.

2. Description of the Related Art

Software development is becoming increasingly complex and sophisticated. In addition, as computers and embedded controllers are increasingly used in products that were traditionally not computer-based, software development has become an important task for new types of products and new types of manufacturers. For example, in the automotive and electronics industries, software is quickly becoming a major piece of the overall deliverable products. Moreover, the increasing complexity and integration into other products has required greater collaboration between parties, e.g., original equipment manufacturers (OEM's) and suppliers.

Typically, OEM's and suppliers each have their own unique software development environments that are used to develop, test and track problems with deliverable software. In many cases, some of these parties are not particularly well equipped to handle software development, particularly if such parties predominantly provide manufacturing or design of products where software is only a small part of the overall design.

In many situations, it is desirable to allow multiple parties working on a common project to share information between their respective software development environments.

SUMMARY

According to one embodiment of the present invention, a computer implemented method verifies code within an integrated development environment. A first data processing system identifies a code dependency within a first artifact located thereon. The code dependency depends on the second artifact. Responsive to identifying the dependency within the first artifact, the first data processing system identifies a second data processing system within a network that contains the second artifact. The first data processing system requests permission from the second data processing system to access the second artifact. Responsive to receiving permission to access the second artifact, the first data processing system accesses the second artifact on the second data processing system. The first data processing system then verifies a compatibility of the second artifact with the code dependency within the first artifact.

DETAILED DESCRIPTION

Note that the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.

With reference now to the figures and in particular with reference toFIG. 1, an illustrative diagram of a data processing environment is provided in which illustrative embodiments may be implemented. It should be appreciated thatFIG. 1are only provided as an illustration of one implementation and is not intended to imply any limitation with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made.

In the depicted example, server computer104and server computer106connect to network102along with storage unit108. In addition, client computers110,112, and114connect to network102. Client computers110,112, and114may be, for example, personal computers or network computers. In the depicted example, server computer104provides information, such as boot files, operating system images, and applications to client computers110,112, and114. Client computers110,112, and114are clients to server computer104in this example. Network data processing system100may include additional server computers, client computers, and other devices not shown.

Program code located in network data processing system100may be stored on a computer recordable storage medium and downloaded to a data processing system or other device for use. For example, program code may be stored on a computer recordable storage medium on server computer104and downloaded to client computer110over network102for use on client computer110.

Turning now toFIG. 2, an illustration of a data processing system is depicted in accordance with an advantageous embodiment. In this illustrative example, data processing system200includes communications fabric202, which provides communications between processor unit204, memory206, persistent storage208, communications unit210, input/output (I/O) unit212, and display214.

Memory206and persistent storage208are examples of storage devices216. A storage device is any piece of hardware that is capable of storing information, such as, for example, without limitation, data, program code in functional form, and/or other suitable information either on a temporary basis and/or a permanent basis. Storage devices216may also be referred to as computer readable storage devices in these examples. Memory206, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage208may take various forms, depending on the particular implementation.

For example, persistent storage208may contain one or more components or devices. For example, persistent storage208may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage208also may be removable. For example, a removable hard drive may be used for persistent storage208.

Input/output unit212allows for input and output of data with other devices that may be connected to data processing system200. For example, input/output unit212may provide a connection for user input through a keyboard, a mouse, and/or some other suitable input device. Further, input/output unit212may send output to a printer. Display214provides a mechanism to display information to a user.

These instructions are referred to as program code, computer usable program code, or computer readable program code that may be read and executed by a processor in processor unit204. The program code in the different embodiments may be embodied on different physical or computer readable storage media, such as memory206or persistent storage208.

Program code218is located in a functional form on computer readable media220that is selectively removable and may be loaded onto or transferred to data processing system200for execution by processor unit204. Program code218and computer readable media220form computer program product222in these examples. In one example, computer readable media220may be computer readable storage media224or computer readable signal media226. Computer readable storage media224may include, for example, an optical or magnetic disk that is inserted or placed into a drive or other device that is part of persistent storage208for transfer onto a storage device, such as a hard drive, that is part of persistent storage208. Computer readable storage media224also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory, that is connected to data processing system200. In some instances, computer readable storage media224may not be removable from data processing system200. In these illustrative examples, computer readable storage media224is a non-transitory computer readable storage medium.

Alternatively, program code218may be transferred to data processing system200using computer readable signal media226. Computer readable signal media226may be, for example, a propagated data signal containing program code218. For example, computer readable signal media226may be an electromagnetic signal, an optical signal, and/or any other suitable type of signal. These signals may be transmitted over communication links, such as wireless communication links, optical fiber cable, coaxial cable, a wire, and/or any other suitable type of communications link. In other words, the communications link and/or the connection may be physical or wireless in the illustrative examples.

In still another illustrative example, processor unit204may be implemented using a combination of processors found in computers and hardware units. Processor unit404may have a number of hardware units and a number of processors that are configured to run program code218. With this depicted example, some of the processes may be implemented in the number of hardware units, while other processes may be implemented in the number of processors.

As another example, a storage device in data processing system200is any hardware apparatus that may store data. Memory206, persistent storage208, and computer readable media220are examples of storage devices in a tangible form.

The illustrative embodiments described herein provide a computer implemented method for verifying code within an integrated development environment. A first data processing system identifies a code dependency within a first artifact located thereon. The code dependency depends on the second artifact. Responsive to identifying the dependency within the first artifact, the first data processing system identifies a second data processing system within a network that contains the second artifact. The first data processing system requests permission from the second data processing system to access the second artifact. Responsive to receiving permission to access the second artifact, the first data processing system accesses the second artifact on the second data processing system. The first data processing system then verifies a compatibility of the second artifact with the code dependency within the first artifact.

Referring now toFIG. 3, a peer-to-peer (P2P) collaborative development system is shown, according to an illustrative embodiment. P2P collaborative development system300can be implemented as a virtual topology superimposed on the existing network infrastructure, such as network data processing system100ofFIG. 1. P2P collaborative development system300is a peer-to-peer overlay network in which all participants (always at edge of Internet) have identical responsibilities, and organize them into a network in an ad hoc manner.

Server310is a server such as server computer104or server computer106ofFIG. 1. Server310contains current build312. Current build312is a software application resulting from the compilation of several software artifacts that are themselves compiled from separate software components.

Server310includes source code repository311. Source code repository311is a storage device where large amounts of source code are kept, either publicly or privately. They are often used by multi-developer projects to handle various versions and developers submitting various patches of code in an organized fashion. Source code repository311can be, for example, but not limited to, memory206, persistent storage208, and computer readable media220ofFIG. 2.

Current build312is compiled from live components, such as live components314-320. Each of live components314-320is a piece of software designed to work as a component of a larger and generally more complex application, such as current build312.

Data processing systems322-328are data processing systems such as one of server computers104, and106, or client computers110,112, and114ofFIG. 1. Each of data processing systems322-328executes an integrated development environment, such as one of integrated development environments330-336. Each of integrated development environments330-336is a software application that provides comprehensive facilities to software developers338-344for development of software components346-352. Integrated development environments330-336may consist of, for example, but not limited to, a source code editor, a compiler, an interpreter, build automation tools, and a debugger. Software developers338-344utilize respective ones of integrated development environments330-336to create and make changes to software components346-352.

Software components346-352are individual components of a software build that have not been incorporated into current build312. In a collaborative software development environment, such as P2P collaborative development system300, each of software developers338-344is responsible for building specific components of the overall build. For example, in P2P collaborative development system300, software developer338is responsible for software component346. Software developer340is responsible for software component348. Software developer342is responsible for software component350. Software developer344is responsible for software component352. Software developers338-344utilize respective ones of integrated development environments330-336to create and make changes to software components346-352.

When software components346-352are finalized by software developers338-344, software components346-352are incorporated into current build312. Once compiled into current build312, software components346-352become live components314-320. In that sense, prior to compilation into current build312, each of live components314-320was previously one of software components346-352. Therefore, live components314-320are earlier iterations of software components346-352.

Prior to compiling software components346-352into current build312, each of software developers338-344independently confirms the stability, operability, and dependencies of software components346-352. In order to confirm software components346-352, software developers338-344utilize integrated development environments330-336in order to create artifacts354-360. Each of artifacts354-360is a compiled version of a corresponding one of software components346-352. That is, artifact354is a compiled version of software component346, but does not include code, compiled or otherwise, for software components348-352. Artifact356is a compiled version of software component348, but does not include code, compiled or otherwise, for software components346, and350-352. Artifact358is a compiled version of software component350, but does not include code, compiled or otherwise, for software components346-348, and352. Artifact360is a compiled version of software component352, but does not include code, compiled or otherwise, for software components346-350.

In one illustrative embodiment, ones of artifacts354-360may have code dependencies that require data from others of artifacts354-360. A code dependency is a section of code that requires data or input from another section of code in order to finish a dependent task or process. An artifact, such as ones of artifacts354-360, having a code dependency is able to access other ones of artifacts354-360across network362in order to verify the dependency of the dependent artifact with the other ones of artifacts354-360.

An integrated development environment executing an artifact having dependencies, such as one of integrated development environments330-336, does not pull or download other artifacts or software components into its own development environment. Rather, one integrated development environment, such as one of integrated development environments330-336, will communicate with others of integrated development environment330-336, and resolve any constraints of the dependent code without transferring the actual artifacts or software components between the separate integrated development environments.

While code dependencies between components are typically more common, the illustrative embodiments can be used to resolve other dependencies of the artifacts as well. For example, an artifact, such as ones of artifacts354-360may have dependencies not only on code, but also on actual integrated development environment settings in the other peer-to-peer node machine, such as the settings of one of integrated development environments330-336.

For example, a software developer338is unit testing the code and cannot reproduce the problem identified by software developer340. Software developer338therefore wants to make sure that integrated development environments330is set up in exactly the same way as integrated development environments332of software developer340. In this scenario, integrated development environments330communicates with integrated development environments332to pull integrated development environment settings from integrated development environments330to integrated development environments332.

Referring now toFIG. 4, a data flow for testing software components within a peer-to-peer (P2P) collaborative development system is shown, according to an illustrative embodiment. P2P collaborative development system400can be, for example, P2P collaborative development system300ofFIG. 3.

Data processing system410is a data processing system such as one of data processing systems322-328ofFIG. 3. Data processing system410executes integrated development environment412. Integrated development environment412is an integrated development environment such as one of integrated development environments330-336ofFIG. 3.

Software developer414uses integrated development environment412to create artifact416. Artifact416is an artifact such as one of artifacts354-360. Artifact416contains code dependency418. Code dependency418is a section of code that requires data or input from another section of code in order to finish a dependent task or process. Code dependency418depends on artifact416in order to finish a task or process of artifact416.

Artifact420is located on data processing system422. Artifact420is an artifact such as one of artifacts354-360. Data processing system422is a data processing system such as one of data processing systems322-328ofFIG. 3. Code dependency418of artifact416depends on artifact420in order to finish a task or process of artifact416.

Integrated development environment412identifies that code dependency418depends on artifact420. Integrated development environment412therefore locates artifact420across P2P network424, within P2P collaborative development system400. Integrated development environment412does not identify every artifact or software components that are located across P2P network424. Instead, integrated development environment412identifies which artifact or software components are dependencies of artifact416. Integrated development environment412locates only those artifact or software components upon which artifact416depends.

Software developer414interacts with integrated development environment412through user interface426. User interface426is a software component that allows software developer414to interact with integrated development environment412.

Software developer428interacts with integrated development environment430of data processing system422through user interface432. User interface432is a software component that allows software developer414to interact with integrated development environment412. User interface432includes access control434.

Access control434is a software component that controls what other software developers, data processing systems, artifacts, and software components may access artifacts located on data processing system422, such as artifact420. In one illustrative embodiment, access control434is implemented as a component of integrated development environment430.

Access control434sets access restrictions436. Access restrictions436is a data structure that contains permissions of what other software developers, data processing systems, artifacts, and software components may access artifacts located on data processing system422, such as artifact420.

Integrated development environment412locates artifact420required by code dependency418. Integrated development environment412then sends read request438to integrated development environment430for access to artifact420. Read request438includes indication440. Indication440is an indication that at least one of integrated development environment412, software developer414, data processing system410is the source of read request438. Indication440may also include, for example, data processing system classification information such as an indication of a development system, and an indication of a testing system. Indication440may also include, for example, user classification information such as an indication of a developer of artifact416, a tester of artifact416, and an owner of artifact416. In response to receiving read request438, integrated development environment430identifies whether one of integrated development environment412, software developer414, data processing system410has been granted read access of artifact420. To identify whether one has been granted read access, integrated development environment430compares indication440of read request438to the permissions granted within access restrictions436. If indication440of read request438matches one of the permissions within access restrictions436, integrated development environment430grants integrated development environment412access to artifact420.

In one illustrative embodiment, if indication440of read request438does not match one of the permissions within access restrictions436, integrated development environment430does not immediately grant integrated development environment412access to artifact420. Instead, integrated development environment430presents the access request to software developer428. Software developer428can then decide whether access should be granted. If software developer428eventually allows access to artifact420, integrated development environment430can then send access response440to integrated development environment412, notifying that access to artifact420has been granted to integrated development environment412.

Once integrated development environment412is granted access to artifact420, integrated development environment430sends access response442to integrated development environment412. Access response442informs integrated development environment412whether access has been granted to artifact420. Integrated development environment412can verify the compatibility of code dependency418with artifact420.

Referring now toFIG. 5, a flowchart illustrating the processing steps for accessing a dependency artifact within a P2P collaborative development system is shown according to an illustrative embodiment. Process500is a software process, executing on a software component, such as integrated development environment412ofFIG. 4.

Process begins by identifying compiling a software component into an artifact (step510). The software component can be, for example, one of software components346-352ofFIG. 3.

Process500then identifies whether any code dependencies exist within the artifact (step520). The code dependencies can be, for example, code dependency418ofFIG. 4. If the artifact does not contain any code dependencies (“no” at step520), the process terminates.

Returning now to step520, responsive to determining that the process contains at least one code dependency (“yes” at step520), process520identifies the peer computer containing the artifact depended upon (step540). The peer computer can be, for example, data processing system422ofFIG. 4.

Responsive to identifying the peer computer containing the artifact depended upon, process500sends a read request to the peer computer (step550). The read request can be, for example, read request438ofFIG. 4. The read request contains an indication as to the source of the request, such as indication440ofFIG. 4.

Process500then determines whether access to the artifact depended upon is granted by the peer computer (step560). Responsive to determining that access to the artifact depended upon is granted by the peer computer (“yes” at step560), process500verify the artifact and its compatibility of code dependency with the artifact depended upon (step570).

Once the artifact and any code dependencies therein have been verified (“yes” at step570), process500terminates.

Returning now to step570, responsive to the artifact and any code dependencies therein not being verified (“no” at step570), process500informs a software developer of any identified errors within the software component or the artifact (step580), with the process terminating thereafter. The software developer can then use the identified errors to make changes to software component or the artifact prior to forwarding the software component for compilation into a current build as a live component.

Returning now to step560, responsive to determining that access to the artifact depended upon is not granted by the peer computer (“no” at step560), process500informs the software developer that access to the requested artifact has not been granted (step590). Process500terminates thereafter.

Referring now toFIG. 6, a process for granting access to software components and artifacts within a P2P collaborative development system is shown according to an illustrative embodiment. Process600is a software process, executing on a software component, such as integrated development environment430ofFIG. 4.

Process600begins by receiving a read request from an integrated development environment (step610). The read request can be, for example, read request438ofFIG. 4. The integrated development environment can be, for example, integrated development environment412ofFIG. 4. The read request contains an indication as to the source of the request, such as indication440ofFIG. 4.

Responsive to receiving the read request, process600identifies whether access has been granted to a requested artifact (step620). The indication may indicate at least one of an integrated development environment, a software developer, and a data processing system. To identify whether one has been granted read access, process600compares the indication of the read request to the permissions granted within access restriction data structure, such as for example access restrictions436ofFIG. 4.

If the indication of the read request matches one of the permissions within the access restrictions data structure (“yes” at step620), process600grants the requesting integrated development environment access to the requested artifact (step630), with the process terminating thereafter.

However, if the indication of the read request does not match one of the permissions within the access restrictions data structure (“no” at step620), process600presents the read request to a software developer (step640). The software developer can be, for example, software developer428ofFIG. 4. Process400then polls for a response from the software developer to determine whether access to the requested artifact is allowed (step650). The software developer can then decide whether access should be granted.

Responsive to receiving notice that the software developer grants access to artifact (“yes” at step650), process can send an access response to requesting integrated development environment, notifying that access to artifact has been granted (step660). Process600then updates the access restrictions data structure to indicate that access has been granted to the requested artifact (step670). The access restrictions data structure can be updated to include an indication of at least one of the integrated development environment, a software developer, and a data processing system that has been granted access, as well as the specific artifact or test code that access has been granted to. Process600then grants the requesting integrated development environment access to the requested artifact (step630), with the process terminating thereafter.

Returning now to step650, responsive to receiving notice that the software developer does not grant access to artifact (“no” at step650), process can send an access response to requesting integrated development environment, notifying that access to artifact has not been granted (step680). Process600terminates thereafter.

Thus, the illustrative embodiments described herein provide a computer implemented method for verifying code within an integrated development environment. A first data processing system identifies a code dependency within a first artifact located thereon. The code dependency depends on the second artifact. Responsive to identifying the dependency within the first artifact, the first data processing system identifies a second data processing system within a network that contains the second artifact. The first data processing system requests permission from the second data processing system to access the second artifact. Responsive to receiving permission to access the second artifact, the first data processing system accesses the second artifact on the second data processing system. The first data processing system then verifies a compatibility of the second artifact with the code dependency within the first artifact.