101companies / 101simplejava Goto Github PK
View Code? Open in Web Editor NEWA set of 101companies contributions that are easy to build, run, and test
A set of 101companies contributions that are easy to build, run, and test
Hi Matthias,
please integrate @DerDackel 's new contribution:
Please see whether you can run it.
Also, please create a wiki page.
We were discussing the standard package prefix a lot and didn't come up with any compelling, short contender. I therefore conclude that org.softlang.company shall be used whenever possible. This is what is used mostly anyway. The important thing is, of course, that "org.softlang" should only be applied to contributions that come from the softlang team. So other package prefixes should be preserved when the contributions are from non-softlangers.
Generally, sub-packages should not be used unless there is a compelling reason and a convincing name for the subpackage.
I would suggest that "a compelling reason" could be either of those:
a) There are not just a few files and thus, some group facilitates understanding.
b) Some of the files are tool-generated (as with JAXB) and they are held in a designated package.
c) The technology may stipulate different packages. (Any example?)
We know that subpackage names were assigned somewhat chaotically across different contributions. For instance, we may have used "features", "operations", "behavior". The use of such names is too subtle. Perhaps some of these names make more sense:
There may be more good candidates. Just try to normalize and get rid of subtle packaging. In case of doubt, let's discuss via comments on this GitHub issue.
Do I remember correctly that we would be using a "tests" package for them? Or is it "test" Which one is best practice? Please check and enforce.
Apparently this one dislikes the rename of meganalysis to "ACME Corporation". For the moment, I chose to name the sample corp. "ACMECorporation" instead, but I'm looking into a proper fix.
Hi Matthias,
See here:
https://github.com/101companies/101simplejava/blob/master/README.md
I remember you saying that the windows-specific instructions are not to the point.
Any improvements you can make?
(So that the students in the course don't run into issues.)
Thanks,
Ralf
PS: I think for Linux and Mac OS X, we seem to be fine.
I see that there is a .gradle file/folder in contributions once I ran gradle.
Should this file be added to .gitignore (so that it does not pop during "git status")?
We should use "Acme Corporation" rather than "meganalysis".
http://en.wikipedia.org/wiki/Acme_Corporation
Just looking, for example, at package org.softlang.company.features.javaf.syb
of javaSyb.
So you are placing framework/library-like functionality in the package for features.
This is really not helpful in understanding / explaining / maintaining the architecture of a contribution. Please refactor.
We are in the process of migrating 101wiki to a new metamodel for contributions and others.
The emerging metamodel is currently bootstrapped with many Haskell-based contributions.
Eventually, the Java-based contributions of the present repo should catch up.
Many of the changes are trivial; some of theme were already automatically completed.
However, some of the new metamodel details require manual effort.
What exactly needs to be done should be discussed once this issue is picked up.
To provide some indicators, consider this:
Hi Matthias,
I added jdomHttp and javaJson and javaJsonHttp.
I think I revised all gradle stuff as needed.
Can you please see whether you still build and test everything?
(... so that the students don't run into issues.)
Thanks,
Ralf
I recognized that README.md varies in style and level of "uptodateness".
Therefore, I propose the following clean-up.
I set up an example:
https://github.com/101companies/101simplejava/tree/master/contributions/dom
Thus, the only variable parts in a README.md would be these:
When doing the README.md's, please take these considerations into account:
In addition to the naming issues, noted in another issue, these tests don't make much sense as such:
They are not really testing much as than doing some file I/O.
This needs to be improved.
I copied this approach over to javaReflection. So this is also a problem there and probably in several other implementations.
Not much is needed, but some basic info about these things:
The various Java projects mess around with different package names.
Most of them seem to be using org.softlang.
Generally, long package names make it unnecessarily hard to just explore the projects.
Perhaps, we kind find some "best" practice that allows us to use much shorter package names.
The use of the default package appears to be a tabu, but perhaps we can find some support for doing it. If we decide not to use the default package, what would be the shortest package name that is tolerable from a best practice/engineering point of view?
The subpackages names should also be standardized.
It looks like the following patterns are in use:
A tentative proposal for a standardization and simplification follows:
Just read this:
https://github.com/101companies/101simplejava/blob/master/README.md
It talks about steps to be applied for all contributions?
What to do when I only want to build and test a single contribution?
Please enhance the README.md to clarify.
This was reported before.
It is in README.md where the headline is copied to.
So no copying to build.gradle.
Just seeing this in javaSyb.
Just gradle built and eclipsed javaSyb.
Now I see a "bin" directory.
It does not even disappear after "../gradlew clean".
We have this sort of stuff in the contributions dir:
https://github.com/101companies/101simplejava/tree/master/contributions/gradle
This greatly confuses the infrastructure.
This must be moved out of the way.
The emerging best practice is to use "tools" (rather than contributions).
Also a subdir of tools should use a name that is unlikely to cause any conflict across the repos.
So I guess "contributions/gradle" should become "tools/gradle-simplejava" or something like that.
I guess we could want to have a nice example for this technology:
http://commons.apache.org/proper/commons-jxpath/
We would need to think about what features shine with this technology and whether we have all features to actually demonstrate this technology sufficiently.
@avaranovich do you have an idea how we should go about this problem?
The issue is this:
It looks like when one builds all of 101simplejava, then certain files get re-generated.
Here is a snippet from the corresponding "git status":
modified: contributions/jaxbComposition/src/main/java/org/softlang/company/xjc/Company.java modified: contributions/jaxbComposition/src/main/java/org/softlang/company/xjc/Department.java modified: contributions/jaxbComposition/src/main/java/org/softlang/company/xjc/Employee.java modified: contributions/jaxbComposition/src/main/java/org/softlang/company/xjc/ObjectFactory.java modified: contributions/jaxbComposition/src/main/java/org/softlang/company/xjc/package-info.java
This is unfortunate because such changes may create loads of stupid conflicts.
Any thoughts?
Basically we want a clone of this one:
http://101companies.org/wiki/Contribution:mySqlOne
... but without dependence on mySql since this would imply installing MySQL through the admin interface of the host computer. Rather we need a version that installs a database through Maven so that we can do the build/test/eclipse targets as if this was a regular 101simplehava contribution.
Does SQLite work this way?
We cannot have 101simplejava/contributions/gradle and alikes in the general directory structure for contributions (or other namespaces for that matter). Specifically, such gradle stuff needs to get out of the way.
The violation of this constraint messes up 101 because the gradle stuff now appears to be a "contribution".
Where does it go? Here are the general constraints to meet and to refine. That is, all such stuff must compete for a global namespace scheme. The gradle stuff must be Ok with any other 101repo that may come up.
Let's discuss and resolve.
Should testNegative
I am not assigning to @DerDackel or @tbernau but perhaps they may be willing to do this.
Anyway, experience with the PTT class shows that the current use of gradle makes it perhaps not easier for most involved to understand how to respond to any issues that may arise.
I don't think we want to move away from Gradle for resource/continuity reasons. So we need to accept that 1. will remain a problem.
We must address 2. in some way.
If there would be no problems, we could be ignorant, but there are problems:
So we need to solve both problems: 3. and 4. but automated testing (and address 2.).
Ralf
At this point we generally seem to assume the following license, but this could be changed, if needed.
http://101companies.org/wiki/101companies:License
Should the LICENSE file hence at the top of the repo? Is just a pointer enough? Say, what is the smallest footprint for addressing the LICENSE duty?
So we have this one:
https://github.com/101companies/101simplejava/tree/master/contributions/yapg
... and this one:
https://github.com/rlaemmel/yapg.git
which linked here:
https://github.com/101companies/101repo/blob/master/.gitdeps
I am confused. yapg was canceled in 101simplejava and moved elsewhere (2nd location). Now it is back in the old location?
When I am running "git status" on 101simplejava, I see loads of noise:
... # ../jdom/.classpath # ../jdom/.project # ../jdom/.settings/ # ../jdom/build/ # ../sax/.classpath # ../sax/.project # ../sax/.settings/ # ../sax/build/ # ../xom/.classpath ...
.gitignore should make sure to make those kinds of things go quiet.
I am getting this sort of stuff for "git status":
# Untracked files: # rxjava/.classpath # rxjava/.project # rxjava/.settings/ # rxjava/build/
Please check other contributions for the right logic regarding .gitignore.
More generally, please make sure "git status" is empty after commiting/pushing new contributions.
Hi @tbernau
I would like to discuss whether it is reasonable to go back to a scheme where contributions are self-contained. Seeing how students struggle with the repo-level distribution and seeing further how our contribution-level zip distribution is broken now, I would like to seriously consider going back to self-contained distributions.
What would be the consequences?
If @DerDackel also has an opinion on / time for this, please comment as well.
cc Michael Monschau (once I know his id).
cc @ydupont
This is a tough one.
The java jdbc contribution is still in 101repo for a reason.
We cannot gradle-ize/maven-ize it -- not on the grounds of its technology dependencies, in the current form.
There must be some DB engine, some setup that is controllable in this sense though.
Perhaps Yves is closer to proposing something here.
We can discuss this when we meet next time.
Not urgent.
Likewise, we would want to bundle hibernate stuff.
This is trying to make one aspect of #19 more operational.
When looking at build.gradle of a non-trivial project I see this:
$ pwd
/Users/laemmel/Downloads/101simplejava-master/contributions/jaxbComposition
$ more build.gradle
description = 'Object/XML mapping for Java and XSD with JAXB'
I don't think the description should be there because per #18 it belongs into the README.
Thus, the file is essentially empty.
Now, a beginner will have no idea that still some stuff happens (i.e., xjc is invoked). I didn't even bother to look at the global gradle file, but I guess some cleverness is encoded there to process Company.xsd in some cases. How would the global rule know that it needs to be run on specific contributions?
Anyway, here is my proposal. When looking at the gradle file there must be some hint at the fact that "xjc" is invoked so that a modestly experienced user is encouraged to look further in the global gradle file. Don't make the global gradle file overly clever.
Just realized that the code for "total" is actually written into the test class.
This needs to be factored out into a proper main class.
Also, the test class should perhaps not be be called "Parsing" because antlrLexer does no parsing. What would be the name for the class in other, non-antlrish contributions?
Further, there is no implementation of Cut, but there should be preferably.
The idea of javaLexer could be applied such that an output stream is filled with all tokens modulo adapting the salaries.
Just looking at some pages which are about the current homework.
For instance:
http://101companies.org/wiki/Contribution:sax
It talks about packages that do no longer exist.
I am trying to fix this for this one, but please take care of this, as we were discussing this before. Some standardized, simple architectural description could be really wanted.
There is Feature:Serialization and its subfeatures.
There is features for parsing and unparsing.
The naming seems to confuse them occasionally.
Just looking at javaSyb with its ParsingTest (which is about (de-)serialization).
Loads of them I run into.
Unless this is about generated code, such unused imports are not wanted.
So we could do a concurrent implementation using this:
I guess we can start from the existing thread-based implementation and see how we can leverage akka instead.
I am assigning @DerDackel but I guess Sebastian could also communicate with @tbernau whether Thomas can take over. What I am describing here is a result though of Sebastian's efforts; so he would need to say at least how to proceed in technical terms.
Prior to setting up gradle, the jaxb* contributions contained Makefile-based rules that described very clearly how to derive the object models from the schemas.
The PTT students had issues with Contribution:jaxbComposition.
See the FB group for PTT.
It looks like the gradle stuff not working under Windows.
Also, the documentation (README.md) should hint at the need to set JAVA_HOME.
Thanks to @DerDackel and @tbernau for fixing this so that we don't run into this again when we use ANTLR next week.
As far as I understand, Sebastian has a fix.
It looks like Kevin Klein also has a fix:
https://github.com/ar7u9o/101repo/blob/master/other/build.gradle
Demonstrate DOM-based validation.
@DerDackel was mentioning that he had trouble with that.
Anyway, it was working just fine before it was gradle-ed.
So please unbreak.
/Users/laemmel/projects/101simplejava/contributions/yapg/src/test/java/org/softlang/tests/Parser.java:8: cannot find symbol symbol : class CompanyLexer location: package org.softlang.company import org.softlang.company.CompanyLexer; ^ /Users/laemmel/projects/101simplejava/contributions/yapg/src/test/java/org/softlang/tests/Parser.java:9: cannot find symbol symbol : class CompanyParser location: package org.softlang.company import org.softlang.company.CompanyParser; ^ /Users/laemmel/projects/101simplejava/contributions/yapg/src/test/java/org/softlang/tests/Parser.java:21: cannot find symbol symbol : class CompanyLexer location: class org.softlang.tests.Parser CompanyLexer lexer = new CompanyLexer(antlr); ^ /Users/laemmel/projects/101simplejava/contributions/yapg/src/test/java/org/softlang/tests/Parser.java:21: cannot find symbol symbol : class CompanyLexer location: class org.softlang.tests.Parser CompanyLexer lexer = new CompanyLexer(antlr); ^ /Users/laemmel/projects/101simplejava/contributions/yapg/src/test/java/org/softlang/tests/Parser.java:23: cannot find symbol symbol : class CompanyParser location: class org.softlang.tests.Parser CompanyParser parser = new CompanyParser(tokens); ^ /Users/laemmel/projects/101simplejava/contributions/yapg/src/test/java/org/softlang/tests/Parser.java:23: cannot find symbol symbol : class CompanyParser location: class org.softlang.tests.Parser CompanyParser parser = new CompanyParser(tokens); ^ 6 errors :yapg:compileTestJava FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':yapg:compileTestJava'. > Compilation failed; see the compiler error output for details. * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED
This is sort of related to #19.
Based on PTT experiences and today's work with @DerDackel .
We could perhaps distribute projects past the steps for basic configuration with "./gradlew" and build / tests steps with "./gradlew build & eclipse", but I guess this would not work directly as libraries would be in the Maven repo on the system used for building.
Anyway, if we could do something to the effect of this, then things would be back to "simple" for users of the "simple" contributions. They used to be simple because they were self-contained Eclipse projects. Now they are no longer self-contained and need gradle to be performed to even arrive at an Eclipse project. This appears to be hard for beginners and they have no idea how to fix things manually when necessary.
Of course, the fact (and the way in which) we use Gradle is alright. It is just adding some point of failure for the potential stakeholders of 101simplejava, which are beginners.
Looking forward more discussion.
This is about this technology:
http://www.stringtemplate.org/
The contribution would exercise Feature:Unparsing.
http://101companies.org/wiki/Feature:Unparsing
Checkout existing implementations within 101simplejava that also implement that feature for comparison.
By definition, the projects of this repo should be easy to build and test.
Thus, we should demonstrate this proper.
That is, the repo should be equipped with some scripting (make, ant, maven, python, ...) so that by a simple script execution all projects are built and tested and report is produced to summarize the results somehow.
Each project, should also do the following as part of build and test:
README.md of this repo should be used to document everything.
.gitignore should be maintained to be useful for this style of repo.
perhaps with JMS:
http://en.wikipedia.org/wiki/Java_Message_Service
See also a more general discussion here:
http://www.slideshare.net/buzdin/messaging-in-java
One idea could be that one client maintains the company objects whereas the other client sends messages to retrieve company data which are to be sent back also by messages.
Overall, let' see how we can demo messaging without perhaps adding another feature. If necessary though, we can discuss a new feature.
The zip worker currently zips (http://data.101companies.org/zips) the repo as (1) a whole and as (2) individual implementations. Build scripts are only present at implementation level.
With the way our build scripts currently work (all info in a single super script in ...\contribtuions) all build info in (1) and (2) is lost.
With the structure of the resulting zip from (1) where all 101implementations are in the same folder super build scripts from different subrepos will collide if the same build system (and hence script name) is used. Also such super build scripts would need to be included in (2).
A solution on the worker side would be changing the zip structure (adding a superfolder to (2) to include e.g. build.gradle and settings.gradle and the need of dividing contributrions by repo/language/build system/something in (1)).
A solution on the build side would add redundancy and reduce maintainability but also add comprehensibility and usability (for both contributors and users) to the whole repo (every implementation would have its own script).
If not for the educational and community driven aspect of 101companies the first solution would be obvious.
The various contributions use slightly different styles of test hardnesses for no reason.
Should we have one test class? When should we have several? How to name the classes and the test methods? What to test? How much file processing to do along with it? Etc.
Another major area of divergence is the test data itself and how it is actually obtained. There are probably good reasons as to why the data is encoded in the program, whether instead it is de-serialized from a file (in object serialization format or XML), but it looks like some best practice could be defined (-> README.md).
Should we try to reuse test data across different contributions more aggressively? This is probably something we should save for later as it gets into the bigger area of "refactoring for a product line".
Just FYI.
I started from javaSyb.
The tests are now called Ok.
Haven't resolved the issue with the build.gradle vs. README.md redundancy.
Thanks for taking care of javaReflection.
We currently can not guarantee functionalities for multiple OS (or possibly even OS configurations).
We have to assume that Gradle works on different OS's (was tested on Windows 7, Ubuntu and MAC OS X and works fine), yet some implementations may cause errors platformdependent (see #35) and this can currently not be discovered automatically.
Sax seems to be buggy. Validation causes some weird errors (stating that UTF-8 is no known format) situational, system-inter and -intra-dependent:
On Windows:
On Ubuntu:
The problem seems to occur for others (internet), yet I found no solution or explanation.
Would we be able to get an Apache EJB contribution?
Would we have problems similar to other database-based contributions (in that build is more involved)?
Below follows a list of the relevant contributions.
All those guys are to be eradicated from 101repo.
They should be added to 101simplejava.
The projects should again appear in a contributions folders.
However, .jar and .class files are NOT copied over.
Perhaps the list of excluded .jar and .class files could be captured and shared with me and tbernau.
antlrAcceptor
antlrLexer
antlrObjects
antlrParser
antlrTrees
dom
javaComposition
javaExorcism
javaInheritance
javaLexer
javaMultithreading
javaParseLib
javaParser
javaScanner
javaStatic
javaSyb
javaTemplate
javaVisitor
jaxbChoice
jaxbComposition
jaxbExtension
jaxbSubstitution
jdom
jgralab
sax
xom
xpathAPI
yapg
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.