Hi vitor I'm sorry but I do not understand your question? can you rephrase it and give an example? Stef On Sat, Dec 30, 2017 at 10:03 PM, Vitor Medina Cruz <vitormcruz@gmail.com> wrote:
Hello Stephane
What if I want to define two projects for the same baseline: both pointing to different groups?
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...> Livre de vÃrus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_camp...>. <#m_-7133589263725951599_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Dec 22, 2017 at 6:15 PM, Stephane Ducasse <stepharo.self@gmail.com
wrote:
From a baseline you can refer to a none github configuration
here is an example from the pillar newpipeline dev branch it shows you both: dependencies on github projects and smalltalkhub
baseline: spec <baseline> spec for: #common do: [ spec blessing: #baseline. spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main/'. spec baseline: 'OSSubprocess' with: [ spec repository: 'github://marianopeck/OSSubprocess:v0.2.5/repository' ];
baseline: 'Mustache' with: [ spec repository: 'github://noha/mustache:v1.0/repository' ];
project: 'Cocoon' with: [ spec className: #ConfigurationOfCocoon; versionString: #stable; repository: 'http://smalltalkhub.com/mc/PharoExtras/Cocoon/main' ];
project: 'JSON' with: [ spec className: #ConfigurationOfJSON; versionString: #stable; repository: 'http://smalltalkhub.com/mc/PharoExtras/JSON/main/' ];
project: 'LightPhaser' with: [ spec className: #ConfigurationOfLightPhaser; versionString: '1.0.2'; repository: 'http://smalltalkhub.com/mc/Pier/LightPhaser/main/' ]; project: 'PetitParser' with: [ spec className: #ConfigurationOfPetitParser; versionString: #stable; loads: #('Tests'); repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ]; project: 'PetitParserTest' with: [ spec className: #ConfigurationOfPetitParser; versionString: #stable; loads: #('Tests'); repository: 'http://www.smalltalkhub.com/mc/Moose/PetitParser/main' ]. spec package: 'Pillar-Cli' with: [ spec requires: #('Pillar-ExporterCore') ]; package: 'Pillar-Cli-PillarVersion' with: [ spec requires: #('Pillar-Cli') ]; package: #'Pillar-ExporterAsciiDoc'
On Thu, Dec 21, 2017 at 3:48 PM, Vitor Medina Cruz <vitormcruz@gmail.com> wrote:
This is mostly true, but ATM you may want to wrap your BaselineOf in a ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration e.g. only Configs show up in the catalog. IIUC, one additional constraint to be aware of (not sure how important it is in practice) is that in the past with mcz repos, one could refer to a specific version of each package, but now you would only be able to specify a version for the whole git repo.
I was about to ask that after reading through Metacello docs â While I find usefull to define groups and dependencies at package level (I need only package A from ThatProject on version 2.6, cool!), I didn't understand why define version at package level.... If many dependencies exists to different versions of different packages belonged to the same project, doesn't that means (or is an indicative) that those packages should be separeted in different projects? I don't think this constraint will be a problem.
On Thu, Dec 21, 2017 at 12:37 PM, Sean P. DeNigris < sean@clipperadams.com> wrote:
CyrilFerlicot wrote
Now I got lost
A ConfigurationOfXyz was doing two things: 1) Declaring the project structure of packages and their dependencies
in a
#baselineXyz: method 2) Tagging specific sets of package versions with meaning symbolic to the project e.g. 1.2 or stable or whatever
CyrilFerlicot wrote
So, you just need Metacello to manage the dependencies... This is what BaselineOf do. You just manage the dependencies part and not the versionning part that is already managed by git.
A BaselineOfXyz is very similar to what configurations did for #1, with a few simplifications (e.g. you don't need to declare the method a "baseline" or specify a repo because you obviously already know the repo because that's where you just got the baseline itself)
CyrilFerlicot wrote
The equivalent of a ConfigurationOf version in now the SHA of a commit or a tag/release of git).
This is mostly true, but ATM you may want to wrap your BaselineOf in a ConfigurationOf (i.e. refer to A with a SHA from B) for tool integration e.g. only Configs show up in the catalog. IIUC, one additional constraint to be aware of (not sure how important it is in practice) is that in the past with mcz repos, one could refer to a specific version of each package, but now you would only be able to specify a version for the whole git repo.
HTH
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html