Continue discussion on library structure

[modelica-trac-importer]

Modified by dietmarw on 3 Jul 2008 17:49 UTC I file this ticket to get back to the library structure discussion started at the 56th Modelica Design Meeting in March 2008, in Bielefeld.

The first thing I did was transforming the [attachment:ticket:89:NotesOnLibraryStructure.txt notes taken by Michael Tiller] into a nice wikipage wiki:Documents/NotesOnLibraryStructure ([wiki:Documents/NotesOnLibraryStructure?format=pdf click here] to download the generated pdf-version of that page).

I hope I got the indentation right...if not or if you like to enhance that document then feel free to do so but add also a comment about the changes to this ticket.

So now it seems that the discussion was not continued since then. By going through the notes right at the end ([wiki:Documents/NotesOnLibraryStructure#notes link to that section]) I think the three remaining issues are:

Quote from notes: ::

• Mike raised the issue and Modelon seemed to agree that management of packages is complicated by the fact that must be "flattened at the top". Martin will send out the minutes of the meeting where this was previously discussed.
• There was a discussion about what constraining classes should be.
• One issue that Mike brought up would be cases where multiple behaviors use the same data.

So for the first item it would be nice if Martin can find those minutes and maybe attach them to this ticket.

---

Reported by dietmarw on 3 Jul 2008 17:46 UTC I file this ticket to get back to the library structure discussion started at the 56th Modelica Design Meeting in March 2008, in Bielefeld.

The first thing I did was transforming the [attachement:ticket:89:NotesOnLibraryStructure.txt notes taken by Michael Tiller] into a nice wikipage wiki:Documents/NotesOnLibraryStructure ([wiki:Documents/NotesOnLibraryStructure?format=pdf click here] to download the generated pdf-version of that page).

I hope I got the indentation right...if not or if you like to enhance that document then feel free to do so but add also a comment about the changes to this ticket.

So now it seems that the discussion was not continued since then. By going through the notes right at the end ([wiki:Documents/NotesOnLibraryStructure#notes link to that section]) I think the three remaining issues are:

Quote from notes: ::

• Mike raised the issue and Modelon seemed to agree that management of packages is complicated by the fact that must be "flattened at the top". Martin will send out the minutes of the meeting where this was previously discussed.
• There was a discussion about what constraining classes should be.
• One issue that Mike brought up would be cases where multiple behaviors use the same data.

So for the first item it would be nice if Martin can find those minutes and maybe attach them to this ticket.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/89

[modelica-trac-importer]

Modified by dietmarw on 3 Jul 2008 17:49 UTC

[modelica-trac-importer]

Modified by msielemann on 4 Jul 2008 05:55 UTC

[modelica-trac-importer]

Modified by dietmarw on 4 Jul 2008 08:19 UTC

[modelica-trac-importer]

Modified by dietmarw on 4 Jul 2008 08:49 UTC

[modelica-trac-importer]

Comment by mtiller on 11 Jul 2008 18:28 UTC I'd like to add a note here about the way libraries are assembled. There has been an ongoing discussion of whether a top-level library should necessary be considered a single entity or whether it should be possible to consider it as a collection of loosely related packages.

One argument is that a library like "Modelica" is a single entity and that breaking it up into pieces doesn't make that much sense. This is partly because there are dependencies between sub-libraries and partly because there is some concern that people will "break" the library by injecting their own fragments into its hierarchy.

The other argument is that treating libraries as a single entity is unwieldy and prevents the ability to associated some kind of umbrella brand with different libraries. Proponents of this argument are in favor of semantics more like those in Java where each 'package' is essentially a stand-alone entity with possible (explicit and easy to determine) dependencies on other packages.

I myself am very firmly in the later. I feel that the Java model is well proven, easily understood and allows for much better scalability and model management. In my mind the following changes would really improve the ability for library developers:

• All packages are implicitly encapsulated (avoiding unexpected or implicity dependencies)
• Packages need not be grouped together in one place on the file system. This would allow each library to be developed as a stand-alone entity and make it much easier to package subsets of a given library.

• We should define a common format like the "jar/tar" format for packaging not only multiple libraries together but also the "resources" associated with those libraries as well (e.g. data files, images) so that they can be referenced in the models without regard to file system location (i.e. referenced, as in Java, with respect to the package they are associated with).

  All of these suggestions have been proven out in Java and would really help library developers to manage large collections of models much better than they are now.

[modelica-trac-importer]

Comment by dietmarw on 12 Jul 2008 08:12 UTC Replying to [comment:5 mtiller]:

* All packages are implicitly encapsulated (avoiding unexpected or implicity dependencies) * Packages need not be grouped together in one place on the file system. This would allow each library to be developed as a stand-alone entity and make it much easier to package subsets of a given library. * We should define a common format like the "jar/tar" format for packaging not only multiple libraries together but also the "resources" associated with those libraries as well (e.g. data files, images) so that they can be referenced in the models without regard to file system location (i.e. referenced, as in Java, with respect to the package they are associated with).

Here is another thought: What about using a mechanism similar to the Python way of providing Python packages on some kind of repository (e.g. The Cheese Shop in case of Python). One could package her Modelica library stating the external dependencies which in turn are installed automatically from the repository (e.g. xxx.modelica.org) or can be provided locally (in case of network unavailability) using a tool similar to easy_install (part of setuptools).

For example, AFAICT the Powertrain library (PTl) depends on the new Vehicle Interfaces library (VIl) (which will be provided by the MA). The creators of the PTl now don't need to statically package the VIl but can simply provide the link to the 'Modelica Cheese Shop'. The nice thing about the easy_install script is that you can define a certain package version and other options (see here). You can also install packages directly using a subversion source directory. I think such functionality would be a great improvement when it comes to library management.

[modelica-trac-importer]

Comment by dietmarw on 8 Aug 2008 15:55 UTC Replying to [comment:5 mtiller]:

* We should define a common format like the "jar/tar" format for packaging not ...

How about calling it "mar" for Modelica Archive ;-)

[modelica-trac-importer]

Comment by dietmarw on 16 Aug 2008 08:20 UTC Johan, looking at the agenda of the 58^th Modelica Design Meeting:

• Guidelines/rules to structure Modelica libraries. Continue discussion from previous meeting (Johan A. can you provide a draft of a proposal, as you planned it???)

I guess that this is related to this ticket? If yes we should change the milestone to [milestone:Design58 Design58] (and assign it to you???) right?

[modelica-trac-importer]

Comment by dietmarw on 8 Sep 2008 14:04 UTC As this is now actually discussed at Design58 I'm adjusting the milestone hereby.

[modelica-trac-importer]

Comment by mtiller on 9 Sep 2008 16:19 UTC Mike created a more detailed analysis of the resource distribution issue on the ResourceDistribution page.

[modelica-trac-importer]

Comment by mtiller on 15 Dec 2008 17:15 UTC I've created a separate ticket for the resource bundling discussion. It is ticket #132.

[modelica-trac-importer]

Comment by dietmarw on 20 Feb 2009 15:51 UTC closing milestone:Design60 and postponing this discussion to the next post 3.1 Design Meeting

[modelica-trac-importer]

Modified by dietmarw on 19 Nov 2009 16:35 UTC

[modelica-trac-importer]

Modified by dietmarw on 16 Nov 2014 00:29 UTC

[modelica-trac-importer]

Changelog removed by dietmarw on 16 Nov 2014 00:29 UTC

[modelica-trac-importer]

Comment by dietmarw on 19 Dec 2014 07:01 UTC Ticket retargeted after milestone closed

[modelica-trac-importer]

Comment by dietmarw on 20 Dec 2016 14:01 UTC Unhide for GitHub transition.