jku-isse / ecco Goto Github PK

The buffer field is private with no access methods, thus it is only used internally. However, AFAICT it is only accessed in the setData and getData methods. In the setData, it is used under the assumption that the ArtifactData is serializabe. There might be cases in which the data being loaded into ECCO is not, e.g. EMF EObjects are not (by default).
In the getData, it is used to recreate the data from the buffer in case the data is null., but since the buffer can not be filled/set elsewhere there is no way this is actually helpfull.

In the ArtifactTree, using the Java ID of the nodes does not provide usefull information about the node. The Node Interface could define a mehthod "getTreeLabel", which by deafault (abstract base class) returns the Java ID, but the plugin could override. Probably the method just actually go in the ArtifactData so the plugins can provide custom implementations (plugins dont extend nodes).

Some integration tests use hard-coded file paths to files that naturally don't exist in the repository. Those tests should either be deleted or modified, such that they use a relative path from the resources folder instead.

In order to modify and keep certain tests, it might be necessary to create new test data in the mentioned resources folders.

The ECCO REST project is currently only tested manually and should be automated.
Therefore, the subproject must be extended and covered with a reasonable amount of unit tests that cover the most important features.

Currently Artifacts need to use Path instances to point to the files in the local file system that constitute the product "code" base. This makes sense for some specific cases, for example for the ECCO service that provides a "repository" like functionality where the files that constitute a product are kept in a local folder.

In the general sense, ECCO should support files located "anywhere" (e.g. web servers, ftp servers, network drives, etc.). For this I think the best approach is to change the Path to a URI.

If this is defeninetly not the case and things must be kept local, then the generic parameter from Artifacts should be removed and the Path interface "hard codeded".

The CLI does not currently cover many features of Ecco, additionally, it is written with an outdated command library.

First, the CLI should be rewritten with a more modern approach.
Preferably using Kotlin as a language, which would then allow usage of the Clikt library.

Secondly, the CLI should cover most features of ECCO that can be reasonably expected.
I.e.,

• Initializing
• Commit
• Checkout
• Handling Remotes
• Push
• Pull
• Listing Metadata:
  • Features
  • Loaded Adapters

Currently, when the Ecco Service is initiated the properties files is read form the class path. This means that if you want to provide a different configuration you need to change the ecco.properties file in the service project.
This file should be either:

1. Read from the repository folder, so the user can put it there. The issue with this is that the Ecco service is initiated once, and if the repository is changed then the different settings wont be changed
2. Read from an argument in the command line. This makes it possible to provide a properties file anywhere in the system. However, it suffers from the same issue that the service is initiated once.
3. If the above fail, then fall back to the class loader mechanism, effectively starting the service with a set of default options, i.e. all plugins loaded.. should this be the default?

Since you try to emulate a CVS repository, the above fit into the git approach: specific properties per repository (in the .ecco folder), global properties in the .git (.ecco) folder in the user home, default settings loaded from the service class.

As far as I can tell there are two or three major categories: core, dt (developer tools, i.e. cli/ui) and plugins (read/write from a domain). It might be usefull to group subprojects in each category by either adding a submodule/folder structure or adding a .core, .dt, .plugin fragment in the name/package structure.

Currently, the Ecco service (via DispatchWriter) checks that the output directory is empty before delegating to the plugin writter. I understand that this is wanted as currently Ecco does not provide a merge/conflict resolution mechanism.
I think this check and the actions taken should be delegated to the plugins. For example, in the EMF plugin I don't want to commit the metamodel (.ecore) but I need it to be there so I can open the model. This will also imply that I can have other files that I need, for example the folder micht contain IntelliJ or Eclipse files that indicate that the folder is a project.
The plugin can then decide if it will have a strong policy: the directory must be empty, or if it does something else: e.g. ask the user if files shuold be replaced, open the files with no append so the contents are overwritten, etc.
For backwards compatibility, it is easy to make the existing projects provide the strong policy.

The ArtifactPlugin, ArtifacterReader, etc.., share some of the itnerface methods. For example all the intefaces define the public abstract String getPluginId();

Perhaps a common super interface could be provided: ArtifactHelper to contain the common functionality. That way, for example, it would be easier to document that the getPluginId(); needs to return the class name of the ArtifactPlugin implementation.

As @arcanefoam in #10 (comment)_ mentioned, the ArtifactGraphView is missing a legend. Furthermore, afaik it is currently not possible to move around in the graph when zoomed in.

If there is no such possibility, it should be added, if there is a shortcut to move around, it should be mentioned in the legend.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency micronaut to v4.3.3
• Update dependency org.scala-lang:scala-library to v2.13.13
• Update plugin com.netflix.nebula.ospackage to v11.8.1
• Update plugin io.micronaut.minimal.application to v4.3.3
• Update dependency ch.qos.logback:logback-classic to v1.5.0
• Update dependency ch.qos.logback:logback-core to v1.5.0
• Update dependency io.micronaut.openapi:micronaut-openapi to v6.6.2
• Update dependency org.neo4j:neo4j to v5.17.0
• Update dependency org.neo4j:neo4j-bolt to v5.17.0
• Update gradle/gradle-build-action action to v3.1.0
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

In the EMF plugin an Artifact can be referenced by many artifacts and hence can appear multiple times in the tree.
I think the problem is that the LazyCompositionNode always creates a new node for the origNodes. So probably need a cache of Artifact:Node so they are not created more than once and instead reused.

I think that the ArtifactXXX interfaces belong to he base project, not the server. The main reason is that this interfaces are part of the base API of Ecco. That is, if you don't use the server, you will still nead te plugin, reader, writer, etc.