[REFACTORING] Split gobo in 2 projects

[gchauvet]

Dear Gobo team,

Gobo contains generic clusters and tools in the same projet. I think it would be interesting to split gobo in two distinct projects :

• gobo-clusters: contains libraries (Argument, Time ...) ;
• gobo-devkit: contains eiffel tools (gec, geyacc ...)

I'll fork the project to test the feasibility of this ticket

[ebezault]

My plan is to go even further: I will create one Git repository per library (containing the code, its examples, its tests and its doc). People who want to use regular expressions don't necessarily need to get the XML library.
My objective is to finish migrating to void-safety (only half of the xslt part of the XML library remains to be done), and then split the Gobo repository into smaller ones.
It's feasible. But I will need to use all my Git skills in order to pull the history of each library in its new repository (knowing that the code will come from various folders: library/examples/...).

[schoelle]

Please don't - there is absolutely no problem on any modern system to
have a few classes or binaries lying around you don't use.

But keeping everything versioned and consistent is a nightmare.

I would strongly vote for keeping GOBO as a single GIT repository.

Bernd

On 15/08/15 08:32, Eric Bezault wrote:

My plan is to go even further: I will create one Git repository per
library (containing the code, its examples, its tests and its doc).
People who want to use regular expressions don't necessarily need to
get the XML library.
My objective is to finish migrating to void-safety (only half of the
xslt part of the XML library remains to be done), and then split the
Gobo repository into smaller ones.
It's feasible. But I will need to use all my Git skills in order to
pull the history of each library in its new repository (knowing that
the code will come from various folders: library/examples/...).

—
Reply to this email directly or view it on GitHub
#8 (comment).

[gchauvet]

I'm not convinced by your argument that keeping all classes in the same project because this is not a problem to keep classes or binaries lying around.
In my point of view, splitting gobo in two parts will improve maintainability process on some points :

• Improve clusters visibility (e.g some classes in "library/tools" cluster are really specific to Gobo tools, no interest to keep them in the "main" Gobo library);
• Simplify project structure & documentation.

Moreover, these changes have no functional impact

[oligot]

I'm also for the split.
@pgcrism did the same for the SAFE Project when it was moved from Sourceforge to Github.
I don't remember if the history was kept: maybe we should just ask him...

[ebezault]

There are several reasons I want to split the Gobo repository into several repositories, one per library.

The first one is that there are some libraries in there which have been contributed by people who either lost interest in Eiffel or just don't want to maintain their libraries anymore. So I agree that having a single repository helps keeping compatibility. But guess who has to do the job? My hope is that it will be easier for people who are too shy to contribute to the whole Gobo project to make the first step and contribute to a smaller project.

Also, many times in the past I heard about people not willing to use some part of the Gobo libraries just because they didn't need everything. For example they didn't want to use the regexp classes because they did not need the XML classes. I can understand that people might want to get everything, but some don't. Having one repository per library allows people to get just what they want, and still have a whole Gobo package which includes everything (from the different repos, using submodules for example) for the others.

Typically, people are not looking for the Gobo package. They are looking for a library which will help them in their work. For that, there are some pages on the Web listing available Eiffel libraries per functionalities. Because Gobo contains many libraries, it is often not listed in the right places in these lists. I hope that having one repo per library will make things clearer as to what libraries are available. In particular if we want the Github EiffelHub account to regroup all available Eiffel libraries (through forks), or if some Eiffel libraries distributions (using iron or not) want to organize libraries per functionalities (there has been some discussions about that on ISE's mailing list in the past), things shold be easier that way.

And it's not just about Gobo. During the past few years my wish has been that ISE's libraries (such as EiffelVision) be in repositories independent of EiffelStudio. As mentioned above, it would make it easier to create packages including Eiffel libraries independently of any Eiffel compiler or other Eiffel library writers. For example I want to be able to use EiffelVision with the Gobo compiler without having to download the whole EiffelStudio package.