You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2003/11/01 11:06:22 UTC
[RT] Block Packaging
Hi all,
IMHO, Avalon is concentrating too much from the POV of the Container and not
very much from POV of the Application Integrator (AI).
Perhaps this is so due to the perception that AI have a lot of time to create
an application using the blocks available, and that he/she doesn't really
need any powerful tools. I beg to differ, as I have expressed many times
before.
In order to be able to create tools for the AI, we have to define a
specification on how the Component Author (CA) is to package the
component(s), and it is my intention with this RT to kick off such a
discussion.
Eventually, once this specification is nailed down, I and/or others can start
on powerful tools, not only for the AI but also for the CA. We will kill two
flies in one go, so to speak.
So, what is the problem??
Avalon today is 100% about CODE and METADATA.
Avalon shy away from all kind of RESOURCES, whether they are pertinent to the
Avalon context or not. I don't know if this intentional or not.
In any event, a COMPONENT consists of all of the above, and if one or the
other is completely missing, it is not a component anymore.
>From my perspective I see the following resources and metadata (some metadata
could be considered a resource and vice versa, so I klump them together),
being fairly central to most components;
1. Naming and Identification
2. Versioning
3. Dependencies
4. LifeStyle
5. Container/Environment Requirements
6. Third-Party Requirements
7. Javadoc and other documentation.
8. Internationalization & Localization
9. Management Interface
I don't intent to elaborate on these at this point in time, but would like to
mention that item 2-5 is pretty much nailed down as it is today.
Also, item 6, refers to stuff like jars/classes and resources have to be
packaged into WAR file in a particular way.
Item 9, I am a little bit split over myself. Sometimes I feel that the
container should be able to provide a Management Interface automatically, but
how would it know what is part of management, and what is part of the
components normal function. TBD.
First of all, I would like people to recognize that we actually have 3
different packages to deal with;
1. Component APIs
2. Component Implementations
3. Support Implementations.
4. Assembled Applications
5. Container Extensions
Existing examples;
Example of a Component API = Generator
Example of an Implementation = FileGenerator
Example of an Application = A configured Cocoon instance
Imaginary Examples;
Example of Support Implementation = Web interface to Calendar
Example of Container Extension = JINI based lookup
I always get the objection that, for instance, the Generator is so simple that
we don't need to separate it out.
Not to get too deep into that discussion again, let me just say, yes the code
is simple, but look at the list above.
Component API
============
The Component API specifies the programmatic interfaces and sometimes provides
some value objects, but very little else code.
It should (must), however, provide extensive documentation, javadoc and
others, about the semantics, explicit or implied, of the API.
It should probably contain I18N and L10N resources where appropriate.
Component Implementations
=====================
A lot of code typically goes into creating a component.
An implementation can often reuse chunks of the Component API documentation.
In fact, it feels almost like documentation should be inherited, albeit we
don't have such a mechanism.
I18N and L10N are big issues.
Implementations will support one, few or all LifeStyles.
They Depend on at least its own Component API (but this dependency is
different from the dependency in Avalon), but often on many other Component
APIs and sometimes Component Implementations. This also refers back to
Identification and Versioning.
Often the Component Implementation have many specific requirements from the
Container/Environment and often 3rd Party requirements as well, such as JDBC
drivers, external config file entries, user authentications and what not.
Support Implementations
==================
The Support Implementation does not implement the Component API, but provides
some explicit additional service to a particular Component API.
An example of a support implementation is a Web User Interface to a particular
Component API (or even Component Implementation).
Container Extensions
================
In rare occassions a Component Implementation may require a particular
Container Extension to be present.
Container Extensions are slightly outside the scope of this RT, so I leave it
as a special dependency case.
Assembled Applications
==================
I have been struggling with the question "Does an Assembled Application have
its own code?"
The argument is that you need some level of GLUE between the Components to
make them work.
The counter-argument would be that, that GLUE is in itself a Component
Implementation, that implements an "Application Component API".
The more I have investigated the "counter-argument", the stronger I believe in
it. One would establish a few "Application Component API"s for different
similar applications.
That would then mean that an Assembled Application is ONLY the components, and
the "configuration" and "wiring" of these components (Merlin terms;
block.xml, Phoenix terms; configuration.xml + assembly.xml ).
So where does all of this bring us??
==========================
I strongly believe that for each of the above sub-system, we need to SPECIFY a
packaging format that are tool-friendly.
I have a vision, using Eclipse/Netbeans;
File->New->Avalon->Component API
All the parts that the Component API should have is managed by the IDE. I can
right-click and ask for the documentation window. I can ask to create a JUnit
based validation test, to be used by Component Implementations.
Tools -> View Components -> APIs
A browser to view the APIs that are available. Which versions I have. Mount
repositories and download new components or versions. For each API, I can
easily access the documentation, view code and validation tests.
"Component API" -> Create Implementation
The IDE creates stub(s) for me, and sets up all the I18N/L10N resources, and
manages the declarations of dependencies.
"Component API" -> Create Support Implementation -> Web
I imagine that the IDE PlugIn supports a couple of standard Support
Implementation systems, or even allow extensions to be plugged-in. For
instance, a Web User Interface is perhaps a typical Support Implementation.
A SOAP access wrapper may be another.
File -> New -> Avalon -> Application
Allows me to pick and choose Component Implementations, and the IDE plug-in
will track missing dependencies, will include the Component APIs required and
package it all.
This is just the beginning of such a vision. I hope everyone can see the
elegance if/when we could reach such a state.
I have started on such a tool several time, and I think others have also
thought about it, and I bet the reason why it doesn't exist by now is the
lack of packagin specifications. It is not possible to start on such a IDE
plug-in, since there is no standard on what constitutes a component.
I hope we can spend a little bit of time defining exactly that.
1. How is a Component API packaged?
2. How is a Component Implementation packaged?
3. How is an Assembled Application packaged?
This will already give us plenty of room for fantastic tools to be developed.
Answering the 3. question first should be the easiest, since that is related
to the Container where we deploy.
Well, that is not entirely true, because the container is only interested in
the runtime aspect of the Application, and doesn't care about installation,
versioning (of entire app), documentation and to some extent configuration
handling.
Phoenix was more explicit about the packaging than Merlin is, but we need to
nail this one down more precisely. Not because we need to satisfy Merlin, but
to satisfy tools' need for a specification in this area.
I would like not to go into specifics about what _I_ believe to be a good
packaging specification for the above 3 (I haven't been thinking too much
about Container Extensions and Support Implementations), but let everyone
digest what I have just written.
At the end of this discussion, I would like to see the following
exit-conditions;
1. Packaging specifications for at least the 3 core packages (api, impl and
app).
or
2. The community decides that this is not a concern and should not be part of
Avalon core.
And in the event of 1., the follow-up question would then be,
Is it in Avalon's interest to host IDE tools for Avalon development?
I hope I have provided some food for thought.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Leo Simons <le...@apache.org>.
I went back through the archives to read up on the various discussions
about block packaging we've head over the years. "Deployable Units" and
"Resource Units" are terms from the recent past; lots of interesting
thoughts also to be found on the old phoenix-dev@jakarta.apache.org
mailing list in much older discussions.
An important point that already came up back in 2001 is that block
packaging is something that is a need that is far from unique to avalon.
It was suggested several times, from this realization, that some kind of
packaging/repository project would be started in jakarta-commons, as a
jakarta subproject, or at least somewhere where many more non-avaloners
would also participate. That did never work out.
But, there's a difference now. Most of the world is just now realizing
the potential behind an archive format that's richer than just "jars"
and "wars", more people are really digging into this area. With IoC,
SoC, SoAI really gaining steam throughout the java world, it might be a
good idea to escalate this packaging effort out of the avalon fold and
into a bigger project.
Maybe in a month or two; but I suggest everyone keeps this broad
application idea in the back of his head...it'd be nice if we'd have
packaging products, plugins, etc etc, that can be used even if you think
avalon (or IoC in general) otherwise sucks.
cheers!
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Sunday 02 November 2003 16:17, Niclas Hedhman wrote:
>
>>On Saturday 01 November 2003 18:06, Niclas Hedhman wrote:
>>
>>I spent two hours on Eclipse to visualize a Repository Browser.
>>
>>Hope you guys don't mind the bandwidth.
>>
>>
>>This is an extreme draft ;o)
>
>
> Hmmm.... Obviously mailing list strips off attachments.
>
Attachments over a certain size, yes. I can't remember the cut-off for
this list though...
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 02 November 2003 16:17, Niclas Hedhman wrote:
> On Saturday 01 November 2003 18:06, Niclas Hedhman wrote:
>
> I spent two hours on Eclipse to visualize a Repository Browser.
>
> Hope you guys don't mind the bandwidth.
>
>
> This is an extreme draft ;o)
Hmmm.... Obviously mailing list strips off attachments.
The Image is available at;
http://niclas.hedhman.org/avalon/browser/draft1.png
the plug-in itself is at
http://niclas.hedhman.org/avalon/browser/browser-20031102.zip
Installation, go to the directory where eclipse is installed, expand the zip,
so that org.hedhman.avalon.browser directory is expanded into the
eclipse/plugins directory.
Then go to Window->Show View->Other->Component Category->Repository Browser
and it should show up somewhere on the workspace (lower right corner in my
case)
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 01 November 2003 18:06, Niclas Hedhman wrote:
I spent two hours on Eclipse to visualize a Repository Browser.
Hope you guys don't mind the bandwidth.
This is an extreme draft ;o)
Cheers
Niclas
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 02 November 2003 10:20, Stephen McConnell wrote:
> Just a short note to let you know that I printed out the four pages,
> went to cafe, ordered a bottle of wine, sat back, and read your
> email in detail.
No WiFi in the cafe?? Here in Kuala Lumpur, we are getting to the point that
just about every cafe in downtown area provides WiFi access.
> General comment - what your thinking is in scope and of interest.
Encouraging.
> have a bunch of thoughts bubbling away - but way to early to do anything
> other than scare you, me, and a bunch of others.
I'm not easily scared. When I was part of JSR-78, I loudly objected to the
proposal put forward by the Sun lead, as being pre-mature and required more
work. Sun "threatened" as much as they could and argued that there was no
time, and that JSR-76 was directly dependent on JSR-78. The Expert Group
finally voted in favour (majority vote), but the Executive Committee (thank
God) sank the proposal.
It was an interesting experience, to say the least. I guess I'll never be
invited again ;o)
> The killer question is the abstract an seperation of concerns relative
> to the right abstracion - but I'm not going to go into this now because
> my brain would probably though an IllegalStateException.
My one frequently throws OutOfMemoryError and NoSuchMethodException.
Cherio, cherio.... (saw Shanghai Knights yesterday)
Niclas
P.S. You are allowed to "trim" the emails a bit Steve...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Stephen McConnell <mc...@apache.org>.
Niclas:
Just a short note to let you know that I printed out the four pages,
went to
cafe, ordered a bottle of wine, sat back, and read your email in detail.
General comment - what your thinking is in scope and of interest. I'm not
yet ready to provide a constructive reply (at least not immediately) - but
I am ready to say that you should push forward on this here at Avalon. I
have a bunch of thoughts bubbling away - but way to early to do anything
other
than scare you, me, and a bunch of others. The killer question is the
abstract an seperation of concerns relative to the right abstracion - but
I'm not going to go into this now because my brain would probably though an
IllegalStateException.
Cheers, Steve.
Niclas Hedhman wrote:
>Hi all,
>
>IMHO, Avalon is concentrating too much from the POV of the Container and not
>very much from POV of the Application Integrator (AI).
>
>Perhaps this is so due to the perception that AI have a lot of time to create
>an application using the blocks available, and that he/she doesn't really
>need any powerful tools. I beg to differ, as I have expressed many times
>before.
>
>In order to be able to create tools for the AI, we have to define a
>specification on how the Component Author (CA) is to package the
>component(s), and it is my intention with this RT to kick off such a
>discussion.
>
>Eventually, once this specification is nailed down, I and/or others can start
>on powerful tools, not only for the AI but also for the CA. We will kill two
>flies in one go, so to speak.
>
>So, what is the problem??
>
>Avalon today is 100% about CODE and METADATA.
>
>Avalon shy away from all kind of RESOURCES, whether they are pertinent to the
>Avalon context or not. I don't know if this intentional or not.
>In any event, a COMPONENT consists of all of the above, and if one or the
>other is completely missing, it is not a component anymore.
>
>>>From my perspective I see the following resources and metadata (some metadata
>could be considered a resource and vice versa, so I klump them together),
>being fairly central to most components;
>
>1. Naming and Identification
>2. Versioning
>3. Dependencies
>4. LifeStyle
>5. Container/Environment Requirements
>6. Third-Party Requirements
>7. Javadoc and other documentation.
>8. Internationalization & Localization
>9. Management Interface
>
>
>I don't intent to elaborate on these at this point in time, but would like to
>mention that item 2-5 is pretty much nailed down as it is today.
>Also, item 6, refers to stuff like jars/classes and resources have to be
>packaged into WAR file in a particular way.
>Item 9, I am a little bit split over myself. Sometimes I feel that the
>container should be able to provide a Management Interface automatically, but
>how would it know what is part of management, and what is part of the
>components normal function. TBD.
>
>First of all, I would like people to recognize that we actually have 3
>different packages to deal with;
>
>1. Component APIs
>2. Component Implementations
>3. Support Implementations.
>4. Assembled Applications
>5. Container Extensions
>
>Existing examples;
>Example of a Component API = Generator
>Example of an Implementation = FileGenerator
>Example of an Application = A configured Cocoon instance
>
>Imaginary Examples;
>Example of Support Implementation = Web interface to Calendar
>Example of Container Extension = JINI based lookup
>
>I always get the objection that, for instance, the Generator is so simple that
>we don't need to separate it out.
>Not to get too deep into that discussion again, let me just say, yes the code
>is simple, but look at the list above.
>
>Component API
>============
>The Component API specifies the programmatic interfaces and sometimes provides
>some value objects, but very little else code.
>It should (must), however, provide extensive documentation, javadoc and
>others, about the semantics, explicit or implied, of the API.
>It should probably contain I18N and L10N resources where appropriate.
>
>Component Implementations
>=====================
>A lot of code typically goes into creating a component.
>An implementation can often reuse chunks of the Component API documentation.
>In fact, it feels almost like documentation should be inherited, albeit we
>don't have such a mechanism.
>I18N and L10N are big issues.
>Implementations will support one, few or all LifeStyles.
>They Depend on at least its own Component API (but this dependency is
>different from the dependency in Avalon), but often on many other Component
>APIs and sometimes Component Implementations. This also refers back to
>Identification and Versioning.
>Often the Component Implementation have many specific requirements from the
>Container/Environment and often 3rd Party requirements as well, such as JDBC
>drivers, external config file entries, user authentications and what not.
>
>Support Implementations
>==================
>The Support Implementation does not implement the Component API, but provides
>some explicit additional service to a particular Component API.
>An example of a support implementation is a Web User Interface to a particular
>Component API (or even Component Implementation).
>
>Container Extensions
>================
>In rare occassions a Component Implementation may require a particular
>Container Extension to be present.
>Container Extensions are slightly outside the scope of this RT, so I leave it
>as a special dependency case.
>
>Assembled Applications
>==================
>I have been struggling with the question "Does an Assembled Application have
>its own code?"
>The argument is that you need some level of GLUE between the Components to
>make them work.
>The counter-argument would be that, that GLUE is in itself a Component
>Implementation, that implements an "Application Component API".
>The more I have investigated the "counter-argument", the stronger I believe in
>it. One would establish a few "Application Component API"s for different
>similar applications.
>That would then mean that an Assembled Application is ONLY the components, and
>the "configuration" and "wiring" of these components (Merlin terms;
>block.xml, Phoenix terms; configuration.xml + assembly.xml ).
>
>
>So where does all of this bring us??
>==========================
>I strongly believe that for each of the above sub-system, we need to SPECIFY a
>packaging format that are tool-friendly.
>
>I have a vision, using Eclipse/Netbeans;
>
> File->New->Avalon->Component API
>All the parts that the Component API should have is managed by the IDE. I can
>right-click and ask for the documentation window. I can ask to create a JUnit
>based validation test, to be used by Component Implementations.
>
> Tools -> View Components -> APIs
>A browser to view the APIs that are available. Which versions I have. Mount
>repositories and download new components or versions. For each API, I can
>easily access the documentation, view code and validation tests.
>
> "Component API" -> Create Implementation
>The IDE creates stub(s) for me, and sets up all the I18N/L10N resources, and
>manages the declarations of dependencies.
>
> "Component API" -> Create Support Implementation -> Web
>I imagine that the IDE PlugIn supports a couple of standard Support
>Implementation systems, or even allow extensions to be plugged-in. For
>instance, a Web User Interface is perhaps a typical Support Implementation.
>A SOAP access wrapper may be another.
>
> File -> New -> Avalon -> Application
>Allows me to pick and choose Component Implementations, and the IDE plug-in
>will track missing dependencies, will include the Component APIs required and
>package it all.
>
>This is just the beginning of such a vision. I hope everyone can see the
>elegance if/when we could reach such a state.
>
>
>I have started on such a tool several time, and I think others have also
>thought about it, and I bet the reason why it doesn't exist by now is the
>lack of packagin specifications. It is not possible to start on such a IDE
>plug-in, since there is no standard on what constitutes a component.
>
>I hope we can spend a little bit of time defining exactly that.
>
>1. How is a Component API packaged?
>
>2. How is a Component Implementation packaged?
>
>3. How is an Assembled Application packaged?
>
>This will already give us plenty of room for fantastic tools to be developed.
>
>Answering the 3. question first should be the easiest, since that is related
>to the Container where we deploy.
>Well, that is not entirely true, because the container is only interested in
>the runtime aspect of the Application, and doesn't care about installation,
>versioning (of entire app), documentation and to some extent configuration
>handling.
>Phoenix was more explicit about the packaging than Merlin is, but we need to
>nail this one down more precisely. Not because we need to satisfy Merlin, but
>to satisfy tools' need for a specification in this area.
>
>I would like not to go into specifics about what _I_ believe to be a good
>packaging specification for the above 3 (I haven't been thinking too much
>about Container Extensions and Support Implementations), but let everyone
>digest what I have just written.
>
>At the end of this discussion, I would like to see the following
>exit-conditions;
>
>1. Packaging specifications for at least the 3 core packages (api, impl and
>app).
>
>or
>
>2. The community decides that this is not a concern and should not be part of
>Avalon core.
>
>
>And in the event of 1., the follow-up question would then be,
>Is it in Avalon's interest to host IDE tools for Avalon development?
>
>
>I hope I have provided some food for thought.
>
>Niclas
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 02 November 2003 05:15, Leo Simons wrote:
> One reason that has often been quoted is that,
> whereas class/code management, and to a lesser extend
> configuration/metadata management, is an area where there exists lots of
> expertise. We know relatively well how to deal with those and come up
> with a solution that works for the vast majority of problem spaces.
Good point. Do what you are good at... :o)
> More "general" resource management is much more difficult, as there is
> no "general" kind of resource; just about every resource that is only
> very loosely coupled tocode will be more specific to a (category of)
> problem space(s).
Let's create the expertise.
IMHO, generalizations are only possible after experiencing enough specifics,
to be able to recognize the abstractions. It is almost impossible to bring a
general solution to the table with going through a larger set of specific use
cases.
But I feel we probably have enough use cases within the community to start
this now.
> If I'm to fully digest all the implications of your words, I think I'll
> need a lot more "context". I learn well by example :D
;o) I learn by teaching !!
My plan for the near future is to take the experience from my "Ant based
packaging" (no special tasks) and extract what I think is useful, and put
that forward as a starting point. I have also started to look into a Eclipse
plug-in.
> If there's people to do the work, again, IMO it fits our charter,
> so I think we're pretty open that kind of thing.
Overall, rather encouraging words. Thanks.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> Avalon today is 100% about CODE and METADATA.
>
> Avalon shy away from all kind of RESOURCES, whether they are pertinent to the
> Avalon context or not. I don't know if this intentional or not.
Not going into the rest of the RT (need more time to digest), some
background perhaps...One reason that has often been quoted is that,
whereas class/code management, and to a lesser extend
configuration/metadata management, is an area where there exists lots of
expertise. We know relatively well how to deal with those and come up
with a solution that works for the vast majority of problem spaces.
More "general" resource management is much more difficult, as there is
no "general" kind of resource; just about every resource that is only
very loosely coupled tocode will be more specific to a (category of)
problem space(s).
Since, with avalon, we have the tendency to always strive to the "very"
end of the "generic" scale, we've always kinda shunned away from
attempting to deliver generic resource management.
That does not take away that there is a real *need* for a/some resource
management solution(s) that integrate(s) with the rest of the platform.
Cocoon is a perfect example (being focussed about "content", which is
definately classifiable as a "resource"), and there's many more (like
the business rules/workflow area where often a "rule" or "process" is
more like a generic resource than like concrete code, the GUI/TUI/WUI
world, ...)
<snip/>
> I have started on such a tool several time
<snip/>
> I would like not to go into specifics about what _I_ believe to be a good
> packaging specification for the above 3 (I haven't been thinking too much
> about Container Extensions and Support Implementations), but let everyone
> digest what I have just written.
If I'm to fully digest all the implications of your words, I think I'll
need a lot more "context". I learn well by example :D
> 1. Packaging specifications for at least the 3 core packages (api, impl and
> app).
>
> or
>
> 2. The community decides that this is not a concern and should not be part of
> Avalon core.
even if it is not part of "core", it can be a "standard extension" or
something like that. The packaging stuff fits the avalon charter pretty
well. IIRC, we already decided in the past that this is an area we're
willing to delve into :D
> And in the event of 1., the follow-up question would then be,
> Is it in Avalon's interest to host IDE tools for Avalon development?
sure! If there's people to do the work, again, IMO it fits our charter,
so I think we're pretty open that kind of thing.
All this is in pretty generic terms, of course. Personally, this is not
my area of interest atm, but I know there's several people quite anxious
to work on the same things as you :D
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Monday 03 November 2003 22:00, Berin Loritsch wrote:
>
>>Niclas Hedhman wrote:
>>
>>>Sorry, what is "JMX Advanced Dynamic Loading"??
>
>
>>It is in the JMX spec. It is how JAR resources are resolved in JMX
>>packaged JARs (as well as the classes). That will help us make JARs that
>>are components in themselves, which in turn will help with the development/
>>assembly time/IDE tool integration process.
>
>
> Will look into it. I almost assume it is in the 2.0 spec, no?
It's in the JMX 1.2 version. The 1.2 spec has some refinements to the the
previous version's. It is identified in Chapter 8.
>>BTW, I am on JSR 198 which is about a common plugin API for Java IDEs.
>>If we need to ensure some special features, please let me know. I have
>>already ensured that we have callbacks for pre/post build so that we
>>can ensure the metadata is generated each time we recompile a component.
>>That will help with debugging components.
>
>
> Will keep that in mind.
>
:)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 November 2003 22:00, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> > Sorry, what is "JMX Advanced Dynamic Loading"??
> It is in the JMX spec. It is how JAR resources are resolved in JMX
> packaged JARs (as well as the classes). That will help us make JARs that
> are components in themselves, which in turn will help with the development/
> assembly time/IDE tool integration process.
Will look into it. I almost assume it is in the 2.0 spec, no?
> BTW, I am on JSR 198 which is about a common plugin API for Java IDEs.
> If we need to ensure some special features, please let me know. I have
> already ensured that we have callbacks for pre/post build so that we
> can ensure the metadata is generated each time we recompile a component.
> That will help with debugging components.
Will keep that in mind.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> On Monday 03 November 2003 21:31, Berin Loritsch wrote:
>
>>As to how to manage the JARs and resources I do have some thoughts of my
>>own. I will be reading the entire RT in detail, but have not had the time
>>to yet. Initial thought: use the JMX Advanced Dynamic Loading mechanism to
>>resolve these things.
>
>
> Sorry, what is "JMX Advanced Dynamic Loading"??
>
> I can't find anything with such a name.
> Also, at this time I can't see how JMX can help. I am talking mainly
> "development/assembly time" and IDE/tool integration.
>
It is in the JMX spec. It is how JAR resources are resolved in JMX
packaged JARs (as well as the classes). That will help us make JARs that
are components in themselves, which in turn will help with the development/
assembly time/IDE tool integration process.
BTW, I am on JSR 198 which is about a common plugin API for Java IDEs.
If we need to ensure some special features, please let me know. I have
already ensured that we have callbacks for pre/post build so that we
can ensure the metadata is generated each time we recompile a component.
That will help with debugging components.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 03 November 2003 21:31, Berin Loritsch wrote:
> As to how to manage the JARs and resources I do have some thoughts of my
> own. I will be reading the entire RT in detail, but have not had the time
> to yet. Initial thought: use the JMX Advanced Dynamic Loading mechanism to
> resolve these things.
Sorry, what is "JMX Advanced Dynamic Loading"??
I can't find anything with such a name.
Also, at this time I can't see how JMX can help. I am talking mainly
"development/assembly time" and IDE/tool integration.
Cheers,
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
> Hi all,
>
> IMHO, Avalon is concentrating too much from the POV of the Container and not
> very much from POV of the Application Integrator (AI).
>
> Perhaps this is so due to the perception that AI have a lot of time to create
> an application using the blocks available, and that he/she doesn't really
> need any powerful tools. I beg to differ, as I have expressed many times
> before.
>
> In order to be able to create tools for the AI, we have to define a
> specification on how the Component Author (CA) is to package the
> component(s), and it is my intention with this RT to kick off such a
> discussion.
>
> Eventually, once this specification is nailed down, I and/or others can start
> on powerful tools, not only for the AI but also for the CA. We will kill two
> flies in one go, so to speak.
>
> So, what is the problem??
>
> Avalon today is 100% about CODE and METADATA.
>
> Avalon shy away from all kind of RESOURCES, whether they are pertinent to the
> Avalon context or not. I don't know if this intentional or not.
> In any event, a COMPONENT consists of all of the above, and if one or the
> other is completely missing, it is not a component anymore.
>
<snip/>
All of these things work together, so I guess the question here is what whould
we work towards? Gettting 70% on everything and then filling in the details?
As to how to manage the JARs and resources I do have some thoughts of my own.
I will be reading the entire RT in detail, but have not had the time to yet.
Initial thought: use the JMX Advanced Dynamic Loading mechanism to resolve these
things.
When I have read the proposal in detail, I can present some more focused
comments.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
>>>Item 9, I am a little bit split over myself. Sometimes I feel that the
>>>container should be able to provide a Management Interface automatically,
>>>but how would it know what is part of management, and what is part of the
>>>components normal function. TBD.
>>>
>>>
>>It depends on the type of management we are exposing I suppose. One of the
>>thoughts on this was the JMX integration with Phoenix. The container used
>>metadata to construct the JMX interface, and the proxy to manage the
>>component in question.
>>
>>
>
>You are probably right. But does Merlin have such support?
>
Partially - the kernel is JMX controllable and Appliance also but not
exposed yet. More work needed on a container listener before this is
completed.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Niclas Hedhman <ni...@hedhman.org>.
Writing long RTs can have the downside of generating long replies ;o)
On Monday 03 November 2003 23:09, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> > 1. Naming and Identification
> > 2. Versioning
> > 3. Dependencies
> > 4. LifeStyle
> > 5. Container/Environment Requirements
> > 6. Third-Party Requirements
> > 7. Javadoc and other documentation.
> > 8. Internationalization & Localization
> > 9. Management Interface
> >
> >
> > I don't intent to elaborate on these at this point in time, but would
> > like to mention that item 2-5 is pretty much nailed down as it is today.
> > Also, item 6, refers to stuff like jars/classes and resources have to be
> > packaged into WAR file in a particular way.
>
> Ok. With 1, how do you think it should work? Right now we have the
> ServiceManager to access the components we need, and we map it via
> the @avalon.dependency tag. Or are you thinking of something else?
Well that is Ok within the container, but I am aiming a little bit towards the
DPML aspect. How do identify a packaged component without inspection of the
package content? This is fairly important if we get to operate some type of
central component repos/libraries. And from that follows the "nice future
problem";
If Component N, written by Niclas, declares a dependency on Component B,
written by Berin, how does developer D know how to obtain Component B?
> Also, 6-8 are not really addressed either. We have support for i18n/l10n,
> but not in the sense of being able to provide one way to support the
> resources in a consistent way. IOW, it is up to the component author to
> know the keys for the i18n messages, and in no way can an application
> integrator override what is packaged in the JAR. It would be very
> important to export the i18n keys in a component JAR so that we can also
> tool that. We would provide the values of the keys as well so that we can
> turn it over to translators to do their jobs.
Exactly!!
The issue gets even trickier, because the ResourceBundle system in the JDK is
very powerful. I18N'd icons and images also has to be kept in mind. As a
Framework (server framework or not), I think we could at IDE tool level,
provide "best practices" for I18N works, as well as support "language packs"
"on to" components. (I think it is only a matter of loading a jar for each
lang-pack for the server itself, but IDE tool must handle it.)
> JavaDocs and other docs should be pointed to, not stored in the JAR itself.
> That would require an internet connection (or fileshare connection) to
> download the info (possibly JARed itself) and plug it in to the help
> system. Perhaps this is something I should suggest to the JSR 198 team.
I am a little bit split on this. When I was in the USA and had 3x45MBps
connection to the Internet, for sure a central resource is good. But most of
the time, I think a lot of people are offline or semi-offline (slow conn), so
a local copy is good.
Perhaps that a tool package "mycomp.zip" and "mycomp-doc.zip" separately, and
if you want local copy....
> > Item 9, I am a little bit split over myself. Sometimes I feel that the
> > container should be able to provide a Management Interface automatically,
> > but how would it know what is part of management, and what is part of the
> > components normal function. TBD.
>
> It depends on the type of management we are exposing I suppose. One of the
> thoughts on this was the JMX integration with Phoenix. The container used
> metadata to construct the JMX interface, and the proxy to manage the
> component in question.
You are probably right. But does Merlin have such support?
Did tags in source create MBeans, or were they created dynamically in runtime,
if so where was the metadata stored?
> > First of all, I would like people to recognize that we actually have 3
> > different packages to deal with;
> >
> > 1. Component APIs
> > 2. Component Implementations
> > 3. Support Implementations.
> > 4. Assembled Applications
> > 5. Container Extensions
> How would these five things map to the three packages?
Typing error; 5 packages (it started out 3 from my current Ant build system
;o) )
> > Component API
> > ============
> > The Component API specifies the programmatic interfaces and sometimes
> > provides some value objects, but very little else code.
> > It should (must), however, provide extensive documentation, javadoc and
> > others, about the semantics, explicit or implied, of the API.
> > It should probably contain I18N and L10N resources where appropriate.
> Agreed to a point. If there are I18N and L10N resources that are specific
> to the API, then yes. However the implementation will have a host of other
> resources that are necessary for that implementation. There is no way the
> API can or even should anticipate the needs of the implementations.
I think we are basically in agreement. In _most_ cases, the implementation is
in control of a lot. However, I have component specs that have resources
being part of the spec. And in a single case, where I have one very specific
API and dozens of implementations (serial port communication protocols), I
"inherit" all the resources from the API... ;o)
> The API portion of the JAR is fairly small typically.
You mean the JAR portion of the API?
> > Component Implementations
> > =====================
> JavaDocs automatically inherit from interfaces or superclasses if they can
> be found in the "doc path". So the JavaDocs side of things should be
> easily inherited.
I have never used external links or whatever they call it. I assume any URL is
ok.
> Docs for a particular implementation of a component should be specific to
> how to configure it, or some of the advanced features that the
> implementation allows.
Correct. It should also define behaviours, not only usage descriptions.
> The component implementation typically has meta info which identified
> component level dependencies, identification, and versioning.
Yes, and configuration specification, default configurations, context entries
and more to come I guess.
> > Support Implementations
> > ==================
> > The Support Implementation does not implement the Component API, but
> > provides some explicit additional service to a particular Component API.
> > An example of a support implementation is a Web User Interface to a
> > particular Component API (or even Component Implementation).
>
> IOW, it is a component of a different type. It can specify alternative
> interfaces to the system.
Yes, that is a better way to put it.
> > I would like not to go into specifics about what _I_ believe to be a good
> > packaging specification for the above 3 (I haven't been thinking too much
> > about Container Extensions and Support Implementations), but let everyone
> > digest what I have just written.
>
> I think that is as good a place to start as any. The hardest part in a
> project is the first step. I recall the first (and only) time I went
> repelling. The first step was the hardest, but once it was taken, it was
> all downhill from there. ;P Seriously though, I would rather start with
> the ideas of someone who put some thought into it, and refine and refactor
> from there.
See separate mail. I have started at the "server side" first, and will work
backwards towards the Component API. I think things will fall in place
one-by-one because of need and they can be ticked off as we go along. XP
style, don't design up front, you ain't gonna need it.
So, I am working to understand all the small details of Merlin (It will be
Merlin only from my part) and will build a Eclipse plug-in that can do some
Assembly, by inspecting Component Impl. And I take it from there...
> > exit-conditions;
> > 1. Packaging specifications for at least the 3 core packages
> > 2. The community decides that this is not a concern and should not be
> > part of Avalon core.
> I prefer 1.
> > And in the event of 1., the follow-up question would then be,
> > Is it in Avalon's interest to host IDE tools for Avalon development?
>
> Yes. However, unless it is eclipse, I think the licensing of the IDE APIs
> are unclear, so building them would be tricky.
I am want to dive into Eclipse, because a few months down the line I think I
need to build a new commercial app on top of it. Combine the learning with
Avalon development.
> > I hope I have provided some food for thought.
> You sure did.
Now, I hope I can some money where my mouth is, and deliver upon a promise...
I love when pressure builds and ulsters erupts. 2 fulltime jobs, opensource
and pregnant wife.... When am I going to have time to play games ???
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Block Packaging
Posted by Berin Loritsch <bl...@apache.org>.
Niclas Hedhman wrote:
<snip/>
> In order to be able to create tools for the AI, we have to define a
> specification on how the Component Author (CA) is to package the
> component(s), and it is my intention with this RT to kick off such a
> discussion.
I believe this is an important feature, and it is of interest.
>
> Eventually, once this specification is nailed down, I and/or others can start
> on powerful tools, not only for the AI but also for the CA. We will kill two
> flies in one go, so to speak.
:) Kool.
>
> So, what is the problem??
>
> Avalon today is 100% about CODE and METADATA.
>
> Avalon shy away from all kind of RESOURCES, whether they are pertinent to the
> Avalon context or not. I don't know if this intentional or not.
> In any event, a COMPONENT consists of all of the above, and if one or the
> other is completely missing, it is not a component anymore.
True, we do need a more wholistic view of the Component world, and we should be
farther along on this than we are.
>
>>>From my perspective I see the following resources and metadata (some metadata
> could be considered a resource and vice versa, so I klump them together),
> being fairly central to most components;
>
> 1. Naming and Identification
> 2. Versioning
> 3. Dependencies
> 4. LifeStyle
> 5. Container/Environment Requirements
> 6. Third-Party Requirements
> 7. Javadoc and other documentation.
> 8. Internationalization & Localization
> 9. Management Interface
>
>
> I don't intent to elaborate on these at this point in time, but would like to
> mention that item 2-5 is pretty much nailed down as it is today.
> Also, item 6, refers to stuff like jars/classes and resources have to be
> packaged into WAR file in a particular way.
Ok. With 1, how do you think it should work? Right now we have the
ServiceManager to access the components we need, and we map it via
the @avalon.dependency tag. Or are you thinking of something else?
Also, 6-8 are not really addressed either. We have support for i18n/l10n,
but not in the sense of being able to provide one way to support the resources
in a consistent way. IOW, it is up to the component author to know the keys
for the i18n messages, and in no way can an application integrator override what
is packaged in the JAR. It would be very important to export the i18n keys
in a component JAR so that we can also tool that. We would provide the values
of the keys as well so that we can turn it over to translators to do their jobs.
JavaDocs and other docs should be pointed to, not stored in the JAR itself.
That would require an internet connection (or fileshare connection) to download
the info (possibly JARed itself) and plug it in to the help system. Perhaps
this is something I should suggest to the JSR 198 team.
> Item 9, I am a little bit split over myself. Sometimes I feel that the
> container should be able to provide a Management Interface automatically, but
> how would it know what is part of management, and what is part of the
> components normal function. TBD.
It depends on the type of management we are exposing I suppose. One of the
thoughts on this was the JMX integration with Phoenix. The container used
metadata to construct the JMX interface, and the proxy to manage the component
in question.
> First of all, I would like people to recognize that we actually have 3
> different packages to deal with;
>
> 1. Component APIs
> 2. Component Implementations
> 3. Support Implementations.
> 4. Assembled Applications
> 5. Container Extensions
How would these five things map to the three packages?
>
> Existing examples;
> Example of a Component API = Generator
> Example of an Implementation = FileGenerator
> Example of an Application = A configured Cocoon instance
>
> Imaginary Examples;
> Example of Support Implementation = Web interface to Calendar
> Example of Container Extension = JINI based lookup
>
> I always get the objection that, for instance, the Generator is so simple that
> we don't need to separate it out.
> Not to get too deep into that discussion again, let me just say, yes the code
> is simple, but look at the list above.
I think that for the Avalon team, API/Implementation separation is an accepted
good practice (even at the JAR level). The Cocoon team would need some
convincing though.
> Component API
> ============
> The Component API specifies the programmatic interfaces and sometimes provides
> some value objects, but very little else code.
> It should (must), however, provide extensive documentation, javadoc and
> others, about the semantics, explicit or implied, of the API.
> It should probably contain I18N and L10N resources where appropriate.
Agreed to a point. If there are I18N and L10N resources that are specific to
the API, then yes. However the implementation will have a host of other
resources that are necessary for that implementation. There is no way the
API can or even should anticipate the needs of the implementations.
I still think JavaDoc/other Docs should be pointed to, possibly a separate
JAR that can be incorporated into the help system--or if need be a separate
help system for the plugin.
The API portion of the JAR is fairly small typically. If the documentation
is included in the API jar, then that JAR should be compressed (not required,
but definitely a plus if we have low bandwidth). I do have to worry about
low bandwidth clients and I am looking at a good way to manage deployment
in this environment.
> Component Implementations
> =====================
> A lot of code typically goes into creating a component.
> An implementation can often reuse chunks of the Component API documentation.
> In fact, it feels almost like documentation should be inherited, albeit we
> don't have such a mechanism.
> I18N and L10N are big issues.
> Implementations will support one, few or all LifeStyles.
> They Depend on at least its own Component API (but this dependency is
> different from the dependency in Avalon), but often on many other Component
> APIs and sometimes Component Implementations. This also refers back to
> Identification and Versioning.
> Often the Component Implementation have many specific requirements from the
> Container/Environment and often 3rd Party requirements as well, such as JDBC
> drivers, external config file entries, user authentications and what not.
JavaDocs automatically inherit from interfaces or superclasses if they can be
found in the "doc path". So the JavaDocs side of things should be easily
inherited.
Docs for a particular implementation of a component should be specific to how
to configure it, or some of the advanced features that the implementation
allows.
The component implementation typically has meta info which identified component
level dependencies, identification, and versioning. As to other types of
3rd party requirements, they are somewhat specified in the Context meta info,
but could use some real-world examples to make it better.
>
> Support Implementations
> ==================
> The Support Implementation does not implement the Component API, but provides
> some explicit additional service to a particular Component API.
> An example of a support implementation is a Web User Interface to a particular
> Component API (or even Component Implementation).
IOW, it is a component of a different type. It can specify alternative
interfaces to the system.
>
> Container Extensions
> ================
> In rare occassions a Component Implementation may require a particular
> Container Extension to be present.
> Container Extensions are slightly outside the scope of this RT, so I leave it
> as a special dependency case.
:) We will keep it in mind, but we will hammer it out at a later time.
> Assembled Applications
> ==================
> I have been struggling with the question "Does an Assembled Application have
> its own code?"
> The argument is that you need some level of GLUE between the Components to
> make them work.
> The counter-argument would be that, that GLUE is in itself a Component
> Implementation, that implements an "Application Component API".
> The more I have investigated the "counter-argument", the stronger I believe in
> it. One would establish a few "Application Component API"s for different
> similar applications.
> That would then mean that an Assembled Application is ONLY the components, and
> the "configuration" and "wiring" of these components (Merlin terms;
> block.xml, Phoenix terms; configuration.xml + assembly.xml ).
I can see some truth to that. The GUIApp Swing framework I work on typically
has the same interface to startup and use the application. Things do work well
together, so once it is set up it works wonderfully.
> So where does all of this bring us??
> ==========================
> I strongly believe that for each of the above sub-system, we need to SPECIFY a
> packaging format that are tool-friendly.
>
> I have a vision, using Eclipse/Netbeans;
>
Don't forget their corporate cousins: JBuilder and IDEA. When JSR 198
is released to the world, we should support it directly. It will be only
a matter of time before the JSR is supported directly.
<snip/>
> This is just the beginning of such a vision. I hope everyone can see the
> elegance if/when we could reach such a state.
Excellent.
> I have started on such a tool several time, and I think others have also
> thought about it, and I bet the reason why it doesn't exist by now is the
> lack of packagin specifications. It is not possible to start on such a IDE
> plug-in, since there is no standard on what constitutes a component.
>
> I hope we can spend a little bit of time defining exactly that.
>
> 1. How is a Component API packaged?
>
> 2. How is a Component Implementation packaged?
>
> 3. How is an Assembled Application packaged?
>
> This will already give us plenty of room for fantastic tools to be developed.
:P The greatest vote on how it is to be done goes to the doer, and not the
adviser. So we can start with your vision of how to package things, and move
from there. So far the only requirements on packaging come from Merlin and
Phoenix. Merlin is a bit looser in that it specifies the MANIFEST.MF entries
that should be specified (agreed to standard packaging from Java), and then
ther are things like block.xconf and the Phoenix packaging things.
> Answering the 3. question first should be the easiest, since that is related
> to the Container where we deploy.
> Well, that is not entirely true, because the container is only interested in
> the runtime aspect of the Application, and doesn't care about installation,
> versioning (of entire app), documentation and to some extent configuration
> handling.
> Phoenix was more explicit about the packaging than Merlin is, but we need to
> nail this one down more precisely. Not because we need to satisfy Merlin, but
> to satisfy tools' need for a specification in this area.
>
> I would like not to go into specifics about what _I_ believe to be a good
> packaging specification for the above 3 (I haven't been thinking too much
> about Container Extensions and Support Implementations), but let everyone
> digest what I have just written.
I think that is as good a place to start as any. The hardest part in a project
is the first step. I recall the first (and only) time I went repelling. The
first step was the hardest, but once it was taken, it was all downhill from
there. ;P Seriously though, I would rather start with the ideas of someone
who put some thought into it, and refine and refactor from there.
> At the end of this discussion, I would like to see the following
> exit-conditions;
>
> 1. Packaging specifications for at least the 3 core packages (api, impl and
> app).
Sounds reasonable.
>
> or
>
> 2. The community decides that this is not a concern and should not be part of
> Avalon core.
I prefer 1.
> And in the event of 1., the follow-up question would then be,
> Is it in Avalon's interest to host IDE tools for Avalon development?
Yes. However, unless it is eclipse, I think the licensing of the IDE APIs
are unclear, so building them would be tricky.
> I hope I have provided some food for thought.
You sure did.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org