Hi all,
I'm trying to install Magritte and Seaside on Pharo7.
I have installed Seaside with:
Metacello new
baseline:'Seaside3';
repository: 'github://SeasideSt/Seaside:master/repository';
load
and then I've tried to install Magritte with:
Metacello new
repository: 'github://magritte-metamodel/magritte';
baseline: 'Magritte';
load
but I'm getting a conflict with the installed version of package
BaselineOfGrease.
I'm new to Pharo and I don't know how to resolve these kind of conflicts.
Any help would be greatly appreciated.
Kindly,
Sebastian
Hi All - Lately I've updated the table-of-contents link in Pier to visit its parent, not the page being renderered, and it's resolved one issue, but writing the code to GitHub has been challenging.
The class PRTocRenderer is in Pier-Seaside-Visitors, however what is listed in Iceberg is pier-seaside (lowercase and missing visitors). When committing changes, it doesn't to leave Iceberg. The steps and pictures are at:
http://myborden.com/pier/john-c-borden/updates/committing-pier-seaside-in-i…
Is this problem caused by the package name being lowercase, or that it is missing the suffix? Any suggestions on how to fix this?
Thanks,
John
Hi all,
I am afraid that I do not know how to put this in a smaller mail, as I believe a bit of historical background and theoretical background is in needed. But maybe I should split this in 2 mails. First the background. You can skip this mail, if you believe you know all this.
Before we used git, there was a lot of discussion how to to proper software configuration management for our open source projects. One of the major problems was that a new version of a package was usually a development versions, and might break the build and also other projects. Metacello allowed us to solve this problem. As Dale always has pointed out, not all projects are the same, so there is not one solutions fits all. This was reflected in Metacello, that supported most (if not all) of these strategies. But just as we agreed on using MIT for our licensing the open source projects, in the end there was agreement on how to do make configurations.
There were baselines, that described what packages were used and where these packages could be found
- no version information was included here, only the dependencies
There were concrete versions, that described what versions of packages belonged together
- all versions where explicit, also the versions of the projects used.These versions were frozen.
We defined symbolic versions, that described on a meta level the versions (releases and stable version)
- these versions where aliases to a concrete version, that could change over time, to include bug fixes.
By moving our projects to GIT we could use the version management of GIT, and needed less of Metacello.
In GIT we have good branch support, something that lacked in Metacallo. Using git means, it is no longer necessary to define versions in Metacello. Each concrete or symbolic version can be indicated by either tag, or a branch.
There is one special branch “master” that is implicitly the stable version. This is supported by git tools, i.e. before merging a pull request in a branch, one can build this pull request, verifying that it s indeed a stable version, and when this was in error, it is easy to revert the change, but leaving this change available for further development.
For long term support of releases, one can create a branch (preferable recognisable by calling it isomething like masterv2.3 or release2.3), and merge bug fixes into this branch when applicable.
Also in GIT it is possible for each user to fork a project at a certain version, allowing everyone to freeze a certain project to a certain version, and still be able to get updates on changes, and giving the option to easily merge this change or bug fix into their fork, or leave this change out.
Finally there is a method to refer to a specific version in GitHub by including to the tag/branch name in the url: <git-url>//<projectname>[:<branchname>]/<source-dir>. This branch name is optional, and when left out, it automatically refers to master.
Regards,
Diego
Hi all,
I have some time to fix QCMagritte, and wanted to make it work for the latest Pharo and to my surprise, loading Magritte itself is broken for Pharo 7.
If I understand correctly the official project on GitHub is in the project https://github.com/magritte-metamodel <https://github.com/magritte-metamodel>
There are only 2 people in this repository. Sean or Cyril, can you add me (delware // diego.lont(a)delware.nl <mailto:diego.lont@delware.nl>) to this repository so I can make Magritte working again?
Cheers,
Diego
Ciao,
i have a development system based on Pharo 7.0.3.
On it the 26 April i do :
Metacello new
baseline:'Seaside3';
repository:'github://SeasideSt/Seaside:develop/repository';
load
It load: Seaside v3.3.3 commit c985986
Metacello new
baseline:'Magritte';
repository:'github://magritte-metamodel/magritte:master/repository';
load
It load Magritte commit c8a8cd5
and everything seems to work well.
Now i some test to load the same project on Gemstone 3.4.3
The Seaside with:
GsDeployer deploy: [
Metacello new
baseline: 'Seaside3';
repository: 'github://SeasideSt/Seaside:master/repository';
onLock: [:ex | ex honor];
load ].
It load: Seaside v3.3.3 commit c985986 ( like above )
The Magritte with:
GsDeployer deploy: [
Metacello new
baseline: 'Magritte';
repository: 'github://Magritte-metamodel/Magritte:master/source';
onLock: [:ex | ex honor];
load ].
A this point the system open a dialog with the error:
Could not resolve: Magritte-Merging [Magritte-Merging] in cache github://Magritte-metamodel/Magritte:master/source (4)
and the Seaside project entry is update to v3.2.4 commit 1f39762
Considerations ?
Thanks,
Dario
P.S. Today i do the command to load Magritte on a new Pharo 7.0.3 image
The system open a dialog with:
MetacelloConflictingProjectError: Load Conflict between existing BaselineOfGrease [baseline] from github://SeasideSt/Grease:master/repository and BaselineOfGrease [baseline] from github://SeasideSt/Grease:1.3.5/repository
Looking through the MADescription hierarchy, *almost* all field data is
stored as properties, except MAReferenceDescription>>#reference,
MAOptionDescription>>#options and a few others. Why these anomalies? Design
decision or mistake?
-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Magritte-Pier-and-Related-Tools-f115649.html
Hi,
I have projects depending on Magritte3, Seaside and Grease. I am
currently updating the dependencies to use the official current
repository of Seaside and Grease that is now on Github and not on Sthub
anymore.
I currently have a problem because Magritte3 dependencies reference the
Sthub version and not the github one. This creates conflicts.
I am wondering if Magritte3 should not have a new version using the new
repositories when they still are close. In that case what should be the
release? 3.5.3? 3.6.0?
--
Cyril Ferlicot
https://ferlicot.fr
