Abstract: Arrangements described herein relate to managing versions of artifacts stored across disparate tools. In a multi-dimensional configuration space, dimensions can be defined. The dimensions can represent respective variations of respective versions of a plurality of artifacts for at least a first configuration of a system. Via the dimensions, versions of the plurality of artifacts can be mapped to at least a corresponding first configuration of the system, the mapped versions of the plurality of artifacts corresponding to the versions of the artifacts used in the first configuration. The first configuration can be identified by a point in the multi-dimensional configuration space defined by the respective dimensions. At least a first of the plurality of artifacts can be stored by a first tool, and at least a second of the plurality of artifacts can be stored by a second tool disparate from the first tool.

Abstract: Arrangements described herein relate to managing versions of artifacts stored across disparate tools. In a multi-dimensional configuration space, dimensions can be defined. The dimensions can represent respective variations of respective versions of a plurality of artifacts for at least a first configuration of a system. Via the dimensions, versions of the plurality of artifacts can be mapped to at least a corresponding first configuration of the system, the mapped versions of the plurality of artifacts corresponding to the versions of the artifacts used in the first configuration. The first configuration can be identified by a point in the multi-dimensional configuration space defined by the respective dimensions. At least a first of the plurality of artifacts can be stored by a first tool, and at least a second of the plurality of artifacts can be stored by a second tool disparate from the first tool.

Abstract: A data indexing system including a plurality of servers and a tracked resource set client is provided. Each of the servers includes a plurality of resources that are part of a resource set. Each of the servers also includes a tracked resource set corresponding to the resource set. The tracked resource set describes the plurality of resources located in the resource set. The server identifies the plurality of resources using rules of linked data. The tracked resource set client is in communication with the plurality of servers. The tracked resource set client has a data index. The data index is built and kept up to date using the tracked resource set of each of the plurality of servers.

Abstract: A data indexing system including a plurality of servers and a tracked resource set client is provided. Each of the servers includes a plurality of resources that are part of a resource set. Each of the servers also includes a tracked resource set corresponding to the resource set. The tracked resource set describes the plurality of resources located in the resource set. The server identifies the plurality of resources using rules of linked data. The tracked resource set client is in communication with the plurality of servers. The tracked resource set client has a data index. The data index is built and kept up to date using the tracked resource set of each of the plurality of servers.

Abstract: In the present solution, as set of SDLC resources can be established, where each is separately addressable through a unique URL and is able to be managed through a simple set of operations. For example, a set of RESTful operations (GET, POST, PUT, and DELETE) can be used for the operations. Database management technologies can be leveraged for storing and indexing resources, but the underlying database schema for the solution can operate on a resource level, which results in the resources being stored as-is. Thus, storage (even when database based) of resources for the solution can be considered an Internet server exposing a space of URL addressable objects. Because the solution leverages Internet technologies and standards, it is scalable, standards based, extensible, and traceable.

Abstract: Arrangements described herein relate to managing versions of artifacts stored across disparate tools. In a multi-dimensional configuration space, dimensions can be defined. The dimensions can represent respective variations of respective versions of a plurality of artifacts for at least a first configuration of a system. Via the dimensions, versions of the plurality of artifacts can be mapped to at least a corresponding first configuration of the system, the mapped versions of the plurality of artifacts corresponding to the versions of the artifacts used in the first configuration. The first configuration can be identified by a point in the multi-dimensional configuration space defined by the respective dimensions. At least a first of the plurality of artifacts can be stored by a first tool, and at least a second of the plurality of artifacts can be stored by a second tool disparate from the first tool.

Abstract: Arrangements described herein relate to managing versions of artifacts stored across disparate tools. In a multi-dimensional configuration space, dimensions can be defined. The dimensions can represent respective variations of respective versions of a plurality of artifacts for at least a first configuration of a system. Via the dimensions, versions of the plurality of artifacts can be mapped to at least a corresponding first configuration of the system, the mapped versions of the plurality of artifacts corresponding to the versions of the artifacts used in the first configuration. The first configuration can be identified by a point in the multi-dimensional configuration space defined by the respective dimensions. At least a first of the plurality of artifacts can be stored by a first tool, and at least a second of the plurality of artifacts can be stored by a second tool disparate from the first tool.

Abstract: A data indexing system including a plurality of servers and a tracked resource set client is provided. Each of the servers include a plurality of resources that are part of a resource set. Each of the servers also include a tracked resource set corresponding to the resource set. The tracked resource set describes the plurality of resources located in the resource set. The server identifies the plurality of resources using rules of linked data. The tracked resource set client is in communication with the plurality of servers. The tracked resource set client has a data index. The data index is built and kept up to date using the tracked resource set of each of the plurality of servers.

Abstract: A data indexing system including a plurality of servers and a tracked resource set client is provided. Each of the servers include a plurality of resources that are part of a resource set. Each of the servers also include a tracked resource set corresponding to the resource set. The tracked resource set describes the plurality of resources located in the resource set. The server identifies the plurality of resources using rules of linked data. The tracked resource set client is in communication with the plurality of servers. The tracked resource set client has a data index. The data index is built and kept up to date using the tracked resource set of each of the plurality of servers.

Abstract: Resources are typically stored in homogenous data structures by shredding resource data into database tables destroying a native format of the resources. Typical approaches to indexing the resources rely on users indicating properties that should be indexed, using full text searches to create resource index documents, and other such labor and computation intensive processes. Functionality can be implemented to dynamically generate the resource index documents based on resource properties with minimal user input. The resource index documents can be in a common format to facilitate access to resources stored in heterogeneous native resource formats.

Abstract: Resources are typically stored in homogenous data structures by shredding resource data into database tables destroying a native format of the resources. Typical approaches to indexing the resources rely on users indicating properties that should be indexed, using full text searches to create resource index documents, and other such labor and computation intensive processes. Functionality can be implemented to dynamically generate the resource index documents based on resource properties with minimal user input. The resource index documents can be in a_common format to facilitate access to resources stored in heterogeneous native resource formats.

Abstract: In the present solution, as set of SDLC resources can be established, where each is separately addressable through a unique URL and is able to be managed through a simple set of operations. For example, a set of RESTful operations (GET, POST, PUT, and DELETE) can be used for the operations. Database management technologies can be leveraged for storing and indexing resources, but the underlying database schema for the solution can operate on a resource level, which results in the resources being stored as-is. Thus, storage (even when database based) of resources for the solution can be considered an Internet server exposing a space of URL addressable objects. Because the solution leverages Internet technologies and standards, it is scalable, standards based, extensible, and traceable.

Abstract: Mapping information that describes the mapping of referenced projects to their container project is included in the container project, using a “module mapping” file. A module mapping file is a simple meta-data file, for use at development time only, which stores data that maps relative URIs to IDE project names. The module mapping file contains entries for the location of nested archives, relative to the virtual archive defined by the container project, mapped to the uniquely named referenced project within the IDE. The paths of the archive files are computed “on the fly” just before the application server is started, rather than being simply written into an extensions file, located within the container project, in a fixed form when the enterprise application is written/developed.

Abstract: Methods systems and computer program products are provided which provide a transacted variable. The transacted variable is associated with a specific transaction such that actions on the underlying object of the transacted variable do not affect the contents of the transacted variable unless the actions are carried out in the context of the specific transaction associated with the transacted variable. Furthermore, the transacted variable allows for actions to be taken in the context of its specific associated transaction irrespective of an active transaction.

Abstract: Mapping information that describes the mapping of referenced projects to their container project is included in the container project, using a “module mapping” file. A module mapping file is a simple meta-data file, for use at development time only, which stores data that maps relative URIs to IDE project names. The module mapping file contains entries for the location of nested archives, relative to the virtual archive defined by the container project, mapped to the uniquely named referenced project within the IDE. The paths of the archive files are computed “on the fly” just before the application server is started, rather than being simply written into an extensions file, located within the container project, in a fixed form when the enterprise application is written/developed.

Abstract: Methods systems and computer program products are provided which provide a transacted variable. The transacted variable is associated with a specific transaction such that actions on the underlying object of the transacted variable do not affect the contents of the transacted variable unless the actions are carried out in the context of the specific transaction associated with the transacted variable. Furthermore, the transacted variable allows for actions to be taken in the context of its specific associated transaction irrespective of an active transaction.

Abstract: Methods systems and computer program products are provided which provide a transacted variable. The transacted variable is associated with a specific transaction such that actions on the underlying object of the transacted variable do not affect the contents of the transacted variable unless the actions are carried out in the context of the specific transaction associated with the transacted variable. Furthermore, the transacted variable allows for actions to be taken in the context of its specific associated transaction irrespective of an active transaction.

Abstract: A technique for providing a transaction management subsystem for an enterprise computing environment in which multiple concurrent and/or nested transactions may access the same Enterprise JavaBeans (EJBs) simultaneously. The transaction management subsystem provides a view for each transaction which includes an independent version of an EJB's business logic and its instance data. When an application or application user has made modifications to an EJB version and requests to commit the modifications, a determination is first made as to whether committing the modifications will result in an unacceptable data conflict with other versions of the same EJB. If no unacceptable data conflict will occur, and after resolution of those conflicts that can be resolved, the modifications are committed. The management subsystem also supports nested transactions, where each subtransaction may have an independent view of an EJB. Subtransactions may commit or roll back independently.

Abstract: A technique for maintaining the integrity of data maintained in an object in a persistent store of objects. When a modification event is initiated during a transaction to modify an object, a copy of the object is created. Modifications are made to the copy of the object, and the original object remains available to be accessed with its original value. The modifications to the copy of the object can be reviewed, or further modifications can be made to the copy before the modifications are committed and the changes to the copy applied to the original object and thus available to all users of the persistent store. Alternatively, the modification event can be canceled prior to commitment and never be made available via the persistent store.