auto generation of blocks.properties

[Joerg Heinicke <jh...@virbus.de>]

Hello guys,

last week there was again a thread about binary dists or at least about 
simplifying the build on the users list:

http://marc.theaimsgroup.com/?t=106817421400001&r=1&w=2

The original reason were Alexander's problems with the CLI: it is/was 
not usable with the authentication-fw block. Further dependencies were 
not in the blocks.properties and so he became frustrated.

One solution for him where different blocks.properties for different use 
cases. Another solution IMO are the complete dependencies in our 
blocks.properties. But maintaining both gump.xml and blocks.properties 
is a pain. The solution is to have one file and to generate the other 
one. I wrote a stylesheet doing this from gump.xml, find it attached 
(after problems with Xalan).

The question is how to integrate it exactly into the build. Only as a 
helper target? Only for developers before committing gump.xml? As one of 
the first steps in the build, i.e. blocks.properties is removed from the 
CVS and it's only generated dynamically?

Furthermore the gump.xml project/@status must be completed 
(status="stable" and stable="deprecated").

I hope you will find it useful. Any comments?

Joerg

Re: auto generation of blocks.properties

[Joerg Heinicke <jh...@virbus.de>]

On 11.11.2003 08:29, Upayavira wrote:

>> The solution is to have one file and to generate the other 
>> one. I wrote a stylesheet doing this from gump.xml, find it attached 
>> (after problems with Xalan).
>>
>> The question is how to integrate it exactly into the build. Only as a 
>> helper target? Only for developers before committing gump.xml? As one 
>> of the first steps in the build, i.e. blocks.properties is removed 
>> from the CVS and it's only generated dynamically?
>>
>> Furthermore the gump.xml project/@status must be completed 
>> (status="stable" and stable="deprecated").
>>
>> I hope you will find it useful. Any comments?
> 
> 
> I'd say in two ways:
> (1) as a task anyone can run at their leasure: build blocks-properties
> and
> (2) as a part of the release process - so that releases always have a 
> correct blocks-properties.
> 
> That way, developers have the responsibility to create a 
> blocks-properites file for themselves, but users get one ready made. If 
> someone starts using CVS, they need to look out for this.
> 
> Does your blocks.properties include dependency info and descriptions of 
> the blocks themselves?

Of course dependency info, that was the reason for doing it - and we 
have a lot of dependencies of you look at the result, much more than 
there were mentioned in the blocks.properties until now.

I don't like the idea of having block descriptions also in the 
blocks.properties. This makes the file unreadable. With the dependencies 
it's already "full".

> Otherwise, I think this is great, and much needed (and will no our 
> users, and gump, no harm at all!)

Ok, I will commit it soon as helper target.

Joerg

Re: auto generation of blocks.properties

[Upayavira <uv...@upaya.co.uk>]

Joerg Heinicke wrote:

> Hello guys,
>
> last week there was again a thread about binary dists or at least 
> about simplifying the build on the users list:
>
> http://marc.theaimsgroup.com/?t=106817421400001&r=1&w=2
>
> The original reason were Alexander's problems with the CLI: it is/was 
> not usable with the authentication-fw block. Further dependencies were 
> not in the blocks.properties and so he became frustrated.
>
> One solution for him where different blocks.properties for different 
> use cases. Another solution IMO are the complete dependencies in our 
> blocks.properties. But maintaining both gump.xml and blocks.properties 
> is a pain. The solution is to have one file and to generate the other 
> one. I wrote a stylesheet doing this from gump.xml, find it attached 
> (after problems with Xalan).
>
> The question is how to integrate it exactly into the build. Only as a 
> helper target? Only for developers before committing gump.xml? As one 
> of the first steps in the build, i.e. blocks.properties is removed 
> from the CVS and it's only generated dynamically?
>
> Furthermore the gump.xml project/@status must be completed 
> (status="stable" and stable="deprecated").
>
> I hope you will find it useful. Any comments?

I'd say in two ways:
(1) as a task anyone can run at their leasure: build blocks-properties
and
(2) as a part of the release process - so that releases always have a 
correct blocks-properties.

That way, developers have the responsibility to create a 
blocks-properites file for themselves, but users get one ready made. If 
someone starts using CVS, they need to look out for this.

Does your blocks.properties include dependency info and descriptions of 
the blocks themselves?

Otherwise, I think this is great, and much needed (and will no our 
users, and gump, no harm at all!)

Regards, Upayavira

Re: auto generation of blocks.properties

[Bertrand Delacretaz <bd...@apache.org>]

Le Mardi, 11 nov 2003, à 10:30 Europe/Zurich, Joerg Heinicke a écrit :

> On 11.11.2003 08:56, Bertrand Delacretaz wrote:
>
>> Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :
>>> ...Another solution IMO are the complete dependencies in our 
>>> blocks.properties. But maintaining both gump.xml and 
>>> blocks.properties is a pain. The solution is to have one file and to 
>>> generate the other one....
>> +1, actually this info should come from the blocks directly 
>> (metadata), but this is for later...
>
> This stylesheet was especially for the time we don't have the "real" 
> blocks...

Sure - your (temporary, as you mention) solution is fine for now IMHO.

>> ...
>> I'd just add a prominent notice at the beginning of the generated 
>> blocks.properties: "autogenerated - do not edit" or something.
>
> This depends. If it is only a helper target it will be called on 
> demand. It would be the same as a committer is editing the 
> blocks.properties and commits it. Now he needs not to edit it by hand 
> but generate it automatically.

IIUC the scenario when there is a change in block info would be:

1. update gump.xml
2. generate blocks.properties from gump.xml (using helper build target)
3. commit both gump.xml and blocks.properties

Is that what you mean?

In this case a warning is needed in blocks.properties, to describe how 
to correctly handle it.
And a warning in gump.xml, to remind people to regenerate 
blocks.properties upon changes.
Might be ok for a temp solution, gump.xml does not change that often.

> ...It's another issue if it is deeper integrated into the build 
> process. Remove blocks.properties from CVS, starting the generation on 
> the first build, later on it will be updated after an update on 
> gump.xml, the user get's again it local.blocks.properties and *must* 
> change the blocks deployment there. But how to keep it in sync? Adding 
> a warning on the screen if the blocks.properties is newer than 
> local.blocks.properties?

Not sure what you mean by "keep it in sync", Isn't this the same 
problem as now?
Currently if blocks.properties changes, I have to do a diff with my 
local.blocks.properties to see what happened.

-Bertrand

Re: auto generation of blocks.properties

[Joerg Heinicke <jh...@virbus.de>]

On 11.11.2003 08:56, Bertrand Delacretaz wrote:

> Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :
> 
>> ...Another solution IMO are the complete dependencies in our 
>> blocks.properties. But maintaining both gump.xml and blocks.properties 
>> is a pain. The solution is to have one file and to generate the other 
>> one....
> 
> 
> +1, actually this info should come from the blocks directly (metadata), 
> but this is for later...

This stylesheet was especially for the time we don't have the "real" 
blocks. But of course maybe we can have some intermediate, i.e. a time 
where we have the blocks, but not the block deployer. There another 
stylesheet can also help.

> I like the idea of generating blocks.properties from gump.xml.
> 
> I'd just add a prominent notice at the beginning of the generated 
> blocks.properties: "autogenerated - do not edit" or something.

This depends. If it is only a helper target it will be called on demand. 
It would be the same as a committer is editing the blocks.properties and 
commits it. Now he needs not to edit it by hand but generate it 
automatically.

It's another issue if it is deeper integrated into the build process. 
Remove blocks.properties from CVS, starting the generation on the first 
build, later on it will be updated after an update on gump.xml, the user 
get's again it local.blocks.properties and *must* change the blocks 
deployment there. But how to keep it in sync? Adding a warning on the 
screen if the blocks.properties is newer than local.blocks.properties?

It's not easy as you can see. It's also only a temporary solution.

Joerg

Re: auto generation of blocks.properties

[Bertrand Delacretaz <bd...@apache.org>]

Le Mardi, 11 nov 2003, à 00:20 Europe/Zurich, Joerg Heinicke a écrit :

> ...Another solution IMO are the complete dependencies in our 
> blocks.properties. But maintaining both gump.xml and blocks.properties 
> is a pain. The solution is to have one file and to generate the other 
> one....

+1, actually this info should come from the blocks directly (metadata), 
but this is for later...

I like the idea of generating blocks.properties from gump.xml.

I'd just add a prominent notice at the beginning of the generated 
blocks.properties: "autogenerated - do not edit" or something.

-Bertrand