Abstract: A preferably cloud-based platform supports improvements in software development by assessing quality of source code files, for example, when files are pushed to a software repository. Various static analysis tools are executed on a source file, and the resulting bug reports, which reflect native features of the tools are assembled in a dataset. The bug dataset is enhanced by adding additional features that are not natively generated by the static analysis tool. An ML classifier is trained to predict a selected bug feature, and the classifier is used to update the bug dataset to include estimated values of the selected feature. In an embodiment, post-processing analysis of bug report datasets applies machine learning methods to predict the “severity” of bug reports, an indication of whether they are likely to be true or false. Further, a report of code quality can be returned based on the severity predictions.

Abstract: A computer system for security of components includes at least one processor. For a new version of a component, the processor determines, based on a dataset of release events over time, a historical behavioral analysis of (i) a project that is released with prior versions of the component, and/or (ii) historical committer behavior of a committer that committed the new version of the component, and/or (iii) historical behavior of a publisher of the project. The dataset of release events includes event data collected over time regarding open source project, committers, and repository. The processor determines whether the new version of the component presents an unusual risk profile, based on the historical behavioral analysis. The processor facilitates delayed consumption of the new version of the component in response to determining that the new version of the component presents the unusual risk profile.

Abstract: A computer system, method, or computer-readable medium controls a potentially unacceptable software component intended for a software repository. A pre-defined application or repository policy associated with the repository or application pre-defines risks and, for each of the risks, an action to take for the risk. The action can be a pass action or a does-not-pass action, which are pre-defined programmatic steps also defined in the policy. When the component is not new to the repository or the application, the component is passed through for the usual handling. When the component is new, risks are determined that match the software component; for risks which match, the actions are taken as defined in the pre-defined policy. The pass action can include adding the software component to the software repository. The does-not-pass action is followed for a component that does not pass as a potentially unacceptable software component.

Abstract: A computer system, method, or non-transitory computer-readable medium provides an authoritative name source for files within an ecosystem. Files in the ecosystem which have identical contends and similar contents to each other are merged into the same supercluster, to capture possibly incremental changes to the files over time in one of the superclusters. For each supercluster which has files with identical and similar contents, the supercluster is broken down into package clusters, based on packages to which the files belong, each of the package clusters has the files from a same package. The package cluster which has most change frequency across versions, is identified as the authoritative package. The authoritative name for the files is resolved, based on the authoritative packages that are determined, across the plurality of superclusters which have files with identical and similar contents, and the authoritative name is generated. Any authoritative name collision is resolved.

Abstract: A computer system is provided, comprising: a transceiver; and a processor configured to facilitate: collecting and storing information related to a software project having one or more software artifacts, the information including: a project identifier, artifact identifiers for the artifacts used by the project, information about the temporal version for the artifacts, and contact information for a project user; collecting, from a repository, artifact metadata associated with the software artifacts, the artifact metadata including: information identifying the artifact, information about security risks associated with the artifact, information about a license associated with the artifact, or information indicative of a level of use or user rating of the artifact; periodically monitoring the metadata to determine whether there has been any actionable change in the artifact metadata; and notifying the project user using the contact information if it is determined that there has been an actionable change in the ar

Abstract: A computer system or method identifies components. A component fingerprint storage is configured to memorize known fingerprints of known components. The term “component” used herein is defined to be a specific version of pre-existing executable software, or a reusable pre-existing self-contained software code building block which is not a complete stand-alone finished product ready for use and which is binary or source code. A fingerprint is generated for a normalized unknown component and fingerprints are generated for all normalized components included in the unknown component. It is determined whether any of the fingerprints generated for the normalized unknown component and for the normalized components included in the unknown component match any of the known fingerprints of known components.

Abstract: An artifact update system including a server and a client is described. The server stores and updates a preference as to a characteristic of an artifact. The client executes a software development environment using the artifact. The server makes, in view of the preference as to the characteristic of the artifact, an actionable change determination as to whether there is a change in the characteristic of the artifact that reaches a threshold level of significance. The server communicates to the client the actionable change determination. When the actionable change determination is that there is a change in the characteristic of the artifact that reaches the threshold level of significance, the client performs a specific action in the software development environment in response to the actionable change determination.

Abstract: A computer system includes a transceiver and a processor that is cooperatively operable with the transceiver. The processor gathers, over the transceiver, (i) issue tracking information stored in an issue tracking storage system, the issue tracking information having a history of issues filed against a plurality of artifacts, and (ii) source code management information stored in a source code management storage system, the source code management information having a history of code changes committed against another plurality of artifacts. The processor checks a combined history of the issue tracking information and the source code management information for a history of issues filed against an artifact and a history of commits and corresponding source code changes committed against the artifact. The processor provides an interpretation of the current state of the artifact based on the combined history of the issue tracking information and source code management information about the artifact.

Abstract: A computer system, method, or computer-readable medium corrects a broken portion of an application. A fingerprint indicates classes that comprise the application. The classes indicated in the fingerprint are looked up to determine whether any is broken. For a broken class, a fixed class is substituted when the broken class is loaded at class load time for the application; a fixed class method is substituted into the broken class, when the broken class is loaded at class load time; fixed byte code is substituted for broken byte code corresponding to the broken class, when the broken class is loaded at class load time; the broken class is unloaded and the fixed class is loaded instead, when the application is running; or the broken class is replaced inside the static application with the fixed class; all without replacing classes which are not broken.

Abstract: A system, method, or computer-readable medium provide a look-up table having information on roots in repositories managed by a repository manager, the roots information in the look-up table being only n-levels deep. A file request is received, including filename and filepath with root. Before checking repositories managed by the repository manager for the requested file, the look-up table is referenced to determine whether the root of the requested file exists on one of the repositories managed by the repository manager. A check of the repository is bypassed when the look-up table does not indicate that the root exists on the repository. The repository is checked for the requested file, when the root is indicated as existing on the repository. The requested file is returned, if actually found on one repository. A “fail” response is returned, if the root is not indicated as existing in the look-up table.

Abstract: A software artifact is scored for a user. Metadata associated with an artifact about project activity of how active an artifact project is to which the artifact belongs, a security risk indicated in the metadata of the artifact, or a license indicated in the metadata of the artifact, is collected from a software repository. A weighting of the artifact alone is determined from the metadata associated with the artifact that indicates desirability of the project activity, the security risk, or the license. The metadata associated with the artifact is compared to appropriateness with a metadata of a user project to which the user belongs as indicated by a profile of the user, so as to provide a score considering the determined weighting of the artifact and a appropriateness of the artifact for the user with respect to an intended use of the artifact by the user.

Abstract: A method for recommending at least one artifact to an artifact user is described. The method includes obtaining user characteristic information reflecting preferences, particular to the artifact user, as to a desired artifact. The method also includes obtaining first metadata about each of one or more candidate artifacts, and scoring, as one or more scored artifacts, each of the one or more candidate artifacts by evaluating one or more criteria, not particular to the artifact user, applied to the first metadata. The method further includes scaling, as one or more scaled artifacts, a score of each of the one or more scored artifacts, by evaluating the suitability of each of the one or more scored artifacts in view of the user characteristic information. The method lastly includes recommending to the artifact user at least one artifact from among the one or more scaled artifacts based on its scaled score.

Abstract: Collecting and storing an artifact identifier for one or more artifacts, project identifiers for one or more software projects that use each artifact, and information about the temporal version for the artifacts. Collecting and storing project information related to the software projects, including a project identifier for each project, and contact information for a user of each software project. Collecting Metadata associated with the software artifacts, which includes information identifying the artifact, information about security risks associated with the artifact, information about a license associated with the artifact, or information indicative of a level of use or user rating of the artifact. The metadata is periodically or continually monitored to determine whether there has been any actionable change, and notifying the user about the actionable change.

Abstract: A computer system or method identifies components. A component fingerprint storage is configured to memorize known fingerprints of known components. The term “component” used herein is defined to be a specific version of pre-existing executable software, or a reusable pre-existing self-contained software code building block which is not a complete stand-alone finished product ready for use and which is binary or source code. A fingerprint is generated for a normalized unknown component and fingerprints are generated for all normalized components included in the unknown component. It is determined whether any of the fingerprints generated for the normalized unknown component and for the normalized components included in the unknown component match any of the known fingerprints of known components.

Abstract: A computer system or method identifies components. A component fingerprint storage is configured to memorize known fingerprints of known components. The term “component” used herein is defined to be a specific version of pre-existing executable software, or a reusable pre-existing self-contained software code building block which is not a complete stand-alone finished product ready for use and which is binary or source code. A fingerprint is generated for a normalized unknown component and fingerprints are generated for all normalized components included in the unknown component. It is determined whether any of the fingerprints generated for the normalized unknown component and for the normalized components included in the unknown component match any of the known fingerprints of known components.

Abstract: A system, method, or computer-readable medium provide a look-up table having information on roots in repositories managed by a repository manager, the roots information in the look-up table being only n-levels deep. A file request is received, including filename and filepath with root. Before checking repositories managed by the repository manager for the requested file, the look-up table is referenced to determine whether the root of the requested file exists on one of the repositories managed by the repository manager. A check of the repository is bypassed when the look-up table does not indicate that the root exists on the repository. The repository is checked for the requested file, when the root is indicated as existing on the repository. The requested file is returned, if actually found on one repository. A “fail” response is returned, if the root is not indicated as existing in the look-up table.

Abstract: An artifact update system including a server and a client is described. The server stores and updates a preference as to a characteristic of an artifact. The client executes a software development environment using the artifact. The server makes, in view of the preference as to the characteristic of the artifact, an actionable change determination as to whether there is a change in the characteristic of the artifact that reaches a threshold level of significance. The server communicates to the client the actionable change determination. When the actionable change determination is that there is a change in the characteristic of the artifact that reaches the threshold level of significance, the client performs a specific action in the software development environment in response to the actionable change determination.

Abstract: A computer system is provided, comprising: a transceiver; and a processor configured to facilitate: collecting and storing information related to a software project having one or more software artifacts, the information including: a project identifier, artifact identifiers for the artifacts used by the project, information about the temporal version for the artifacts, and contact information for a project user; collecting, from a repository, artifact metadata associated with the software artifacts, the artifact metadata including: information identifying the artifact, information about security risks associated with the artifact, information about a license associated with the artifact, or information indicative of a level of use or user rating of the artifact; periodically monitoring the metadata to determine whether there has been any actionable change in the artifact metadata; and notifying the project user using the contact information if it is determined that there has been an actionable change in the ar

Abstract: A method for recommending at least one artifact to an artifact user is described. The method includes obtaining user characteristic information reflecting preferences, particular to the artifact user, as to a desired artifact. The method also includes obtaining first metadata about each of one or more candidate artifacts, and scoring, as one or more scored artifacts, each of the one or more candidate artifacts by evaluating one or more criteria, not particular to the artifact user, applied to the first metadata. The method further includes scaling, as one or more scaled artifacts, a score of each of the one or more scored artifacts, by evaluating the suitability of each of the one or more scored artifacts in view of the user characteristic information. The method lastly includes recommending to the artifact user at least one artifact from among the one or more scaled artifacts based on its scaled score.

Abstract: An artifact update notification system that includes a server computer and client computer is discussed and described. The server computer stores artifact preferences, determined according to objective and subjective criteria, of artifact characteristics. The client computer executes a software development environment that makes use of a software artifact. The server computer and client computer interact to perform an update cycle. The update cycle includes the server computer communicating to the client computer whether there is an actionable change to the software artifact with respect to the artifact preferences. If there has been an actionable change to the software artifact, the client computer performs an update action in the software development environment in response to the actionable change.