2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE) 2019
DOI: 10.1109/icse.2019.00090
|View full text |Cite
|
Sign up to set email alerts
|

Intention-Based Integration of Software Variants

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1
1

Citation Types

0
8
0

Year Published

2019
2019
2023
2023

Publication Types

Select...
4
3

Relationship

4
3

Authors

Journals

citations
Cited by 15 publications
(8 citation statements)
references
References 32 publications
0
8
0
Order By: Relevance
“…Whereas previous work typically looked at only a small number of hard forks, and research on tooling around hard-fork issues typically focus on few well known projects, such as the variants of BSD [35] or Marlin [28] or artificial or academic variants [14,22], we have detected a significant number of hard forks, many of them recent, using many different languages, that are a rich pool for future research. We release the dataset of all hard forks with corresponding visualizations as dataset with this paper [2].…”
Section: Frequency Of Hard Forksmentioning
confidence: 89%
“…Whereas previous work typically looked at only a small number of hard forks, and research on tooling around hard-fork issues typically focus on few well known projects, such as the variants of BSD [35] or Marlin [28] or artificial or academic variants [14,22], we have detected a significant number of hard forks, many of them recent, using many different languages, that are a rich pool for future research. We release the dataset of all hard forks with corresponding visualizations as dataset with this paper [2].…”
Section: Frequency Of Hard Forksmentioning
confidence: 89%
“…(2.) The asset is not contained in the target, but needs to be integrated [18] with its siblings in the target, that might not exist beneath its parent in the source. This process is typically difficult to solve automatically, as code can not only be integrated in multiple ways, but in multiple dimensions: in variation points and in ordering.…”
Section: Operationsmentioning
confidence: 99%
“…The evolution is documented by meta-data, usable as ground truth for evaluations. This synthetic version history can be used to benchmark tools that require such a version history as an input, such as feature identification and location [7,28], re-engineering [2] and code integration tools [18]. Our design addresses requirements related to evolving systems in a feature-oriented way, whilst documenting it as meta-data, assuring compilability, and being language-independent and extensible.…”
Section: Introductionmentioning
confidence: 99%
“…Furthermore, most of our use cases applying clone & own also have an integrated platform, that is, a project with common assets. We are only aware of one work in this direction (Lillack et al 2019), which should further be complemented with methodologies and tools.…”
Section: Limitations Of Clone-management Techniquesmentioning
confidence: 99%
“…Specifically, as pointed out for our railway case, there should be means to express historical additions, suppressions, and modifications at the highest level of abstraction, specifically distinguishing architectural and functional evolutions. As such, practically usable, dedicated diffing techniques, which support existing variation points (e.g., #ifdef), are needed, potentially building upon recent techniques such as intention-based clone integration (Lillack et al 2019). Enhanced visualization capabilities should also support highly scattered features (Passos et al 2015(Passos et al , 2018, as explained for the web application and power electronics case.…”
Section: Diffing Of Cloned Variantsmentioning
confidence: 99%