Zips and build script architecture

[tbernau]

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.

[rlaemmel]

We had a similar discussion at one of the recent meetings and I think we all agree on the problem.

I remember these folks to be at the meeting @martinleinberger @avaranovich and @ar7u9o .

@DerDackel would also have an opinion about this.

The proposed solutions (in the filed issue) are also close to what we discussed.

One option we identified is that contributions could be associated with a sort of "dependency" script. This could be JSON. This script could address directories/files from the same physical repo to be included into a distribution such as with a .zip.

This option would necessitate some bigger changes, as we would need to slightly adjust our gitdeps logic and the way module pull101repo works. Most importantly, we would need to establish a best practice so that repos can be effectively added to the virtual 101repo as a whole and that all non-contribution files follow some naming scheme that surely will not cause any conflict or misunderstanding.

Next monday 15.30 we scheduled a 101worker re-engineering meeting which also should go into it.

@ar7u9o has agreed to focus on 101worker improvements for some time.

[avaranovich]

Yes, we could go either for an explicit dependency declaration (in the file); or an implicit (assuming some folder might exist always in the same location)

[rlaemmel]

This is not very high on my priority list.
We really want to get the worker into better shape first.
It's not something anyhow to be deal with at the level of 101simplejava.
I am filing an issue on 101repo and close this one.