search

gobo-eiffel / gobo

The Gobo Eiffel Project provides the Eiffel community with free and portable Eiffel tools and libraries.
https://sourceforge.net/projects/gobo-eiffel/
Other
59 stars 24 forks source link

[REFACTORING] Split gobo in 2 projects #8

Open gchauvet opened 9 years ago

gchauvet commented 9 years ago

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 :

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

ebezault commented 9 years ago

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 commented 9 years ago

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 https://github.com/gobo-eiffel/gobo/issues/8#issuecomment-131312732.

gchauvet commented 9 years ago

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 :

Moreover, these changes have no functional impact

oligot commented 9 years ago

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 commented 9 years ago

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.