You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/06/09 17:04:14 UTC
Re: [Phoenix] Tool Support
Niclas Hedhman wrote:
> Hi,
>
> I was thinking about some tool support for creation of custom servers.
>
> One of the intended features is that the IDE tool can juggle Blocks available,
> but one of the things that struck me was;
>
> How does the Tool know what config.xml each block is expecting??
>
>
> Anyone have any thoughts about this?
If you are talking about plugin development, then there are some things
you can do, but your plugin will always be container specific. You have
to operate based on the rules that the container uses.
For Phoenix based apps, you have to tell the plugin where the
assembly.xml file is (perhaps you are aditing this doc with the
plugin), and where the config.xml file is. Phoenix has certain
rules for how these two files interact. That way you can have that
mapping as you would expect.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Phoenix] Tool Support
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Tuesday 10 June 2003 05:56 am, Berin Loritsch wrote:
>
>>No you are not an idiot. I think I understand a bit better what you
>>want to do with the tool. BTW, which IDE(s) are you creating the tool
>>for?
>
>
> We are evaluating that. Since it will be for our customers, and they don't
> mind paying a bit for tools, we are looking at both OSS and commercial
> offerings.
> Also cross-checking with the progress of JSR-198
> (http://www.jcp.org/en/jsr/detail?id=198) as this will be the ultimate goal.
>
>
>
>>Phoenix for now is the only container that supports a pointer to a
>>configuration schema. However, not all components declare the schema.
>>One thing that you can do (and probably should be included in Avalon
>>Configuration) is the ability to reverse engineer a schema.
>
>
> Hmmmm....
> IMHO, Avalon at large should spend some serious thinking of tool support, and
> possibly include a subproject for it at some point in time. It's the way to
> beat M$, at their own game.
>
> Nevertheless, for me this is very pre-mature, and will be brewing for a few
> months first.
Its on the radar.
The major issue with writing plugins is having everyone able to compile
them. We can't get the JAR or include it in our CVS without the huge
download, so it makes automating the tool building difficult.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Phoenix] Tool Support
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 10 June 2003 05:56 am, Berin Loritsch wrote:
> No you are not an idiot. I think I understand a bit better what you
> want to do with the tool. BTW, which IDE(s) are you creating the tool
> for?
We are evaluating that. Since it will be for our customers, and they don't
mind paying a bit for tools, we are looking at both OSS and commercial
offerings.
Also cross-checking with the progress of JSR-198
(http://www.jcp.org/en/jsr/detail?id=198) as this will be the ultimate goal.
> Phoenix for now is the only container that supports a pointer to a
> configuration schema. However, not all components declare the schema.
> One thing that you can do (and probably should be included in Avalon
> Configuration) is the ability to reverse engineer a schema.
Hmmmm....
IMHO, Avalon at large should spend some serious thinking of tool support, and
possibly include a subproject for it at some point in time. It's the way to
beat M$, at their own game.
Nevertheless, for me this is very pre-mature, and will be brewing for a few
months first.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Phoenix] Tool Support
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, June 10, 2003, at 09:56 AM, Berin Loritsch wrote:
> Phoenix for now is the only container that supports a pointer to a
> configuration schema. However, not all components declare the schema.
> One thing that you can do (and probably should be included in Avalon
> Configuration) is the ability to reverse engineer a schema.
Interesting idea, but its not that hard to write a schema :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Phoenix] Tool Support
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Monday 09 June 2003 07:04 am, Berin Loritsch wrote:
>
>>Niclas Hedhman wrote:
>>
>>>How does the Tool know what config.xml each block is expecting??
>
>>For Phoenix based apps, you have to tell the plugin where the
>>assembly.xml file is (perhaps you are aditing this doc with the
>>plugin), and where the config.xml file is. Phoenix has certain
>>rules for how these two files interact. That way you can have that
>>mapping as you would expect.
>
>
> Perhaps I am an idiot, and don't get your point, BUT my point is that the tool
> creates SARs from a repository of blocks, and hence are the _creator_ of the
> config, assembly and environment files. Meaning, it would need some kind of
> schema or template, especially for config.xml.
No you are not an idiot. I think I understand a bit better what you
want to do with the tool. BTW, which IDE(s) are you creating the tool
for?
Phoenix for now is the only container that supports a pointer to a
configuration schema. However, not all components declare the schema.
One thing that you can do (and probably should be included in Avalon
Configuration) is the ability to reverse engineer a schema.
The way we would do that is to use a "Schema Builder" that implements
the Configuration interface. The block is brought up through
initialization. As long as all the configuration parameters are
called during initialization (some process the config in the
Initializeable stage), then you can create a schema for the block.
In fact that would be a very useful tool if the schema could be
saved with the project and the JavaDoc tag updated.
So the builder would start out with the root context, and if a
"getAttribute" is called, you will know that the attribute is
used, that it is a string, and whether there is a default value
for the attribute. If "getChild" is called, then you know there
is a child element, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Phoenix] Tool Support
Posted by Peter Royal <pr...@apache.org>.
On Tuesday, June 10, 2003, at 02:21 PM, Niclas Hedhman wrote:
> Perhaps I am an idiot, and don't get your point, BUT my point is that
> the tool
> creates SARs from a repository of blocks, and hence are the _creator_
> of the
> config, assembly and environment files. Meaning, it would need some
> kind of
> schema or template, especially for config.xml.
Blocks can declare a schema to describe their configuration, so that's
how you can figure out what goes into config.xml.
Let me know if you need more details :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [Phoenix] Tool Support
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 09 June 2003 07:04 am, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> > How does the Tool know what config.xml each block is expecting??
> If you are talking about plugin development, then there are some things
> you can do, but your plugin will always be container specific. You have
> to operate based on the rules that the container uses.
Yes, I am talking about 'container specific', in a matter of fact, I thought
it was clear from the Subject line ;o)
> For Phoenix based apps, you have to tell the plugin where the
> assembly.xml file is (perhaps you are aditing this doc with the
> plugin), and where the config.xml file is. Phoenix has certain
> rules for how these two files interact. That way you can have that
> mapping as you would expect.
Perhaps I am an idiot, and don't get your point, BUT my point is that the tool
creates SARs from a repository of blocks, and hence are the _creator_ of the
config, assembly and environment files. Meaning, it would need some kind of
schema or template, especially for config.xml.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org