payload: {"action":"created","issue":{"url":"https://api.github.com/repos/crapo/sadlos2/issues/378","repository_url":"https://api.github.com/repos/crapo/sadlos2","labels_url":"https://api.github.com/repos/crapo/sadlos2/issues/378/labels{/name}","comments_url":"https://api.github.com/repos/crapo/sadlos2/issues/378/comments","events_url":"https://api.github.com/repos/crapo/sadlos2/issues/378/events","html_url":"https://github.com/crapo/sadlos2/pull/378","id":473346891,"node_id":"MDExOlB1bGxSZXF1ZXN0MzAxNTMxNDkx","number":378,"title":"Test STEM rules; remove generated/Eclipse files; trim poms","user":{"login":"tuxji","id":5915561,"node_id":"MDQ6VXNlcjU5MTU1NjE=","avatar_url":"https://avatars2.githubusercontent.com/u/5915561?v=4","gravatar_id":"","url":"https://api.github.com/users/tuxji","html_url":"https://github.com/tuxji","followers_url":"https://api.github.com/users/tuxji/followers","following_url":"https://api.github.com/users/tuxji/following{/other_user}","gists_url":"https://api.github.com/users/tuxji/gists{/gist_id}","starred_url":"https://api.github.com/users/tuxji/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tuxji/subscriptions","organizations_url":"https://api.github.com/users/tuxji/orgs","repos_url":"https://api.github.com/users/tuxji/repos","events_url":"https://api.github.com/users/tuxji/events{/privacy}","received_events_url":"https://api.github.com/users/tuxji/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2019-07-26T13:01:00Z","updated_at":"2019-08-26T13:30:20Z","closed_at":null,"author_association":"COLLABORATOR","pull_request":{"url":"https://api.github.com/repos/crapo/sadlos2/pulls/378","html_url":"https://github.com/crapo/sadlos2/pull/378","diff_url":"https://github.com/crapo/sadlos2/pull/378.diff","patch_url":"https://github.com/crapo/sadlos2/pull/378.patch"},"body":"Test the SADL Server's ability to run STEM rules by continuing to work on the testSTEM unit test.  Now testSTEM runs all the queries from STEM's Run.sadl, successfully demonstrating the ability to to write output CSV files and draw SVG graphs.  The STEM files themselves remain outside the SADL source tree for now so keep the @Ignore annotation on testSTEM.\r\n\r\nMerge in previous unpushed work performed a few months ago to generate all service loader files automatically with the most current version of serviceloader-maven-plugin.  Previously we were defining service loader files manually and adding them to the jar files.  It's better to list service interfaces in the poms and let the plugin do the work of finding the service implementations and creating the service loader files.\r\n\r\nRemove some files that shouldn't be put under source control because they're generated by Maven or Eclipse.  There is no need to put files like .classpath, .project, .settings/, model/generated/*.genmodel, plugin.xml_gen, freshly built jars, etc., under source control because they are generated either when importing these existing Maven projects into Eclipse or using Maven to build the projects.  Keeping these files in source control only increases the chance that a git pull will abort with a warning that it would overwrite some locally modified files, and causes extraneous diff output and unnecessary churn in commits.  They don't belong in source control, period.\r\n\r\nContinuing the same philosophy, also keep some Eclipse launch files out of source control since they are very specific to only one or two developers who can keep them around as files that will be ignored by git from now on.\r\n\r\nEnsure Maven's clean goal will remove all files generated by Maven by configuring filesets to be removed in the parent pom itself, not in two or three child poms while missing some files that weren't getting cleaned.  Now \"mvn clean\" will remove plugin.xml_gen, model/generated, src-gen, and xtend-gen from every project that has these files.\r\n\r\nMake some minor cleanups (really, I had to hold myself back since there are a lot more cleanups that could be made) in files like a few MANIFEST.MFs, build.properties, and poms.  Most of these cleanups merely trim these files by removing unnecessary stuff that don't belong in these files.\r\n\r\nI've built and tested SADL with these changes in a DSL 2018-12 Eclipse instance on the STEM project and in test code and a standalone jar making calls to the SADL Server API many times, but we would have better coverage if Andy or Akos could test SADL with these changes in additional projects that I don't have access to (e.g., Andy's test projects, etc.).\r\n\r\nPlease be aware of two important things that you will need to know when building the sadl3 projects.  First of all, when building SADL from the command line, don't run Maven clean and install at the same time such as with \"mvn clean install\" - if you do that, the build will fail with errors compiling the Xtend sources in com.ge.research.sadl.ide.  Simply run mvn clean first and then mvn install only after mvn clean finishes, and the build will finish successfully.  When building SADL in Eclipse after importing the projects, you may also get a build error in com.ge.research.sadl; just run Maven clean before running Maven install and the build should work then.\r\n\r\nSecond, you will get 6948 errors in Eclipse after you import these sadl3 projects into a Java Latest Release Eclipse instance for the first time.  Some 4867 of these errors won't go away even after the usual fixes of building, cleaning, or refreshing the projects, or running Maven Update Project..., but what will make all but one of these errors go away is if you delete all the projects (without deleting their contents on disk) and then re-import these projects into the same Eclipse again.  The remaining 1 error seems to be a bogus Xtend \"must use override keyword\" error that should be ignored (in fact, if you run the Quick Fix that changes the def keyword to override, the Maven build will break with an Xtend error saying the override keyword is not allowed there).  At times after running mvn clean and mvn install from the command line, Eclipse may also get 4 more errors about two projects that don't have an xtend-gen directory, but these 4 errors will go away if you delete and reimport the sadl3 projects again.  Whenever in doubt, reimporting the projects a second time often helps; we don't have to put Eclipse's project files in source control just because importing the first time doesn't work very well.\r\nJohn"},"comment":{"url":"https://api.github.com/repos/crapo/sadlos2/issues/comments/524861013","html_url":"https://github.com/crapo/sadlos2/pull/378#issuecomment-524861013","issue_url":"https://api.github.com/repos/crapo/sadlos2/issues/378","id":524861013,"node_id":"MDEyOklzc3VlQ29tbWVudDUyNDg2MTAxMw==","user":{"login":"tuxji","id":5915561,"node_id":"MDQ6VXNlcjU5MTU1NjE=","avatar_url":"https://avatars2.githubusercontent.com/u/5915561?v=4","gravatar_id":"","url":"https://api.github.com/users/tuxji","html_url":"https://github.com/tuxji","followers_url":"https://api.github.com/users/tuxji/followers","following_url":"https://api.github.com/users/tuxji/following{/other_user}","gists_url":"https://api.github.com/users/tuxji/gists{/gist_id}","starred_url":"https://api.github.com/users/tuxji/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/tuxji/subscriptions","organizations_url":"https://api.github.com/users/tuxji/orgs","repos_url":"https://api.github.com/users/tuxji/repos","events_url":"https://api.github.com/users/tuxji/events{/privacy}","received_events_url":"https://api.github.com/users/tuxji/received_events","type":"User","site_admin":false},"created_at":"2019-08-26T13:30:20Z","updated_at":"2019-08-26T13:30:20Z","author_association":"COLLABORATOR","body":"How about this fourth option (an improvement of the second option)?  \r\n\r\n- Gradle runs a Maven build in only the com.ge.research.jena directory, which populates the lib directory with the jars needed by the NPM and Docker stages.\r\n\r\nMost of the jars (except for two) are downloaded from the Maven central repository.  The exceptions are reasoner-api-3.2.0-SNAPSHOT.jar and reasoner-impl-3.2.0-SNAPSHOT.jar, which are downloaded from the Maven local repository.  These jars don't depend on any other SADL modules, however.  So the fourth option actually would have to do this:\r\n\r\n- Gradle runs a Maven build in only the com.ge.research.sadl.reasoner-api, com.ge.research.sadl.reasoner-impl, and com.ge.research.jena directories, which populates the jena/lib directory with the jars needed by the NPM and Docker stages.\r\n\r\nWe can move the reasoner-api and reasoner-impl jars even faster to build by making them subdirectories of a com.ge.research.sadl.reasoner directory with a standalone pom that becomes the new pom of these two subdirectories' poms.  These jars do not depend on Eclipse, therefore they do not need to load the Tycho build infrastructure that the com.ge.research.sadl.parent pom brings in.  Maven takes a very long time to start up when it uses that com.ge.research.sadl.parent pom, so eliminating that pom as a parent pom will allow Maven to build the reasoner jars in only 30 seconds instead of minutes.\r\n\r\nTherefore, Gradle would run the Maven build in the com.ge.research.sadl.reasoner directory as a first step, which takes only 30 seconds and installs the reasoner jars into the Maven local repository, then it runs the Maven build in the com.ge.research.jena directory as a second step.  The jena jar is an Eclipse bundle so its pom still needs the com.ge.research.sadl.parent pom and Maven still takes longer to start up.  However, we don't need run \"mvn install\"; we can run \"mvn prepare-classes\" which is a different phase that only performs the copy-dependencies, default-resources, and default-compile goals.  It will skip all of the later goals, so the lib directory will get populated faster (on my laptop, mvn process-classes took 30 seconds).\r\n\r\nWhat do you think, Akos and Andy?"}}
other: {"actor":{"display_login":"tuxji"}}