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.

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?

• We would need to assemble contribution-specific build files for gradle.
• What else?

If @DerDackel also has an opinion on / time for this, please comment as well.

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.

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:

• Retrieve jars that are needed.
• Derive source files that can be build.

README.md of this repo should be used to document everything.

.gitignore should be maintained to be useful for this style of repo.

Just gradle built and eclipsed javaSyb.
Now I see a "bin" directory.
It does not even disappear after "../gradlew clean".

In addition to the naming issues, noted in another issue, these tests don't make much sense as such:

https://github.com/101companies/101simplejava/tree/master/contributions/javaSyb/src/test/java/org/softlang/company/tests

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.

Package prefix

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.

Use of subpackages

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:

• "model" makes sense when we want to modularize the "object model".
• "view" and "controller" for those components of contributions with GUI.
• ...

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.

Tests

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.

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.

• (1.) Students wouldn't know Gradle; they can't help themselves.
• (2.) Build rules cannot be discovered as they are factored to the top.

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:

• (3.) ./gradlew eclipse automated generation of eclipse files but doesn't test that Eclipse would be happy.
• (4.) Platform issues; we do development mostly on Mac OS X / Linux but there are apparently Windows users.

So we need to solve both problems: 3. and 4. but automated testing (and address 2.).

Ralf

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.

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

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.

Loads of them I run into.
Unless this is about generated code, such unused imports are not wanted.

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")?

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?

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.

We should use "Acme Corporation" rather than "meganalysis".
http://en.wikipedia.org/wiki/Acme_Corporation

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.

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.

• These rules need to be presented somewhere.
• The object models need to be removed from the repo.
• The derivation of the object models needs to be added to the build process.

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:

• The Headline
• The link to 101wiki

When doing the README.md's, please take these considerations into account:

• Please make sure to use the current headlines as shown on 101wiki as opposed to what's in the current README.md files, which is often outdated.
• Please make sure to use the right URL to 101wiki.
• When copying and pasting headlines from the wiki, please remove "Language:" and "Technology:". This was also done in the example. Other namespaces do not occur in headlines. If you find any other namespaces, please let me know.

@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?

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.

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:

• tests (test) for JUNit tests
• behavior for "behavioral" concerns
• features for "features"
• model for the "object model"

A tentative proposal for a standardization and simplification follows:

• Use as few subpackages as possible without incurring proper drawbacks.
• Decide on whether separating out tests into a subpackage is really worth it.
• Do not use "behavior" and "features" because these names are confusing.

http://tomee.apache.org/

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)?

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".

@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

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.

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:

• Relationships between contributions should be properly described. Currently, "similarities" are only mentioned in the running text of the old "Motivation" paragraph.
• To better respond to the expected standardization of building and testing for this repo, we should simplify and standardize the "Usage" sections.
• To align with changes due to standardized package structure, we should simplify and standardize the "Architecture" sections.

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

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.

Hi Matthias,

please integrate @DerDackel 's new contribution:

#45

Please see whether you can run it.

Also, please create a wiki page.

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.

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.

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?

Not much is needed, but some basic info about these things:

• How to build/test/run/eclipse-lize the contributions individually or collectively?
• What approach is used with pointers to used tools?

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 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.

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.

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.

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:

• Using directories (like inputs) fails
• Using the working directory succeeds

On Ubuntu:

• Using the working directory fails

The problem seems to occur for others (internet), yet I found no solution or explanation.

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.

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.

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.

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.

Should testNegative

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).

So we could do a concurrent implementation using this:

http://akka.io/

I guess we can start from the existing thread-based implementation and see how we can leverage akka instead.

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.

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?

Demonstrate DOM-based validation.

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