how should I do it? without default of course. because you know I want to be able to load any version from now.
Does ((Smalltalk at: #ConfigurationOfMoose) project version: '4.0-beta.2') load. load the latest version of mondrian?
In a word how can I avoid to lose hours with loading Moose?
Stef
Hi all,
I remenber we had Moose-all before ConfigurationOf. It was easier to load. It was easier to save. Now when we make class-extension we must remember the concerned package to save it manually.
Certainly Metacello is better than our previous method. But I think the process is not clear.
It seems that we use Metacello, because it allows us to specify versions and a lot of thinks. What I see is we have more difficulties since the method has changed.
I see: - Moose-All as "make it easy" - ConfigurationOf as "make it modular"
Now is it possible to make ConfigurationOf easier.
Cheers, Jannik
On Dec 3, 2009, at 09:22 , Stéphane Ducasse wrote:
how should I do it? without default of course. because you know I want to be able to load any version from now.
Does ((Smalltalk at: #ConfigurationOfMoose) project version: '4.0-beta.2') load. load the latest version of mondrian?
In a word how can I avoid to lose hours with loading Moose?
Stef _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 3 déc. 2009, at 06:30, Laval Jannik wrote:
Hi all,
I remenber we had Moose-all before ConfigurationOf. It was easier to load. It was easier to save. Now when we make class-extension we must remember the concerned package to save it manually.
The problem with Moose-All is that you always had to save with Moose- All. So you could not make incremental commit (i.e. save one package but not the other on which you are still working).
The good thing with saving packages one by one is that at least it forces me to review the changes before committing :)
More to come later.
-- Simon
Hi Stef,
how should I do it? without default of course. because you know I want to be able to load any version from now.
I know you want that, but the tools are not quite in place to make it practical.
Does ((Smalltalk at: #ConfigurationOfMoose) project version: '4.0-beta. 2') load. load the latest version of mondrian?
The above method will load the exact version of Mondrian that is mentioned in the 4.0-beta.2 configuration of Moose,
In a word how can I avoid to lose hours with loading Moose?
First of all, bashing does not help anyone :).
There are two workflows that are supported at the moment: - load the latest for development - load a certain release
You want another use case in which you publish a hardcoded version every time you publish. Metacello supports that, but you need tool support for that. In fact, this probably belongs in a nightly build and it should not be done manually.
Unfortunately, while I would love to have the perfect tools around, they are just not quite what they should be just yet. But, of course, if someone wants to invest time there, I would be very happy.
Cheers, Doru
-- www.tudorgirba.com
"Every successful trip needs a suitable vehicle."
On Dec 3, 2009, at 1:59 PM, Tudor Girba wrote:
Hi Stef,
how should I do it? without default of course. because you know I want to be able to load any version from now.
I know you want that, but the tools are not quite in place to make it practical.
what is missing. In pharo I get all the packages filter the one I want and this is done.
So can I suggest that we stop fixing moose before this point is fixed! Like that we will all avoid to lose time.
Does ((Smalltalk at: #ConfigurationOfMoose) project version: '4.0-beta.2') load. load the latest version of mondrian?
The above method will load the exact version of Mondrian that is mentioned in the 4.0-beta.2 configuration of Moose,
so this is useless
In a word how can I avoid to lose hours with loading Moose?
First of all, bashing does not help anyone :).
There are two workflows that are supported at the moment:
- load the latest for development
- load a certain release
You want another use case in which you publish a hardcoded version every time you publish. Metacello supports that, but you need tool support for that. In fact, this probably belongs in a nightly build and it should not be done manually.
Unfortunately, while I would love to have the perfect tools around, they are just not quite what they should be just yet. But, of course, if someone wants to invest time there, I would be very happy.
The problem is that with Moose-All we got that behavior and now we lost it. I do not know Metacello to be able to do that. I thought that there is a button to generate the method? So why if there is such a button it would be difficult to have a version released all the time? I do not get it.
Stef
Stef,
how should I do it? without default of course. because you know I want to be able to load any version from now.
I know you want that, but the tools are not quite in place to make it practical.
what is missing. In pharo I get all the packages filter the one I want and this is done.
So can I suggest that we stop fixing moose before this point is fixed! Like that we will all avoid to lose time.
There are other issue in my priority queue that takes precedence. For the development/maintenance of Moose, I can manage with the current workflow based on the latest version. It's not ideal but it is Ok for now.
Does ((Smalltalk at: #ConfigurationOfMoose) project version: '4.0-beta. 2') load. load the latest version of mondrian?
The above method will load the exact version of Mondrian that is mentioned in the 4.0-beta.2 configuration of Moose,
so this is useless
Then, I did not understand your question. If you want to load a certain version, then you are not looking for the last version. If you are looking for the last version, you are not looking necessarily for the last version.
In a word how can I avoid to lose hours with loading Moose?
First of all, bashing does not help anyone :).
There are two workflows that are supported at the moment:
- load the latest for development
- load a certain release
You want another use case in which you publish a hardcoded version every time you publish. Metacello supports that, but you need tool support for that. In fact, this probably belongs in a nightly build and it should not be done manually.
Unfortunately, while I would love to have the perfect tools around, they are just not quite what they should be just yet. But, of course, if someone wants to invest time there, I would be very happy.
The problem is that with Moose-All we got that behavior and now we lost it.
Moose-All did not scale for multiple projects and packages in various repositories. Furthermore, if you had a wrong configuration that lead to an unloadable definition, you could not fix it because the definition of the dependencies was tightly coupled with the loading of the code.
Moose-All also lead to many unnecessary forks which made the integration more difficult.
I do not know Metacello to be able to do that. I thought that there is a button to generate the method? So why if there is such a button it would be difficult to have a version released all the time? I do not get it.
There is a button: 'Spawn New Version'. But you need more than that: You need to be able to publish projects recursively, you need to be able to preview and choose what parts you would want to publish and these should all be integrated in one tool. Until this tool exists there won't be much progress in this respect.
Doru
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."
I know all that. I'm saying that we should really make progress on this front because this is more than a year data that we are losing that way. We cannot use moose as an asset for our research analysis and this is really sad. In addition to all the eingeering problem it brings.
Now instead of shooting for the hyper cool tools. We could do it incrementally. First people really publish up to date configuration. So saving is only done when you can reload!!! Second with the button can we get the complete COnfiguration related (not subprojects) package versions because this would be enough. It means that we can get a list of configurations and do a loop.
Stef
-
Laval Jannik -
Simon Denier -
Stéphane Ducasse -
Tudor Girba