Break fileIO ApplicationsLib dependency #1138

endJunction · 2016-04-12T21:10:02Z

~~Follow up of #1133.~~ This PR adds only the one commit [DE] Break ApplicationLib dependency.

The dependency is caused by usage of ProjectData::addMesh by XmlGspInterface.
Unfortunately the programming of that class and its parents, the XMLInterface and XMLQtInterface is not as separate as it could be, therefore the current solution can be seen as a quickfix.

Clean solution would be, for example, a separation of the reader and the writer parts of the XMLInterface(s) and to use standalone functions for qt's xml validation.

ogsbot · 2016-04-13T00:31:19Z

Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1449/

ogsbot · 2016-04-13T00:31:26Z

Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1565/

ogsbot · 2016-04-13T00:33:34Z

Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1426/

chleh · 2016-04-13T06:59:24Z

FileIO/XmlIO/Qt/XmlGspInterface.cpp

+XmlGspInterface::XmlGspInterface(
+    GeoLib::GEOObjects& geoObjects,
+    std::vector<MeshLib::Mesh*> const& mesh_vector,
+    std::function<void(MeshLib::Mesh* const)> add_mesh_callback)


move it: && ✅

This prevents the Data Explorer from loading anything except geometries and meshes from a project?!

No, it does not. It is only separating circular dependency of the FileIO and ApplicationsLib. The code for reading is not touched, so everything what was read should behave exactly the same. Only the place where the mesh is added to project has moved.

But if the project file reader has no knowledge of ProjectData but only of GeoObjects + the mesh vector it can only store the related information. I don't doubt that everything works fine at the moment but the next step after reorganising the project file reader would be reading/writing boundary conditions which would then require another parameter, I think? Maybe we could talk about this tomorrow or on friday? (maybe together with Tom as would probably be involved in the next stage)

@rinkk, I can understand your concerns. But if we keep all parts of ProjectData in here, soon FileIO will also depend on ProcessLib (for BCs). Probably that shouldn't be.
Maybe a different approach would be to move some of the parsing code to the DE directory. Do you think, that's feasible?
E.g., the following case checking code probably should be done in some DE class.

if (file_node.compare("geo") == 0)

Maybe at some point one could even use the constructor that is provided with ProjectData to read the *.prj (if we remove std::abort() 😄).
That's at least what I can say after a discussion with @endJunction.

maybe it's not good idea to mix core parts and application layers together. How about provide separate FileIO for ApplicationLib? Current FileIO can be used to provide read and write of basic data, e.g. geo and mesh.

Agree with Nori. If planning a major cleanup of the FileIO/ApplicationsLib separation of the business logic and the actual reading of the data would be a good goal.

We shall have a 30min discussion tomorrow.

or to make it consistent for all libs, we can create FileIo for each lib, e.g. geolib/fileio, meshlib/fileio

chleh · 2016-04-13T07:03:28Z

Last commit (f044d58) looks good. Just make it compile. 👍

rinkk · 2016-04-13T08:38:43Z

As a general question: Why does the DataExplorer need to be decoupled from FileIO?

TomFischer · 2016-04-13T08:49:36Z

FileIO/XmlIO/Qt/XmlGspInterface.cpp

@@ -153,8 +156,9 @@ bool XmlGspInterface::write()
 	}

 	// MSH
-	const std::vector<MeshLib::Mesh*> msh_vec = _project.getMeshObjects();
-	for (std::vector<MeshLib::Mesh*>::const_iterator it(msh_vec.begin()); it != msh_vec.end(); ++it)
+	for (std::vector<MeshLib::Mesh*>::const_iterator it(_mesh_vector.begin());


Why not shorter and more readable: for (auto const* mesh : _mesh_vector)? ✅

endJunction · 2016-04-13T13:30:18Z

The data explorer is not decoupled from FileIO, and actually nothing is decoupled. The circular dependency of ApplicationLib and FileIO is removed.

ogsbot · 2016-04-13T23:55:56Z

Jenkins: OGS-6/Gui/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Mac-PRs/1433/

ogsbot · 2016-04-13T23:56:35Z

Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1454/

ogsbot · 2016-04-13T23:58:35Z

Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1431/

ogsbot · 2016-04-13T23:59:35Z

Jenkins: OGS-6/Gui/Gui-Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Gui-Linux-PRs/1540/

ogsbot · 2016-04-13T23:59:45Z

Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1570/

ogsbot · 2016-04-14T00:08:02Z

Jenkins: OGS-6/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Mac-PRs/1451/

bilke · 2016-04-14T05:30:15Z

Jenkins test this please.

ogsbot · 2016-04-14T05:33:26Z

Jenkins: OGS-6/Gui/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Win-PRs/1432/

ogsbot · 2016-04-14T05:34:19Z

Jenkins: OGS-6/Gui/Gui-Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Gui-Linux-PRs/1541/

ogsbot · 2016-04-14T05:35:03Z

Jenkins: OGS-6/Gui/Mac-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Gui/job/Mac-PRs/1434/

ogsbot · 2016-04-14T05:35:32Z

Jenkins: OGS-6/Linux-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Linux-PRs/1571/

ogsbot · 2016-04-14T05:44:54Z

Jenkins: OGS-6/Win-PRs failed: https://svn.ufz.de:8443/job/OGS-6/job/Win-PRs/1455/

rinkk · 2016-04-14T06:56:37Z

Would it help to create a seperate data holder object for the Data Explorer in, e.g. BaseLib, and keep everything else as it is?
What I need (and what ProjectData originally was) is a container for storing all data relevant to the currently processed project. OGS, and especially the Data Explorer has 20 or more input formats and I would like to keep these seperate from the application itself. In addition, some of said formats can hold geometry or meshes so that a clear dinstinction what library they'd belong to is not necessarily clear.

endJunction · 2016-04-14T13:26:11Z

In the discussion we came to the following two steps:

This PR will be merged in order to be able to use shared libraries asap.
A "project data" structure---different from the current ProjectData---suitable for the data explorer and used by the FileIO will be introduced, thus breaking the dependency of the FileIO and the ApplicationsLib.

norihiro-w · 2016-04-14T14:29:58Z

MathLib/CMakeLists.txt

 )

+if(METIS_FOUND)


TOdo for later, not now: we shouldnt always link metis and lapack just because Cmake could find them. there should be a flag like OGS_USE_METIS.
Noted in https://github.com/ufz/ogs/issues/1142

norihiro-w · 2016-04-14T14:33:44Z

i haven't checked ProjectData stuff, but other changes look nice. just a question: you removed logog dependency from most of libs. is it because BaseLib depends on it?

endJunction · 2016-04-14T14:39:48Z

The logog is removed as dependency from most libs but BaseLib, because the default behaviour for linking is transitive. See cmake doc.

I'm yet figuring out, what the minimum specification is, such that all links fine w/o overhead. But first resolving the circular dependencies bugs.

norihiro-w · 2016-04-14T15:17:05Z

thanks for the explanation!

endJunction · 2016-04-17T16:25:59Z

Update: Initially I thought the EnableSharedLibs PR would be much easier, but first I need to break the circular deps. So this is now a stand-alone PR not based on shared libs but set up as a prerequisite for them.
This is actually reviewed and all previous comments are incorporated.

ogsbot · 2016-04-17T16:28:25Z

Build finished.

norihiro-w · 2016-04-18T05:11:27Z

👍

Adding a callback for adding project meshes and pass additional arguments to XmlGspInterface constructor.

ogsbot · 2020-06-19T12:26:38Z

OpenGeoSys development has been moved to GitLab.

See this pull request on GitLab.

endJunction force-pushed the BreakFileIOApplicationsLibDependency branch 2 times, most recently from 7cf6b60 to f044d58 Compare April 13, 2016 00:26

chleh reviewed Apr 13, 2016
View reviewed changes

TomFischer reviewed Apr 13, 2016
View reviewed changes

norihiro-w reviewed Apr 14, 2016
View reviewed changes

endJunction force-pushed the BreakFileIOApplicationsLibDependency branch from f14124d to 91dfd17 Compare April 17, 2016 16:15

endJunction added the please review label Apr 17, 2016

chleh added please rebase and removed please review labels Apr 19, 2016

endJunction added 2 commits April 19, 2016 11:31

[DE] Break ApplicationLib dependency.

1812543

Adding a callback for adding project meshes and pass additional arguments to XmlGspInterface constructor.

[IO] Use range-for-loop.

00c37bc

endJunction force-pushed the BreakFileIOApplicationsLibDependency branch from 91dfd17 to 00c37bc Compare April 19, 2016 09:32

endJunction merged commit 5ab2033 into ufz:master Apr 19, 2016

endJunction deleted the BreakFileIOApplicationsLibDependency branch April 19, 2016 10:03

endJunction removed the please rebase label Apr 19, 2016

rinkk mentioned this pull request Apr 25, 2016

Data explorer project data holder #1162

Merged

		)

		if(METIS_FOUND)

Break fileIO ApplicationsLib dependency #1138

Break fileIO ApplicationsLib dependency #1138

Conversation

endJunction commented Apr 12, 2016 • edited Loading

ogsbot commented Apr 13, 2016

ogsbot commented Apr 13, 2016

ogsbot commented Apr 13, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chleh commented Apr 13, 2016

rinkk commented Apr 13, 2016

Choose a reason for hiding this comment

endJunction commented Apr 13, 2016

ogsbot commented Apr 13, 2016

ogsbot commented Apr 13, 2016

ogsbot commented Apr 13, 2016

ogsbot commented Apr 13, 2016

ogsbot commented Apr 13, 2016

ogsbot commented Apr 14, 2016

bilke commented Apr 14, 2016

ogsbot commented Apr 14, 2016

ogsbot commented Apr 14, 2016

ogsbot commented Apr 14, 2016

ogsbot commented Apr 14, 2016

ogsbot commented Apr 14, 2016

rinkk commented Apr 14, 2016

endJunction commented Apr 14, 2016

Choose a reason for hiding this comment

norihiro-w commented Apr 14, 2016

endJunction commented Apr 14, 2016

norihiro-w commented Apr 14, 2016

endJunction commented Apr 17, 2016

ogsbot commented Apr 17, 2016

norihiro-w commented Apr 18, 2016

ogsbot commented Jun 19, 2020

endJunction commented Apr 12, 2016 •

edited

Loading