You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Peter Donald <pe...@realityforge.org> on 2004/07/09 01:15:28 UTC
Another Development List?
Hi,
Is there another development list or something? A bunch of
changes seem to be committed and I can no notification let
alone discussion of these moves. Given that some of the
changes seem rather unwise I wonder how they are getting
approved.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Peter Donald" <pe...@realityforge.org>
> I assume there is areas
> that other excalibur people could offer advice on.
Probably, I agree. But I also know the speed of those discussions and I do
have a fixed delivery date. What I'm doing in my branch can be discarded, no
hard feelings, but it will be used in a project going to production next
month. The coin always have two sides, attention to that.
Cheers,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by Peter Donald <pe...@realityforge.org>.
hammett wrote:
> ----- Original Message -----
> From: "Peter Donald" <pe...@realityforge.org>
>
>>A bunch of changes seem to be committed and I can no notification let
>>alone discussion of these moves.
>
> Really? Where? I haven't seen any modifications being applied to the main
> trunk.
The things I am concerned about that are occuring in the
main branch are thinks like duplication of the source trees
(see containerkit/**) - presumably an effort to reorganize
but without discussion.
My bunch of modification are being committed the the branch
wisely
> called 'fortress-experiments'.
> After finalized I'll explain what I did, why I did (the use cases) and ask
> for opinions. If everybody likes it, I might merge it back to the main
> trunk, but at the moment I really need to get job done ASAP - yes, I have a
> gun pointed to my head again! :-)
I also think that this is less than optimal. You can keep
developing on the branch by your own but it is going to be
hard to claim that it is a group effort and hard to get it
accepted by everyone.
For example I think it is far more useful to move to a
single attribute toolkit (be that commons-attributes or
metaclass or whatever) rather than a hodge podge of existing
solutions. I am fairly familiar with the area (I was the
primary author of metaclass) and it would have been good to
seek feedback before it is done. I assume there is areas
that other excalibur people could offer advice on. By
seeking their advice you are more likely to get buy in and
more likely to have other people working on the project. Not
doing this is just going to drive people away.
If excalibur is not going to be a community based project
then I am not sure what purpose it will serve or value it
will give.
--
Cheers,
Peter Donald
*-------------------------------------------*
| "You can't depend on your eyes when your |
| imagination is out of focus." -Mark Twain |
*-------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Peter Donald" <pe...@realityforge.org>
> A bunch of changes seem to be committed and I can no notification let
> alone discussion of these moves.
Really? Where? I haven't seen any modifications being applied to the main
trunk. My bunch of modification are being committed the the branch wisely
called 'fortress-experiments'.
After finalized I'll explain what I did, why I did (the use cases) and ask
for opinions. If everybody likes it, I might merge it back to the main
trunk, but at the moment I really need to get job done ASAP - yes, I have a
gun pointed to my head again! :-)
Cheers,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Leo Simons" <ls...@jicarilla.org>
> What do others think? Is "commit-then-review" a bad idea?
Nah.
> With regard to the experiments hammett is doing, I hope its been made
> clear that they are just experiments, and that we agree this radical
> stuff isn't actually the way forward.
At this point they are just experiments, but I don't see why it couldn't be
on Fortress 1.2. Nothing has changed for old Fortress users - that what test
cases had proven - and if one needs a container that supports interceptors,
voila. I think the Keel folks may find good uses for that. But wait 'ill
I've finished it, and my explanation email.
Cheers,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Project layout
Posted by Peter Donald <pe...@realityforge.org>.
Leo Simons wrote:
> Build partitioning
> ------------------
> When working with multiproject builds, I've found it very advantageous
> to not use a very flat directory structure, but actually partition up
> into several small directories, ie a deeper structure. I believe a
> useful strategy is to split things up along the axis of
I have learnt almost exactly the opposite. You can not force
dependency structure by where a source tree lives.
> I still think we should split up the repository into a few categories. I
> guess it maybe is better to just have
>
> 1) components: the independently reusable things
> 2) fortress: the fortress subprojects
Why is not fortress a component? It is an "independently
reusable things". At what point does a component get
migrated up?
I will say again that I think that it is best to group code
trees based on what elements will be worked on in concert.
To reiterate the main groups I see being "ecm", "fortress"
and "instrument".
> 3) deprecated: stuff we really don't want the other projects
> depending on
Deprecated code should be archived up tagged and removed. We
do not want excaliburs svn repo to act as a dumping ground
for dead code.
>> * Why separate out deprecated elements?
>
>
> The rationale is that you can
>
> cd components
> maven multiproject:install
>
> and make sure you're not using any deprecated materials.
That is not true. The deperecated components will be sucked
from local repo anyways so this makes no difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Project layout
Posted by Leo Simons <ls...@jicarilla.org>.
Build partitioning
------------------
When working with multiproject builds, I've found it very advantageous
to not use a very flat directory structure, but actually partition up
into several small directories, ie a deeper structure. I believe a
useful strategy is to split things up along the axis of
"core stuff" -------------------------- "non-core optional stuff"
"no dependencies" --------------------- "many dependencies"
ie make the tree organized loosely like a gump dependency tree.
This allows us to collapse some versioning nightmares, makes it easier
to build only a part of a project, and makes it easy to spot and avoid
potentially circular dpeendencies.
Sloppy partitioning
-------------------
A few days ago, I restructured the svn repository into four categories:
1) containerkit: the independently reusable things fortress
depends on
2) fortress: the fortress subprojects
3) components: the independently reusable things fortress does not
depend on
4) deprecated: stuff we really don't want the other projects
depending on
(and buildsystem/ and site/ as "augmented" stuff)
I didn't think it through well enough -- there's a flaw in this
structure: fortress depends on sourceresolve and pool, but these are in
"components", not "containerkit". That's because I thought of these as
more reusable components. Whoops. Incosistency.
I still think we should split up the repository into a few categories. I
guess it maybe is better to just have
1) components: the independently reusable things
2) fortress: the fortress subprojects
3) deprecated: stuff we really don't want the other projects
depending on
the ugly bit here is that some of these components depend on
fortress-meta. Maybe a good way to fix that is to use metaclass+qdox for
our metadata (de)serialization.
There is more uglyness surrounding excalibur-testcase. Some of the
component have tests that depend on it. That's a big TODO.
Moving stuff around
-------------------
> * Why separate out deprecated elements?
The rationale is that you can
cd components
maven multiproject:install
and make sure you're not using any deprecated materials.
> Isn't that going to lead to more
> churns as components are moved between different lifecycles?
my thinking was that 'svn move' is actually a very easy way to mark
things as deprecated. IE
svn copy \
-m "Save off excalibur-logger snapshot before deprecating it" \
https://svn.apache.org/repos/asf/excalibur/trunk
https://svn.apache.org/repos/asf/excalibur/branches/Excalibur-Logger-Before-Depreaction
svn move \
-m "Deprecating excalibur-logger in favour of foo-logger" \
https://svn.apache.org/repos/asf/excalibur/trunk/containerkit/logger \
https://svn.apache.org/repos/asf/excalibur/trunk/deprecated/
should be very easy and efficient. However, it seems that svn is not as
good at merging move changes into a locally modified copy as I thought
it was. Shame.
> WHy not
> break the hierarchy up in how they are used? (ie why not have ecm/,
> fortress/, instrument/ etc as base dir names)
Well, like I said above, I think its nice to have a deeper tree structure.
> yadda yadda yadda
please do yadda yadda on a little more ;)
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
AOP != Interceptors (was: something else...)
Posted by Leo Simons <ls...@jicarilla.org>.
hammett wrote:
>>>However I would also be very concerned that one of the many numerous
>>>"AOP" toolktis were not considered.
>>
>>same here...bob lee's is supposed to be good...
>
> AOP != Interceptors
true. AOP is an overused buzzword, interceptors are a useful and proven
technique ;)
> Interceptors can be explained as an around-joins, but they are more than
> that.
well, actually, you can implement various joins using interceptors (I
think the only thing you can't do using java proxies and interceptors is
caller-side aspecting or property aspecting), and people have.
If you look inside an "AOP toolkit", you'll see its often just a way to
manage the creation of interceptor chains. I think Nanning and
AspectWerkz even have an Interceptor class :-D
cheers,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by hammett <ha...@uol.com.br>.
----- Original Message -----
From: "Leo Simons" <ls...@jicarilla.org>
> > However I would also be very concerned that one of the many numerous
> > "AOP" toolktis were not considered.
>
> same here...bob lee's is supposed to be good...
AOP != Interceptors
Interceptors can be explained as an around-joins, but they are more than
that. The only thing I've enthusiastically considered was the Brian
McCallister's work on interceptors [
http://kasparov.skife.org/intercept.html ] but decided to not force fortress
to be locked into a specific project - that is not even on ASF or Codehaus.
Cheers,
hammett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by Peter Donald <pe...@realityforge.org>.
Leo Simons wrote:
>> However I would also be very concerned that one of the
many numerous
>> "AOP" toolktis were not considered.
>
> same here...bob lee's is supposed to be good...
https://dynaop.dev.java.net/
Haven't heard of it before now. If the documentation is
accurate then it should be fantastic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by Leo Simons <ls...@jicarilla.org>.
Peter Donald wrote:
> This is especially true when it is just going to create more work for
> others if they are not given enough notice. I had uncommitted files that
> I was playing around with and it was a PITA to go through the steps in
> updating my local setup. Subversion also does not deal well with things
> like inability to delete local directories that are deleted in remote
> repo due to local files that were not version controlled.
>
> In the end I had to spend about 30 minutes fixing up my local repo and
> this could have been avoided if I had been given warning that such a
> global change was imminent.
ouch! Sorry about that.
I was under the impression that subversion deals very well with these
kinds of changes. IE the appropriate svn merge command is supposed to
work since it understands and keeps track of the moves as well. Guess I
have some stuff to re-read...
> Commit then review is fine except for design changes or changes that are
> likely to break other peoples code. (Branches are much more
> free-for-all). The change in structure is what I would call a design
> issue. I think people should be allowed to have an opinion on a change
> like this before it occurs.
ok. Sound sensible enough. I'll remember to branch first in the future.
>> With regard to the experiments hammett is doing, I hope its been made
>> clear that they are just experiments, and that we agree this radical
>> stuff isn't actually the way forward. From my own experience, dabbling
>> with writing a different container or two can be a good way to better
>> learn the way existing containers work, and I have no problems with it
>> going on over here.
>
> To be honest I have not looked at it
same here...
> and I really don't have any problem
> with whatever is occuring there. I have written a couple of interceptor
> toolkits myself and know how much work and pain it can be
same here...
> so I think
> hammett is probably doing a lot fo work that we should be thankful for.
same here...
> However I would also be very concerned that one of the many numerous
> "AOP" toolktis were not considered.
same here...bob lee's is supposed to be good...
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by Peter Donald <pe...@realityforge.org>.
Leo Simons wrote:
> With regard to me moving some code around in the main trunk (of which
> apparently one or two commit messages haven't made it to the svm list),
> we briefly discussed it as part of the "Excalibur != Component
> Repository" thread and there were no objections then. If there's a
> reason why this is a bad idea please say so and its easily reverted.
I don't think there will be a problem with moving code around as such
but I think that you should at least engage the community before you
start restructuring a repository.
This is especially true when it is just going to create more work for
others if they are not given enough notice. I had uncommitted files that
I was playing around with and it was a PITA to go through the steps in
updating my local setup. Subversion also does not deal well with things
like inability to delete local directories that are deleted in remote
repo due to local files that were not version controlled.
In the end I had to spend about 30 minutes fixing up my local repo and
this could have been avoided if I had been given warning that such a
global change was imminent.
> A "commit-then-review" way of doing things involves reverting things
> every now and then, which is now less of a hassle than when we were
> doing CVS. I've found this style of development can be very efficient if
> everyone is fine with it. Since it sounds like you don't like it, we can
> put a stop to it. What do others think? Is "commit-then-review" a bad idea?
Commit then review is fine except for design changes or changes that are
likely to break other peoples code. (Branches are much more
free-for-all). The change in structure is what I would call a design
issue. I think people should be allowed to have an opinion on a change
like this before it occurs.
Theres several questions that I would imediately ask;
* Why re-use the term containerkit?
* Why is the instrument part of containerkit? (It is independent of
containers and could easily sit in its own hierarchy)
* Why is Lifecycle part of containerkit? Presumably Avalon/Merlin have
forked a version of this by now and thus would it not make sense to
migrate Lifecycle to fortress?
* Why is Logger in containerkit and monitor not?
* Why separate out deprecated elements? Isn't that going to lead to more
churns as components are moved between different lifecycles? WHy not
break the hierarchy up in how they are used? (ie why not have ecm/,
fortress/, instrument/ etc as base dir names)
yadda yadda yadda
The answers are not as important as the ability to ask them and for each
of us given the chance to influence how the changes are implemented.
> With regard to the experiments hammett is doing, I hope its been made
> clear that they are just experiments, and that we agree this radical
> stuff isn't actually the way forward. From my own experience, dabbling
> with writing a different container or two can be a good way to better
> learn the way existing containers work, and I have no problems with it
> going on over here.
To be honest I have not looked at it and I really don't have any problem
with whatever is occuring there. I have written a couple of interceptor
toolkits myself and know how much work and pain it can be so I think
hammett is probably doing a lot fo work that we should be thankful for.
However I would also be very concerned that one of the many numerous
"AOP" toolktis were not considered. Many of them are relatively mature
products that have already gone through several development cycles. They
are going to be faster, better supported and more versatile than the
toolkit in excalibur simply because they have had many more development
hours funneled into them. No offense intended hammet ;)
If they are innapropriate (ie licensing, architecture or whatever) or we
simply decide to reinvent for fun then thats fine but there should be
some discussion about it.
Theres no use in drowning the project in beuracracy so that every change
is a PITA but there should at least be some active discussion on whats
going on and what people intend to do etc.
--
Cheers,
Peter Donald
*------------------------------------------------*
| You can't wake a person who is pretending |
| to be asleep. -Navajo Proverb. |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: Another Development List?
Posted by Leo Simons <ls...@jicarilla.org>.
Peter Donald wrote:
> Is there another development list or something?
nope, at least not that I'm aware of!
> A bunch of changes seem
> to be committed and I can no notification let alone discussion of these
> moves. Given that some of the changes seem rather unwise I wonder how
> they are getting approved.
lazy consensus of course :-D
With regard to me moving some code around in the main trunk (of which
apparently one or two commit messages haven't made it to the svm list),
we briefly discussed it as part of the "Excalibur != Component
Repository" thread and there were no objections then. If there's a
reason why this is a bad idea please say so and its easily reverted.
(...)
A "commit-then-review" way of doing things involves reverting things
every now and then, which is now less of a hassle than when we were
doing CVS. I've found this style of development can be very efficient if
everyone is fine with it. Since it sounds like you don't like it, we can
put a stop to it. What do others think? Is "commit-then-review" a bad idea?
(...)
With regard to the experiments hammett is doing, I hope its been made
clear that they are just experiments, and that we agree this radical
stuff isn't actually the way forward. From my own experience, dabbling
with writing a different container or two can be a good way to better
learn the way existing containers work, and I have no problems with it
going on over here.
(...)
One thing I hope we can regain is the trust in each other that these
kinds of things are easily and openly discussed without anything
escalating. Thanks for bringing it up!
I'll be offline for the weekend, so if there's anything I need to revert
it'll have to wait I'm afraid. For people in a hurry, reverting the
trunk could be done by copying over
excalibur/tags/Pre-Repository-Restructure-20040807, then reapplying the
site changes using svn merge.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/