Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

access to roassal configuration
by stepharo 02 Jul '14

02 Jul '14

Hi alex the roassal configuration is old and the versions are outdated. If you give me access I will fix them nicely. Else I will fork it. Stef

3 8

Projects vs Dependencies View of Configuration
by stepharo 02 Jul '14

02 Jul '14

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

3 10

refactoring moose-chef dependency traits
by Usman Bhatti 02 Jul '14

02 Jul '14

Name: Famix-Core-usmanbhatti.237 Author: usmanbhatti Time: 1 July 2014, 4:15:42.620954 pm UUID: a3822a71-e6f7-4d21-abc1-bab82b31b9dc Ancestors: Famix-Core-MirceaLungu.236 refactoring the common behavior to query dependencies in a paradigm agnostic way and creating a new trait to compute dependencies of object-oriented entities. This refactoring was necessary to reuse moose chef queries for non object oriented systems that do not have inheritance. Tests are green. usman

2 1

About roassal2
by stepharo 02 Jul '14

02 Jul '14

Hi alex Why Roassal depends on FuelMetalevel? - having the stable as a baseline is not nice because clients will cry big times. - there is no correct version and it would be good to use versionner to manage it and to release some versions from time to time. Now that roassal2 is out it is importnt that people can build on versions if they want. Typically Synectiquers should really pay attention to this "detail" - unique version is pure junk and looks like from a tutorial so I can clean it. - versionDevelopment: introduce a dependencies to FuelMetalevel. I do not have access to it but I can clean it fast. Else I will fork it. Stef

4 12

code completion?
by Alexandre Bergel 01 Jul '14

01 Jul '14

Apparently it is disabled. Is this intended? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 3

Re: Projects vs Dependencies View of Configuration
by Stephan Eggermont 01 Jul '14

01 Jul '14

>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

1 0

Re: Revert of configuration changes neeeded
by Stephan Eggermont 01 Jul '14

01 Jul '14

Stef wrote: >I fixed them and they should work. Thank you. Stephan

1 0

Re: Revert of configuration changes neeeded
by Stephan Eggermont 01 Jul '14

01 Jul '14

My assumption is that in changing configurations, we don't break older versions and versions for other platforms. Sometimes we only fix things for specific (newest) versions, but otherwise keep them intact. We've started looking at the changes made, and that principle is not respected. Please note that at the moment Versioner cannot reliably be used to version configurations that use platform tags. The change in ConfigurationOfXMLWriter broke the build. Diego reverted the change. Stephan

2 1

Point one
by stepharo 01 Jul '14

01 Jul '14

Hi today we brainstormed and I will send a sequence of emails to discuss what we decided and started to do. One of our goal is to check if we can use versionner to manage all the configurations. It looks possible. The first things we started to do is - make sure that all the configurations of external libraries are correctly defined. In particular we made sure that a version does not depend on a stable one but on a version specific. - We think that Moose should not depend on baseline of external tools, because we need real reproduceability. - We started to produce configurations with versionner that do not depend on stable but on exact versions. - I will continue to see if we can use Versionner because it would simplify the release. Stef

4 15

Revert of configuration changes neeeded
by Stephan Eggermont 01 Jul '14

01 Jul '14

I've taken a look at the changes made to the configurations, and they are broken. All need to be reverted Stephan

3 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev