Projects vs Dependencies View of Configuration

Orthogonally to the process open dev / release, we have the notion of
two different uses of Configurations.
I call them the Projects vs the Dependencies style.

Let us look at these two uses. I will take an example that is not in
Moose but we can see the exact
same problems in Moose.

There is a parallel with XMLSupport (a group loading XMLparser, writer,
SIXX, Pastell....
and XMLParser, XMLWriter

     XMLSupport is a "Project" configuration: it is a convenient way to
group and load (in particular it expresses
     dependencies to clients of XML) so the relation is not I load Sixx
because I dependent on it.
     More I load it because I want to optionally offer it.

     XMLParser is a "Dependencies" configuration: to parse XML we need
OrderedPreservingDictionary, Bitmap...
     if we do not load them we cannot get XMLParser working.

Why this difference is important: When you want to build a tool using
the XMLParser you do not want to get SIXX. pastell
when you do not need it.

Based on this analysis we see that

     PetitParser project, MooseIDE project are Projects
     while
     PetitParser (the package), MooseCore (the package) are dependencies
configuration.

Now the problem is that we do not have a simple way to express the
dependencies at the level of a package.
Because when coding the XMLParser package you would write that it
depends on SIXX.

Christophe is working on a prototype to get package dependencies
expressed at the package level
and he will present that at ESUG but this is not ready to use.

Now we could (but this is a lot of work) add a
configuration"Dependencies" to any package. These dependencies would be
really simple. We already have that for Traverser, Merlin, RoelTyper and
many others.

This way we could have
     - Project configurations
     - Dependencies configurations

Now I would like to see is do we do it? Would be good to have different
names to identify these configurations clearly.
Or at least have a description that clearly say it.

Stef




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Doru

I have the impression that there is not one single MooseEngines
configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may
be both or none and just XML.
So

I have one hypothesis: if  "dependencies" configuration are handled at
the package level it should be easier to build
as many as we want as "Project" configuration

Now the experience I would like to do is the following:

- create one dependencies configuration for each package (this
configuration should be as small as possible)
     - repo
     - dependencies to projects
     - dependencies to package

- then we define a couple of "useful" project cofniguration One being
moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Ok we are in sync.
I should find a way to automatically create the configuration I want and populate the MooseMetacelloConfigurationRepositories.

Stef

Hi Stef,

I did not have enough time to follow in details the conversation. I will try again in a couple of days, so in the meantime, please take my reply as a draft :).

I like the distinction between "Project" and "Dependencies". Also, any Project configuration should be seen as a convenience. In these terms, the ConfigurationOfMoose has to become a Project configuration.

Every engine we have, except for Moose Core, has its own configuration, and most of them are pretty much a Project configuration. So, from this point of view, anyone can easily build his own Project using them.

When I mentioned the MooseEngines configuration, I referred to a Project configuration to be included in the ConfigurationOfMoose that we support as a whole. At this moment, this should include the following:

- Roassal2 & co

- MooseAlgos

- PetitParser

- Fame + Metanool

- Glamour

- MooseCore (this does not exist yet)

- XMLReader

The term engine comes from this diagram:

http://www.themoosebook.org/book/introduction/nutshell

Then, we should have a ConfigurationOfFAMIX that includes FAMIX entities + extensions, importers. I see it as a Dependencies configuration.

Then, we should have ConfigurationOfMooseFinder which includes some basic tools like the MooseFinder and the MetaBrowser. This is a Dependency configuration. On top of that we should also have a ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and ConfigurationOfMooseFinder and that includes all the visualizations and the ui extensions. This will be a bit hairy to do but I think it would be worth it.

If we move in this direction, the ConfigurationOfMoose will finally become empty of explicit Monticello packages.

Cheers,

Doru

On Mon, Jun 30, 2014 at 7:12 PM, stepharo <[hidden email]> wrote:

Doru

I have the impression that there is not one single MooseEngines configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may be both or none and just XML.
So

I have one hypothesis: if  "dependencies" configuration are handled at the package level it should be easier to build
as many as we want as "Project" configuration

Now the experience I would like to do is the following:

- create one dependencies configuration for each package (this configuration should be as small as possible)
    - repo
    - dependencies to projects
    - dependencies to package

- then we define a couple of "useful" project cofniguration One being moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

I thought a bit about the terms "Project" and "Dependencies". Given that it is likely that these terms will be used in other contexts outside of our refactoring project, perhaps we could spend a bit of time to tune them.

I think both Project and Dependencies are highly overloaded terms and because of that it will be easy to create confusion. For example, imagine this sentence:

"we are working on a project to refactor the dependencies from a project configuration to make it contain only depencency configurations".

So, I would like to propose another set:

"Project" -> "Assembly"

"Dependencies" -> "Structure/Structural"

With the new terms, this would become:

"we are working on a project to refactor the dependencies from an assembly configuration to make it contain only structural configurations".

What do you think?

I like dependency because it express the need to work :) but I'm ok for assembly.

Doru

On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <[hidden email]> wrote:

Hi Stef,

I did not have enough time to follow in details the conversation. I will try again in a couple of days, so in the meantime, please take my reply as a draft :).

I like the distinction between "Project" and "Dependencies". Also, any Project configuration should be seen as a convenience. In these terms, the ConfigurationOfMoose has to become a Project configuration.

Every engine we have, except for Moose Core, has its own configuration, and most of them are pretty much a Project configuration. So, from this point of view, anyone can easily build his own Project using them.

When I mentioned the MooseEngines configuration, I referred to a Project configuration to be included in the ConfigurationOfMoose that we support as a whole. At this moment, this should include the following:

- Roassal2 & co

- MooseAlgos

- PetitParser

- Fame + Metanool

- Glamour

- MooseCore (this does not exist yet)

- XMLReader

The term engine comes from this diagram:

http://www.themoosebook.org/book/introduction/nutshell

Then, we should have a ConfigurationOfFAMIX that includes FAMIX entities + extensions, importers. I see it as a Dependencies configuration.

Then, we should have ConfigurationOfMooseFinder which includes some basic tools like the MooseFinder and the MetaBrowser. This is a Dependency configuration. On top of that we should also have a ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and ConfigurationOfMooseFinder and that includes all the visualizations and the ui extensions. This will be a bit hairy to do but I think it would be worth it.

If we move in this direction, the ConfigurationOfMoose will finally become empty of explicit Monticello packages.

Cheers,

Doru

On Mon, Jun 30, 2014 at 7:12 PM, stepharo <[hidden email]> wrote:

Doru

I have the impression that there is not one single MooseEngines configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may be both or none and just XML.
So

I have one hypothesis: if  "dependencies" configuration are handled at the package level it should be easier to build
as many as we want as "Project" configuration

Now the experience I would like to do is the following:

- create one dependencies configuration for each package (this configuration should be as small as possible)
    - repo
    - dependencies to projects
    - dependencies to package

- then we define a couple of "useful" project cofniguration One being moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Doru

what about Unit and Assembly

Stef

On 1/7/14 09:45, Tudor Girba wrote:

Hi,

I thought a bit about the terms "Project" and "Dependencies". Given that it is likely that these terms will be used in other contexts outside of our refactoring project, perhaps we could spend a bit of time to tune them.

I think both Project and Dependencies are highly overloaded terms and because of that it will be easy to create confusion. For example, imagine this sentence:

"we are working on a project to refactor the dependencies from a project configuration to make it contain only depencency configurations".

So, I would like to propose another set:

"Project" -> "Assembly"

"Dependencies" -> "Structure/Structural"

With the new terms, this would become:

"we are working on a project to refactor the dependencies from an assembly configuration to make it contain only structural configurations".

What do you think?

I like dependency because it express the need to work :) but I'm ok for assembly.

Doru

On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <[hidden email]> wrote:

Hi Stef,

I did not have enough time to follow in details the conversation. I will try again in a couple of days, so in the meantime, please take my reply as a draft :).

I like the distinction between "Project" and "Dependencies". Also, any Project configuration should be seen as a convenience. In these terms, the ConfigurationOfMoose has to become a Project configuration.

Every engine we have, except for Moose Core, has its own configuration, and most of them are pretty much a Project configuration. So, from this point of view, anyone can easily build his own Project using them.

When I mentioned the MooseEngines configuration, I referred to a Project configuration to be included in the ConfigurationOfMoose that we support as a whole. At this moment, this should include the following:

- Roassal2 & co

- MooseAlgos

- PetitParser

- Fame + Metanool

- Glamour

- MooseCore (this does not exist yet)

- XMLReader

The term engine comes from this diagram:

http://www.themoosebook.org/book/introduction/nutshell

Then, we should have a ConfigurationOfFAMIX that includes FAMIX entities + extensions, importers. I see it as a Dependencies configuration.

Then, we should have ConfigurationOfMooseFinder which includes some basic tools like the MooseFinder and the MetaBrowser. This is a Dependency configuration. On top of that we should also have a ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and ConfigurationOfMooseFinder and that includes all the visualizations and the ui extensions. This will be a bit hairy to do but I think it would be worth it.

If we move in this direction, the ConfigurationOfMoose will finally become empty of explicit Monticello packages.

Cheers,

Doru

On Mon, Jun 30, 2014 at 7:12 PM, stepharo <[hidden email]> wrote:

Doru

I have the impression that there is not one single MooseEngines configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may be both or none and just XML.
So

I have one hypothesis: if  "dependencies" configuration are handled at the package level it should be easier to build
as many as we want as "Project" configuration

Now the experience I would like to do is the following:

- create one dependencies configuration for each package (this configuration should be as small as possible)
    - repo
    - dependencies to projects
    - dependencies to package

- then we define a couple of "useful" project cofniguration One being moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories

Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--

www.tudorgirba.com

"Every thing has its own flow"

--

www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Some alternatives for consideration...

[1] Solution - A solution contains projects, and defines the available configurations
[2] Artefact; Component; Target; Product; System

[1] http://industriousone.com/topic/project-dependencies-and-exclusions-configuration 
[2] http://www.intccm.org/downloads/iNTCCM_Foundation_Glossary_200707.pdf

cheers -ben

Tudor Girba wrote:

I like that!

Doru

On Tue, Jul 1, 2014 at 1:22 PM, stepharo <[hidden email]> wrote:

Doru

what about Unit and Assembly

Stef

On 1/7/14 12:17, stepharo wrote:

On 1/7/14 09:45, Tudor Girba wrote:

Hi,

I thought a bit about the terms "Project" and "Dependencies". Given that it is likely that these terms will be used in other contexts outside of our refactoring project, perhaps we could spend a bit of time to tune them.

I think both Project and Dependencies are highly overloaded terms and because of that it will be easy to create confusion. For example, imagine this sentence:

"we are working on a project to refactor the dependencies from a project configuration to make it contain only depencency configurations".

So, I would like to propose another set:

"Project" -> "Assembly"

"Dependencies" -> "Structure/Structural"

With the new terms, this would become:

"we are working on a project to refactor the dependencies from an assembly configuration to make it contain only structural configurations".

What do you think?

I like dependency because it express the need to work :) but I'm ok for assembly.

Doru

On Tue, Jul 1, 2014 at 9:33 AM, Tudor Girba <[hidden email]> wrote:

Hi Stef,

I did not have enough time to follow in details the conversation. I will try again in a couple of days, so in the meantime, please take my reply as a draft :).

I like the distinction between "Project" and "Dependencies". Also, any Project configuration should be seen as a convenience. In these terms, the ConfigurationOfMoose has to become a Project configuration.

Every engine we have, except for Moose Core, has its own configuration, and most of them are pretty much a Project configuration. So, from this point of view, anyone can easily build his own Project using them.

When I mentioned the MooseEngines configuration, I referred to a Project configuration to be included in the ConfigurationOfMoose that we support as a whole. At this moment, this should include the following:

- Roassal2 & co

- MooseAlgos

- PetitParser

- Fame + Metanool

- Glamour

- MooseCore (this does not exist yet)

- XMLReader

The term engine comes from this diagram:

http://www.themoosebook.org/book/introduction/nutshell

Then, we should have a ConfigurationOfFAMIX that includes FAMIX entities + extensions, importers. I see it as a Dependencies configuration.

Then, we should have ConfigurationOfMooseFinder which includes some basic tools like the MooseFinder and the MetaBrowser. This is a Dependency configuration. On top of that we should also have a ConfigurationOfFAMIXFinder that depends on ConfigurationOfFAMIX and ConfigurationOfMooseFinder and that includes all the visualizations and the ui extensions. This will be a bit hairy to do but I think it would be worth it.

If we move in this direction, the ConfigurationOfMoose will finally become empty of explicit Monticello packages.

Cheers,

Doru

On Mon, Jun 30, 2014 at 7:12 PM, stepharo <[hidden email]> wrote:

Doru

I have the impression that there is not one single MooseEngines configuration and that we will end up in the same
fat configuration. Because may be we want petitParser may be Smacc may be both or none and just XML.
So

I have one hypothesis: if  "dependencies" configuration are handled at the package level it should be easier to build
as many as we want as "Project" configuration

Now the experience I would like to do is the following:

- create one dependencies configuration for each package (this configuration should be as small as possible)
    - repo
    - dependencies to projects
    - dependencies to package

- then we define a couple of "useful" project cofniguration One being moose IDE.
- group such configurations into a MooseMetacelloConfiguration repositories

Stef
_______________________________________________

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>Now the problem is that we do not have a simple way to express the
>dependencies at the level of a package.

AFAIK, we can express that pretty good with groups and
package requires in Metacello.

Stephan


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stefan

I know about groups :) pretty well in fact. I did not put my name on the
metacello chapter. I wrote it.
Now the point is that groups influenced people to provide Assembly
configuration with many possible
uses and in reality this is difficult to propose solutions that work for
everybody.

So the idea behind distinguishing between Units and Assembly is that
     - all Unit should express THEIR and only THEIR dependencies  and
not potential usage loading unrelated tools (Ex Moose Algos in Moose)
     - based on well described Units, we can build after Assembly
configuration covering common practices but also specific one.

This is like that in linux you have packages (units) and virtual package
(assembly).

I think that doru and me are on the exact same wave length. I will sit
with christophe this afternoon to see how we can
script the generation of Units based on some of our current ASSEMBLY.
Stef
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev