This article will be a series. (unfinished) I'm thinking about the following configuration.
・ Problem raising-This article I will explain the background and theme of this article, and the completed drawing. ・ Gradle environment construction-(Posted) Describes version control by gradle and integration of java / js build environment.
・ IDE environment construction- (not posted) Explains the environment construction procedure when developers perform programming, unit tests, and manual debugging.
What kind of environment do you use to program? Speaking of a long time ago, this language (or this OS) is decided by this environment! I had a feeling like that, but when I tried and errored while searching on the net how to standardize the development environment, I thought that it was not the case these days, so it is difficult to investigate every time. So I will summarize the results and ideas in an article.
Unless it is a very special project, I hope it will serve as a reference when building an environment for future development projects. The content of the writing is basically for myself, but I hope it helps if there are people who have similar feelings.
However, since I only know what I can understand, I will define the area in advance for this article to handle.
I think that the development environment these days has many configurations as shown in the above figure. In this paper, what kind of environment will be built on the development terminal (own terminal) shown above and in the area focused on the Java / Javascript language? I will follow the procedure with the theme.
The following is one way of thinking that I got as a result of my research. Of course, I don't think this is the only answer, and I'm not sure if this is the most standard.
As a result of investigating during this consecutive holiday, I could not find an environment that is easy to build, has various functions, and can integrate anything. However, I can't conclude that, so I thought of the following configuration as far as I could think of.
The first thing to look at is how Gradle works. Others seem to be effective alternatives, but I think that gradle's ease of handling and spaciousness are unrivaled by other build tools, and since it can coexist with ant and maven, it is easy to support legacy. It can be said that it is almost the de facto standard.
Next is eclipse and VS Code. After all, the number of users of eclipse is overwhelmingly large, so it can not be cut off, and I have the impression that it is surprisingly compatible with gradle. And for VS Code, I wanted to realize manual debugging of javascript with eclipse if possible, but I gave up because I could not find a procedure that was easier to install and easier to debug for multiple purposes than VS Code. There is also a compatibility issue with npm.
In the field so far, there were many cases where java and js projects were managed by svn as a unit, but from now on, I think that workspace should be considered as a unit. In this attempt, as shown in the figure below, the concept of workspace is designed to unify all operating environments. Depending on the work at that time, it may be a gradle workspace, an eclipse workspace, or a VSCode workspace, but always access from that location as the starting point. This structure seems to be the most convenient for both humans and systems.
Draft file structure for workspace(Assuming windows environment)
/workspace : gradle, eclipse,VS Code common workspace
/.metadata :eclipse sharing settings(Partially shared)
/.plugins :eclipse sharing settings(Partially shared)
/.vscode :VS Code sharing settings(Partially shared)
/launch.json :js debug configuration definition
/node_module :npm module root(jasmine-node, karma)
/gradle :gradle home
/libs :Libraries
/java :Library referenced by the java program to be developed
/js :Library referenced by the js program to be developed
/test :Library referenced by unit tests
/site :API specifications, unit test result site
/docs :API specifications
/javadoc :javadoc root
/jsdoc :jsdoc root
/reports :Unit test results
/java : spock,jacoco report
/js : jasmine-node,karma report
/project1 :Project home(Temporarily Java project)
/.settings :java compiler,Formatter,File save action
/bin :class folder
/src :Production code(java)
/spec :Unit test code(spock)
/gradle : gradle-wrapper execution environment
/.project :Project settings(groovy project)
/.classpath :Source folder,class folder,Library settings
/gradlew.bat :Build,Batch for automated test execution
/project2 :Project home(Temporarily Js project)
/.settings :java.settings and.Equivalent to a combination of classpaths
/bin :If you need transpile
/src :Production code(js)
/spec :Unit test code(jasmine)
/gradle : gradle-wrapper execution environment
/.project :Project settings(javascript project)
/gradlew.bat :Build,Batch for automated test execution
/build.gradle :Build definitions that can be applied across projects
/gradle.properties:If you need properties
/settings.gradle:Enumerate project folders
/gradlew.bat :Parent gradle-wrapper
I've omitted folders and files that aren't necessary for team sharing, but just by developing one java project and one js project, the lineup is really this much. I intended to reduce the number, but it is a tremendous amount. It seems that it is wasteful to build and manage this by personalized work, so standardization work seems inevitable. Even if it says standardization, it is appropriate to systematize it to some extent because the procedure manual is not suitable for this complexity.
I'm sorry for those who were expecting a deeper or concrete method. It's going to be long and I'm tired, so I'll post the detailed procedure from the next time. Since it is a conceptual story, it may have been difficult to convey because it was only sentences, but if you like, please read it when the next post is completed.
2018/07/22 Gradle environment construction posted