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 2004/01/05 19:48:42 UTC
Where do you want to go?
I posted a "feeler" question to the PMC group today just to get some initial
feedback. Considering the support from all parties, and the concerns that I
personally have, I would now like to get a bigger picture of the whole Avalon
developers group.
I have a feeling that Avalon, and specifically Merlin is focusing too much on
the enterprise. I know that the enterprise features are necessary for some
folks, but others simply do not need it. It never really had simplicity, and
to be honest I can't tell what it does and does not do. I know of a couple of
people who are concerned (and will remain nameless until they choose not to be).
To be honest, I am not in a situation where I need enterprise level architecture
anymore. I just need something simple. The current Fortress does fit my needs,
and I am almost scared to try Merlin. To be fair, I should declare what I mean
by simple. By simple, I mean that I have a set of components I need, but I
don't need security, proxying, etc. Granted, I do need to extend the lifecycle,
but that is another topic entirely.
I am not really for a cease and desist type of action, but I really want to know
if my needs are truly that distinct from where Avalon is going. For a long time
we have talked about something that would be easy to modify or easy to extend.
Many of us can prove that it can be done--but noone is interested in a complete
rebuild or new work. I don't blame them. I feel the need for simplicity is
being drowned out by the need for features.
Another thing that scares me is the rate of mutation for Merlin. You may know
what it does this week, but come back to it a couple weeks later and everything
is different. There are hundreds of commit messages that go by all the time,
and it is difficult for me to try to keep up with what is really going on.
The questions I have are this (for those who have not seen this earlier):
1) Am I alone in my concerns?
2) If not, how should we start refactoring Merlin to make it what we all need?
* please note that development should be able to continue while refactoring
occurs.
3) What about the guy with simple needs? What are we going to do for him?
4) What about extensibility? We need this if we are to survive. Right now I
get the feeling that Merlin is an all or nothing approach. Not a pick and
choose the feature set approach.
--
"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: Where do you want to go?
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> I have a feeling that Avalon, and specifically Merlin is focusing too
> much on the enterprise.
+1. I'm going to enter rant mode now. Not meaning to offend anyone though.
> I know that the enterprise features are
> necessary for some folks, but others simply do not need it. It never
> really had simplicity, and to be honest I can't tell what it does and
> does not do. I know of a couple of people who are concerned (and
> will remain nameless until they choose not to be).
that would include me. But everyone already knew that:D
> To be honest, I am not in a situation where I need enterprise level
> architecture anymore. I just need something simple.
+1
> The current
> Fortress does fit my needs, and I am almost scared to try Merlin. To
> be fair, I should declare what I mean by simple. By simple, I mean
> that I have a set of components I need, but I don't need security,
> proxying, etc.
+1. While "simple" is hard to define, here's a few pointers as to what
is not:
* excessive use of reflection (especially when it doesn't make sense;
like AbstractMerlinTestCase.setUp())
* sourcefiles that are 1000 lines long
* methods that are 300 lines long
* 5 levels of indirection / increased abstraction along the lines of
repository--1..n-->kernel--\
/-----------------------/
\-1->block-1..n->appliance-1->factory--1..n-->model--\
/--------------------------------------------------/
\-1..n->profile--1-->configuration
* instantiation of roughly 10 helper classes for the instantation of a
single component
* undocumented use of weak references
* undocumented and inconsistent use of synchronization
* lack of unit tests
* mismatch between functional use and classname
* mismatch between functional use and javadoc description
* an execution stack of 15 levels or more for the simplest tasks
several more (while less serious, many apply one way or another) can be
found at
http://lsd.student.utwente.nl/jicarilla/TooMuchMagic
> I am not really for a cease and desist type of action, but I really
> want to know if my needs are truly that distinct from where Avalon is
> going. For a long time we have talked about something that would be
> easy to modify or easy to extend.
My "[merlin] problems plugging in type 3 lifestyle" shows how hard it is
for a seasoned (wouldn't dare say "absolute authority in the field" :P)
to modify or extend merlin.
> Many of us can prove that it can be
> done--but noone is interested in a complete rebuild or new work. I
> don't blame them. I feel the need for simplicity is being drowned
> out by the need for features.
+1. It certainly feels a lot like drowning.
> Another thing that scares me is the rate of mutation for Merlin.
+1. And it is not just that new features are added every week, it is
also that api documentation, inline code comments, unit tests (etc) do
not keep up with the feature additions. Running a code analysis on the
kernel impl/src/java directory finds me 110 non-trivial issues that I
wouldn't consider even committing.
And that's in just 3 classes (arguably the core of the core package). I
would have run a unit test coverage tool on the same 3 classes, but I
can do the calculation by head - its 0%.
What I can understand is people saying unit testing or test-first is
silly, that verifying the results obtained from simple set and get
operations is a waste of time (I disagree, but I can understand why).
What I cannot understand is why the core of a robust enterprise
development platform hosted at apache (the number of open source
projects with as good a reputation to protect as apache is quite small)
deserves the mandate "final release".
> You may know what it does this week, but come back to it a couple weeks
> later and everything is different. There are hundreds of commit
> messages that go by all the time, and it is difficult for me to try
> to keep up with what is really going on.
I seem to recall that a release was held up over badly written shell
scripts a week or two ago. Had I been able to keep up, that would not
have happend (I believe I wrote the original scripts by copying the
basis from phoenix which was copied from ant which are some well-tested
scripts).
I can think of countless other examples.
> The questions I have are this (for those who have not seen this
> earlier):
>
> 1) Am I alone in my concerns?
no. Many people are starting to avoid touching avalon with ten feet
poles because of it.
I will try to answer 2) and 3) seperately.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://lsd.student.utwente.nl/jicarilla/Articles
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>> To be honest, I am not in a situation where I need enterprise level
>> architecture anymore. I just need something simple.
>> The current Fortress does fit my needs, and I am almost scared to try
>> Merlin.
>
>
> There are two important questions here:
>
> (a) why does Fortress not meet your needs?
Fortress *does* meet my needs, but needs some work which I wish I had time
to do. It needs community support.
> (b) why is Merlin scary?
The code and dependency list look almost like a spider's web to me. It's
not as clean and simple as the basic Fortress concepts.
> I can can speculate about the first, but I don't understand about the
> second. Feedback I'm getting is that Merlin is *really* easy to use -
> in fact more than a few people have commented that it is the easiest
> container they have used (within and external to Avalon).
Easy to use and easy to develop the internals are two different things.
How to add new arbitrary features that don't necessarily fall into the
Lifecycle extensions can seem to break things that I personally don't need
but others do.
> From here you should stop looking at the code and start looking at the
> composition package. The entire package is about parameterization of
> what happens at runtime. If you cannot change something though the meta
> model API than its not changeable.
To be honest, I find the inflexibility of the meta model to be a problem.
I like the work that Leo did for the arbitrary attributes that had real
objects with it. It even addressed dynamically finding classes that implemented
the attribtues.
>
> For example, Leo wants to switch in handling of Type 3 components. Well,
> based on the meta-model contract as it stands, he can't because this
> isn't an exposed parameterizable aspect under version 3.2.
But why can't it be? What's wrong with the factory/instance management
separation in Fortress? Can't that be directly supported in Merlin without
breaking contracts? Then all that is needed is to add a new factory.
> What I'm saying is - focus on understanding the meta-model defined by
> the composition package and from that everything falls into place.
> Remember, its not code driven, it model driven.
Grmbl. I think this is too much magic for the simple case. For instance,
I may have some simple component needs where magic is the last thing on
the list, but in Merlin it can't be gotten around.
>> To be fair, I should declare what I mean by simple. By simple,
>> I mean that I have a set of components I need, but I don't need
>> security, proxying, etc. Granted, I do need to extend the lifecycle,
>> but that is another topic entirely.
>
> This may not make a lot of sense but the feature profile your looking
> for will probably arrive with Merlin 3.4 - i.e. scaling to "not much".
> As Merlin moves forward it becomes less and less and enabling more and
> more.
>
> I.e. you have more choice in terms of what is is you want your container
> to be. On my machine here I have a full HTTP server running inside the
> Merlin kernel (i.e. under the internal system SPI classloader) and
> capable of monitoring and interacting with the entire meta-model. I am
> probably a few full on developer days away from having component ==
> servlet with the http server directing request to the component instance.
>
> But what is import here is that this is not feature extension - its just
> a component that happens to be running internally (it could be a logging
> system, a JMX server, a JMS adapter, an ORB, whatever). In fact the
> entire HTTP stuff is two lines of XML inside the kernel.xml (one for the
> server and one for the model listener). The more this sort of internal
> facility handling evolves, the smaller Merlin gets.
So what concerns are interwoven into Merlin that cannot be separated out?
>> Many of us can prove that it can be done--but noone is interested in a
>> complete rebuild or new work. I don't blame them. I feel the need for
>> simplicity is being drowned out by the need for features.
>
> I strong disagree with you on this point. If you take a look at the
> requirements from the James project - they need additional features but
> this is translated into activities related to pluggable feature
> handling. The same is true for the requirements coming from Turbine, the
> OpenIM project, and other external projects.
>
> Instead of looking at solving all of these feature enhancement requests
> - the approach is to (a) refactor aspect of the kernel or meta model to
> better handle custom solution requirements, and (b) where necessary,
> expose an appropriate parameterization point in the meta-model.
How about using a flexible meta-model, and not worrying about predefined
extension points. A plugin or feature package can use the new attributes
without having to perform code changes to the meta model.
>> Another thing that scares me is the rate of mutation for Merlin. You
>> may know what it does this week, but come back to it a couple weeks
>> later and everything is different. There are hundreds of commit
>> messages that go by all the time, and it is difficult for me to try to
>> keep up with what is really going on.
>
> On the Merlin system there are three separate considerations with
> respect to change:
>
> 1. changes to the XML type and block contract
> 2. changes to the kernel and model API
> 3. changes to the model and runtime implementation
>
> As far as (1) is concerned - Merlin has remained rock-solid in support
> for the component meta-data and meta-info contracts.
THat's good.
>
>> The questions I have are this (for those who have not seen this earlier):
>>
>> 1) Am I alone in my concerns?
>
> No, but I don't share the same concerns.
> I more aligned with Hammets comment ...
>
> >> My only "critic" to merlin is a better isolation of features, after
> >> that it will rule the world.
>
> And feature isolation is being addressed under the 3.4 branch. In fact
> there is a real possibility that the entire assembly package will become
> a plug replaceable extension - leaving only composition and merlin core
> as the "real" system facilities. Again, I cannot emphasis enough, spend
> some time looking at the composition package, understand the meta model,
> then start exploring.
>
>> 2) If not, how should we start refactoring Merlin to make it what we
>> all need?
>> * please note that development should be able to continue while
>> refactoring
>> occurs.
>
>
> 1. understand what exists and the architecture of the system
Very daunting
--
"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: Where do you want to go?
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I posted a "feeler" question to the PMC group today just to get some
> initial feedback. Considering the support from all parties, and the
> concerns that I personally have, I would now like to get a bigger
> picture of the whole Avalon developers group.
>
> I have a feeling that Avalon, and specifically Merlin is focusing
> too much on the enterprise. I know that the enterprise features
> are necessary for some folks, but others simply do not need it.
> It never really had simplicity, and to be honest I can't tell what
> it does and does not do. I know of a couple of people who are
> concerned (and will remain nameless until they choose not
> to be).
I could talk about a couple of nameless multi-nationals that are
building commercial product on Avalon Framework, Avalon Utilities,
Avalon Repository, and Avalon Merlin. My point is that "nameless"
individuals don't mean anything - just as my nameless multinationals
don't mean anything. What does matter are the opinions expressed
publicly - for the benefit of the community and in the spirit of
contribution.
Moving on to more concrete topics ...
> To be honest, I am not in a situation where I need enterprise level
> architecture anymore. I just need something simple.
> The current Fortress does fit my needs, and I am almost scared to
> try Merlin.
There are two important questions here:
(a) why does Fortress not meet your needs?
(b) why is Merlin scary?
I can can speculate about the first, but I don't understand about the
second. Feedback I'm getting is that Merlin is *really* easy to use -
in fact more than a few people have commented that it is the easiest
container they have used (within and external to Avalon).
My guess is that your probably thinking about "how do I make Merlin
internals do what I want" - and yes - that could be scary. But the
solution here is rather simple - take a step back and separate out the
following:
(a) bootstrapping, this is all 100% avalon-repository stuff
(same pattern could/should be applied to logging subsystem
establishment, Fortress embedding, in fact any embedding
scenario) - this means that the entry point is standard
Factory model.
(b) model creation, this is inside Merlin's DefaultFactory
where a root system and a root application meta-model
are created.
(c) followed by creation of the runtime root system and
application blocks that are handled based on supplied
parameters
From here you should stop looking at the code and start looking at the
composition package. The entire package is about parameterization of
what happens at runtime. If you cannot change something though the meta
model API than its not changeable.
For example, Leo wants to switch in handling of Type 3 components.
Well, based on the meta-model contract as it stands, he can't because
this isn't an exposed parameterizable aspect under version 3.2.
What I'm saying is - focus on understanding the meta-model defined by
the composition package and from that everything falls into place.
Remember, its not code driven, it model driven.
> To be fair, I should declare what I mean by simple. By simple,
> I mean that I have a set of components I need, but I don't need
> security, proxying, etc. Granted, I do need to extend the
> lifecycle, but that is another topic entirely.
This may not make a lot of sense but the feature profile your looking
for will probably arrive with Merlin 3.4 - i.e. scaling to "not much".
As Merlin moves forward it becomes less and less and enabling more and
more.
I.e. you have more choice in terms of what is is you want your container
to be. On my machine here I have a full HTTP server running inside the
Merlin kernel (i.e. under the internal system SPI classloader) and
capable of monitoring and interacting with the entire meta-model. I am
probably a few full on developer days away from having component ==
servlet with the http server directing request to the component instance.
But what is import here is that this is not feature extension - its just
a component that happens to be running internally (it could be a logging
system, a JMX server, a JMS adapter, an ORB, whatever). In fact the
entire HTTP stuff is two lines of XML inside the kernel.xml (one for the
server and one for the model listener). The more this sort of internal
facility handling evolves, the smaller Merlin gets.
> I am not really for a cease and desist type of action, but I really
> want to know if my needs are truly that distinct from where Avalon
> is going. For a long time we have talked about something that would
> be easy to modify or easy to extend.
Start of with understanding what Merlin is (and isn't) and from there
you will get an idea of which playground your in - either its
parameterization of the platform to do things, or, your looking at
platform customization. If its the later - a little experience in using
the platform will go a long way to understanding what the process is to
introduce change (because its not just adding a configurable classname
at line 122 - its about declaring the aspect formally in the meta model,
expressing that aspect in the model readers and writers, and
implementing the corresponding model level validation and runtime
associations.
Yes, it sounds complicated but its the same process every time.
> Many of us can prove that it can be done--but noone is interested in a
> complete rebuild or new work. I don't blame them. I feel the need for
> simplicity is being drowned out by the need for features.
I strong disagree with you on this point. If you take a look at the
requirements from the James project - they need additional features but
this is translated into activities related to pluggable feature
handling. The same is true for the requirements coming from Turbine, the
OpenIM project, and other external projects.
Instead of looking at solving all of these feature enhancement requests
- the approach is to (a) refactor aspect of the kernel or meta model to
better handle custom solution requirements, and (b) where necessary,
expose an appropriate parameterization point in the meta-model.
> Another thing that scares me is the rate of mutation for Merlin. You
> may know what it does this week, but come back to it a couple weeks
> later and everything is different. There are hundreds of commit
> messages that go by all the time, and it is difficult for me to try to
> keep up with what is really going on.
On the Merlin system there are three separate considerations with
respect to change:
1. changes to the XML type and block contract
2. changes to the kernel and model API
3. changes to the model and runtime implementation
As far as (1) is concerned - Merlin has remained rock-solid in support
for the component meta-data and meta-info contracts.
Concerning the embedded API (2), things are evolving and interfaces are
chainging (but nothing radical and nothing that has caused a problem
with people actually coding against this stuff). In fact I think it is
fair to say that the recent changes (3.0-2) have been a big plus for
anyone working on a embedded container scenarios. Yes, there will be
evolution here - the work on the 3.4 branch (which has a lot of commit
messages is dealing with refactoring of the assembly aspects - basically
moving assembly logic from runtime layer to the model). But
irrespective of the fun and excitement under the 3.4, the actual commits
related to 3.2 are almost all implementation enhancements (which is
definely safe territory for change and evolution) which bring me to
point (3).
Item (3) is and will remain open territory for change because Merlin
(implementation) is about change, evolution, development, it about
identifying what can be separated out, what is and is not a facility,
what are the extensions points, what is the containment contract? No
apologies for hundreds of commits - they reflect interest and
engagement. Think of it this way - every commit is making Merlin
smaller and smaller, less and less, and at the end of the day Avalon
will have a rock solid containment architecture and reference
implementation.
> The questions I have are this (for those who have not seen this earlier):
>
> 1) Am I alone in my concerns?
No, but I don't share the same concerns.
I more aligned with Hammets comment ...
>> My only "critic" to merlin is a better isolation of features, after
>> that it will rule the world.
And feature isolation is being addressed under the 3.4 branch. In fact
there is a real possibility that the entire assembly package will become
a plug replaceable extension - leaving only composition and merlin core
as the "real" system facilities. Again, I cannot emphasis enough, spend
some time looking at the composition package, understand the meta model,
then start exploring.
> 2) If not, how should we start refactoring Merlin to make it what we all
> need?
> * please note that development should be able to continue while
> refactoring
> occurs.
1. understand what exists and the architecture of the system
2. identify what it is that you think that we all need
3. identify where that need plays into the Merlin platform - is is a
system configuration question, is is a parameterizable aspect that
needs to be exposed?
On completion of the above you have everything you need to in order to
fulfill whatever it is the "we all need".
> 3) What about the guy with simple needs? What are we going to do for him?
Merlin 3.0 is handling simple needs for hundred of users.
> 4) What about extensibility? We need this if we are to survive. Right
> now I get the feeling that Merlin is an all or nothing approach. Not
> a pick and choose the feature set approach.
From Niclas' email to the PMC, he summarized extensibility features
either in place or in progress:
a. application deployment via repository system
b. ability to select and alternative kernel on the command line
c. ability to add custom facilities inside the kernel
d. ability to add containment listeners
e. customizable context handlers
f. customizable lifecycle stage handlers
g. ability to handle custom model implementations
h. custom component instance factory
i. custom deployment handler
j. pluggable <element> handlers in meta info and meta data description
k. customizable serialization factories
l. customizable service factories (i.e. not just local components)
m. embeddable codebase level security (on/off)
n. pluggable subject level security
Items a-e are already in-place and the majority of the rest will
probably make it within 3.4 with breaking the client component usage
contract.
What this all means is that Merlin is progressively moving to a shell
within which you put the features you need (via your components) - and
you decide if you customizing the platform or the application. But I
need to restate the point that this is "a model-driven solution".
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Giacomo Pati <gi...@otego.com>.
Niclas Hedhman wrote:
> On Tuesday 06 January 2004 14:37, Giacomo Pati wrote:
>
>>Stephen McConnell wrote:
>>
>>>As far as commit messages are concerned, please take into consideration
>>>(a) commits on implementation improvements, (b) commits related to
>>>sub-system relocation (i.e. system moving out of merlin and into avalon
>>>space such as avalon-meta, avalon-utilities, and avalon-repository and
>>>the resulting refactoring withing the merlin system implementation), and
>>>(c) commits on the 3.4 branch which deal with meta-model optimization
>>>and do not impact the client contract.
>>
>>Stephen, what should that tell me: You spread the refactoring not only
>>to the core and sub-system but also onto meta, repo, util, etc?
>
>
> Perhaps that "meta" and "repository" didn't exist pre-Merlin and is the
> beginning of the on-going, and requested, effort of breaking Merlin into
> smaller chunks of optional and replacable units.
>
> Opinions are *often* like nails. The more you hammer on them, the harder they
> stick. :o)
:-) I think it's possible to convice me. It matters the arguments :-)
Giacomo
>
> Cheers
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
--
Otego AG Tel: +41 (0)1 240 00 55
Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member Mailto:giacomo@apache.org
Hohlstrasse 216 Mailto:Giacomo.Pati@otego.com
CH-8004 Zürich Web: http://www.otego.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Tuesday 06 January 2004 14:37, Giacomo Pati wrote:
> Stephen McConnell wrote:
> > As far as commit messages are concerned, please take into consideration
> > (a) commits on implementation improvements, (b) commits related to
> > sub-system relocation (i.e. system moving out of merlin and into avalon
> > space such as avalon-meta, avalon-utilities, and avalon-repository and
> > the resulting refactoring withing the merlin system implementation), and
> > (c) commits on the 3.4 branch which deal with meta-model optimization
> > and do not impact the client contract.
>
> Stephen, what should that tell me: You spread the refactoring not only
> to the core and sub-system but also onto meta, repo, util, etc?
Perhaps that "meta" and "repository" didn't exist pre-Merlin and is the
beginning of the on-going, and requested, effort of breaking Merlin into
smaller chunks of optional and replacable units.
Opinions are *often* like nails. The more you hammer on them, the harder they
stick. :o)
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Stephen McConnell <mc...@apache.org>.
Giacomo Pati wrote:
> Stephen, what should that tell me: You spread the refactoring not only
> to the core and sub-system but also onto meta, repo, util, etc?
Avalon Meta was initially within the Merlin system (back in 2.1). It
was moved out to a separate Avalon level package and in that process
things like tags, APIs, implementation, docs, tools, etc. all evolved
and improved. That system (meta 2.0) was then factored back in to
Merlin as part of the 3.0 release.
Avalon Repository was initially based on the repository model within
Merlin 3.0. It was separated out to better handle generic systems
embedding with a priority on minimal footprint and ease of
configuration. The refactoring the repository sub-system by Alex
resulted in the separation of a set of common utilities (covering
property aggregation, criteria handling, exception reporting, and access
to environment variables). Merlin 3.2 was refactored as a system
established by the repository facility, leveraging the vastly improved
embedded support.
Merlin 3.3 (a.k.a. CVS HEAD) incorporates model listeners, the internal
kernel pluggable facilities management, and the improved thread model.
Commit level on 3.3 is rather low. Merlin 3.4 (a.k.a V-3-4 branch) is
addressing a number of aspects related to the meta-model, in particular
a review of specific classnames to address easier recognition of
function, the shifting of assembly logic from the runtime to the model,
and security aspects.
> Du you think you can convince me to change oppinion with this comment?
Just making sure you have the right information available.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Giacomo Pati <gi...@apache.org>.
Stephen McConnell wrote:
> Giacomo Pati wrote:
>
>> Concerning Merlin I once had the impression that some of the feature
>> it offers are cool (i.e. default configurations aka profiles IIRC) but
>> others aren't that much (i.e. security). ATM I'm not in need for a
>> standalone container as most of my server apps are running with
>> Phoenix' last version much better because it has JMX and that's much
>> more important to me than other features Merlin offers. Looking at the
>> current commit rate of the development it will take month until I will
>> suggest my customers to migrate from Phoenix to Merlin because of its
>> endless refactoring cycles (admittedly I might be totally wrong but
>> this is the impression it gives me).
>
>
> Giacomo:
>
> Relative to the client contract - Merlin is rock solid.
Sure, client contracts == interfaces/APIs, but this was not the issue here.
> As far as commit messages are concerned, please take into consideration
> (a) commits on implementation improvements, (b) commits related to
> sub-system relocation (i.e. system moving out of merlin and into avalon
> space such as avalon-meta, avalon-utilities, and avalon-repository and
> the resulting refactoring withing the merlin system implementation), and
> (c) commits on the 3.4 branch which deal with meta-model optimization
> and do not impact the client contract.
Stephen, what should that tell me: You spread the refactoring not only
to the core and sub-system but also onto meta, repo, util, etc?
Du you think you can convince me to change oppinion with this comment?
Cheers
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Stephen McConnell <mc...@apache.org>.
Giacomo Pati wrote:
> Concerning Merlin I once had the impression that some of the feature it
> offers are cool (i.e. default configurations aka profiles IIRC) but
> others aren't that much (i.e. security). ATM I'm not in need for a
> standalone container as most of my server apps are running with Phoenix'
> last version much better because it has JMX and that's much more
> important to me than other features Merlin offers. Looking at the
> current commit rate of the development it will take month until I will
> suggest my customers to migrate from Phoenix to Merlin because of its
> endless refactoring cycles (admittedly I might be totally wrong but this
> is the impression it gives me).
Giacomo:
Relative to the client contract - Merlin is rock solid.
As far as commit messages are concerned, please take into consideration
(a) commits on implementation improvements, (b) commits related to
sub-system relocation (i.e. system moving out of merlin and into avalon
space such as avalon-meta, avalon-utilities, and avalon-repository and
the resulting refactoring withing the merlin system implementation), and
(c) commits on the 3.4 branch which deal with meta-model optimization
and do not impact the client contract.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/ |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Giacomo Pati <gi...@apache.org>.
Berin Loritsch wrote:
<snipped/>
> I have a feeling that Avalon, and specifically Merlin is focusing too
> much on
> the enterprise. I know that the enterprise features are necessary for some
> folks, but others simply do not need it. It never really had
> simplicity, and
> to be honest I can't tell what it does and does not do. I know of a
> couple of
> people who are concerned (and will remain nameless until they choose not
> to be).
Concerning Merlin I once had the impression that some of the feature it
offers are cool (i.e. default configurations aka profiles IIRC) but
others aren't that much (i.e. security). ATM I'm not in need for a
standalone container as most of my server apps are running with Phoenix'
last version much better because it has JMX and that's much more
important to me than other features Merlin offers. Looking at the
current commit rate of the development it will take month until I will
suggest my customers to migrate from Phoenix to Merlin because of its
endless refactoring cycles (admittedly I might be totally wrong but this
is the impression it gives me).
<another-snip/>
> Another thing that scares me is the rate of mutation for Merlin. You
> may know
> what it does this week, but come back to it a couple weeks later and
> everything
> is different. There are hundreds of commit messages that go by all the
> time,
> and it is difficult for me to try to keep up with what is really going on.
Thats what I meant by 'endless refactoring impression'.
> The questions I have are this (for those who have not seen this earlier):
>
> 1) Am I alone in my concerns?
Definitively not. I second your concerns.
> 2) If not, how should we start refactoring Merlin to make it what we all
> need?
> * please note that development should be able to continue while
> refactoring
> occurs.
To be honest, I have no idea as it has grown too fast for me, too many
features that I can get an idea only by looking at the documentations.
> 3) What about the guy with simple needs? What are we going to do for him?
Thanks there is Fortress.
> 4) What about extensibility? We need this if we are to survive. Right
> now I
> get the feeling that Merlin is an all or nothing approach. Not a
> pick and
> choose the feature set approach.
I actually can see the need for a standalone container that fills the
Phoenix hole (or being a successor of it) but as a 'user' of Avalon code
most of the time I'd like to see a prioritized feature list combined
with relases they are expected to be available (I do know OS projects
cannot promise any dates so dates are really relative but releases and
their feature implementations is a way to go for it).
PS: I really do not want to offend anybody. Just take this as the
feelings from an interested Avalon user/developer since years.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Where do you want to go?
Posted by Ulrich Mayring <ul...@denic.de>.
I'd like to have a container that does everything that Phoenix does and
additionally has good end user documentation. Merlin comes closest to that.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org