project collision on complex configurations

Hi Dale, list

I have this problem, and I suppose it is a common problem:

I have configurations for several projects, who depends on other projects. Let's say, I have a customers project (ibizlog), who depends on: Seaside, SeasideRest, JQWidgetBox, Reef, etc., etc., etc.

but well... I don't want to load all Seaside, because I'm trying to use pharo 1.4 as my development plaform, so I don't want OB (I'm using nautilus), and I also don't want Kom (who doesn't loads, and pharo has zinc, anyway).
So, I placed my configuration with just groups and packages I want... but... this is the problem:

SeasideRest also requires Seaside30
JQWidgetBox also requires Seaside30
Reef also requires Seaside30

...so... metacello executes project configuration, and tries to load again Seaside30... with the default configuration (who is, we all know, a huge beast).

How do I manage this situation?

I think right now, you can't... so, here a couple of thoughts:

1) add a flag "ignore already installed projects". Projects can be detected by repo+configuration class
2) add a #ignoring: #(list of artifact names) protocol to project spec... so I can add them and say: ignore "Seaside30, I'm using own"

of course, in the long way, I think first solution is better :)

best,
Esteban

On Mar 7, 2012, at 10:24 PM, Esteban Lorenzano wrote:

you can specify that you want to load only a set of groups
for example



ConfigurationOfCoolToolSet>>version10: spec <version: '1.0' imports: #('1.0-baseline')>
        spec for: #pharo do: [ spec
                project: 'XMLSupport' with: [spec loads: #(’XML-Parser’ ’XML-Tests-Parser’); versionString: ’1.2.0’].

        spec
                package: 'Soup-Core' with: 'Soup-Core-sd.11';
                package: 'Soup-Tests-Core' with: 'Soup-Tests-Core-sd.3'; package: 'Soup-Help' with: 'Soup-Help-StephaneDucasse.2' ].

Hi,

yes, I can.. problem is that I need to load, for instance Seaside-Rest... who has a "requires: #('Seaside30')" inside.

So... it tries to load Seaside30, even if I specified just "Seaside-Rest"

cheers,
Esteban

El 07/03/2012, a las 6:28p.m., stephane ducasse escribió:

looks to me that the configuration is not fully exposing modular aspect of seaside design.
Now this is normal since it would be easier if philippe and lukas would maintain the configuration because
they know the minimal config and families. Now I suggest that you update it as you can.

Stef

you think it will be accepted for seaside mantainers?

Esteban

El 07/03/2012, a las 6:56p.m., stephane ducasse escribió:

> looks to me that the configuration is not fully exposing modular aspect of seaside design.
> Now this is normal since it would be easier if philippe and lukas would maintain the configuration because
> they know the minimal config and families. Now I suggest that you update it as you can.
>
> Stef
>

> you think it will be accepted for seaside maintainers?

sure no?
what is the alternative. To fork and create more mess? and be less to have a look and be able to fix?

Stef

ok, I will create a Core-Minimal, a Core-JQuery-Minimal and Core-Scriptaculous-Minimal, and redirect default on first one :)

El 07/03/2012, a las 7:14p.m., stephane ducasse escribió:

Estaban,

I haven't read through the responses, yet, but SeasideREST requires only 'Seaside-Core', JQWidgetBox requires #('Base' 'JQuery-UI')...I haven't looked at the Reef config (not in MetacelloRepository).

'Seaside-Core' is a single package in Seaside, so it won't cause the whole enchilads to be loaded.

The 'Base' group in Seaside is considered to be the 'bare minimum' for a functioning Seaside installation ... no development support and no extras, including no adaptors which have to be managed separately ...

In all of my projects I use a variant of the JQWidgetBox approach where I specify 'Base' group plus whatever other Seaside packages I explicitly need.

Upon further inspection it looks like the Reef configuration does not specify an explicit list including the 'Base', so that's why all of Seaside is being loaded. If you edit the configuration and specify only the set of packages that are needed you'll be good to go.

Dale

----- Original Message -----
| From: "Esteban Lorenzano" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, March 7, 2012 1:24:08 PM
| Subject: [Metacello] project collision on complex configurations
|
| Hi Dale, list
|
| I have this problem, and I suppose it is a common problem:
|
| I have configurations for several projects, who depends on other
| projects. Let's say, I have a customers project (ibizlog), who
| depends on: Seaside, SeasideRest, JQWidgetBox, Reef, etc., etc.,
| etc.
|
| but well... I don't want to load all Seaside, because I'm trying to
| use pharo 1.4 as my development plaform, so I don't want OB (I'm
| using nautilus), and I also don't want Kom (who doesn't loads, and
| pharo has zinc, anyway).
| So, I placed my configuration with just groups and packages I want...
| but... this is the problem:
|
| SeasideRest also requires Seaside30
| JQWidgetBox also requires Seaside30
| Reef also requires Seaside30
|
| ...so... metacello executes project configuration, and tries to load
| again Seaside30... with the default configuration (who is, we all
| know, a huge beast).
|
| How do I manage this situation?
|
| I think right now, you can't... so, here a couple of thoughts:
|
| 1) add a flag "ignore already installed projects". Projects can be
| detected by repo+configuration class
| 2) add a #ignoring: #(list of artifact names) protocol to project
| spec... so I can add them and say: ignore "Seaside30, I'm using own"
|
| of course, in the long way, I think first solution is better :)
|
| best,
| Esteban
|
|

Esteban,

You are correct that a better set of groupings can be defined for the Seaside project. I would suggest that you make your suggestions on the Seaside list (to get feedback from others) and we should be able to come up with a set of groups that meets the needs of the developers using Seaside...

Dale

----- Original Message -----
| From: "Esteban Lorenzano" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, March 7, 2012 2:22:02 PM
| Subject: Re: [Metacello] project collision on complex configurations
|
| ok, I will create a Core-Minimal, a Core-JQuery-Minimal and
| Core-Scriptaculous-Minimal, and redirect default on first one :)
|
| El 07/03/2012, a las 7:14p.m., stephane ducasse escribió:
|
| >
| >> you think it will be accepted for seaside maintainers?
| >
| > sure no?
| > what is the alternative. To fork and create more mess? and be less
| > to have a look and be able to fix?
| >
| > Stef
| >
| >>
| >> Esteban
| >>
| >> El 07/03/2012, a las 6:56p.m., stephane ducasse escribió:
| >>
| >>> looks to me that the configuration is not fully exposing modular
| >>> aspect of seaside design.
| >>> Now this is normal since it would be easier if philippe and lukas
| >>> would maintain the configuration because
| >>> they know the minimal config and families. Now I suggest that you
| >>> update it as you can.
| >>>
| >>> Stef
| >>>
| >>
| >
|
|