You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/04/22 19:05:44 UTC
Excalibur Phase III Release Candidate 1
Excalibur Phase III Release Candidate 1 is ready for review.
You can get the packages at the usual location:
http://avalon.apache.org/~bloritsch/excalibur-dist/
Please post all comments so that we can take care of them
one at a time.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Shash Chatterjee wrote:
> Berin,
>
> Here's one more change for ComponentFactory. In newInstance(), like it used
> to be, Parameters.fromConfiguration() should only be called if the component
> is an instance of Parameterizable. This breaks backwards compatibility for
> Keel, otherwise. We have components which have configuration with
> "parameter" elements which do not have "value" attributes (and none are
> Parameterizable).
>
> I have attached a patch (but, this also includes the patch I sent earlier
> this evening).
Again, your patch is missing :(
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Shash Chatterjee <sh...@hotmail.com>.
Something's eating the attachment. I added to bugzilla:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19305
----- Original Message -----
From: "Shash Chatterjee" <sh...@hotmail.com>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Thursday, April 24, 2003 10:39 PM
Subject: Re: Excalibur Phase III Release Candidate 1
> Berin,
>
> Here's one more change for ComponentFactory. In newInstance(), like it
used
> to be, Parameters.fromConfiguration() should only be called if the
component
> is an instance of Parameterizable. This breaks backwards compatibility
for
> Keel, otherwise. We have components which have configuration with
> "parameter" elements which do not have "value" attributes (and none are
> Parameterizable).
>
> I have attached a patch (but, this also includes the patch I sent earlier
> this evening).
>
> Thanks,
> Shash
>
> ----- Original Message -----
> From: "Berin Loritsch" <bl...@apache.org>
> To: <de...@avalon.apache.org>
> Sent: Tuesday, April 22, 2003 12:05 PM
> Subject: Excalibur Phase III Release Candidate 1
>
>
> > Excalibur Phase III Release Candidate 1 is ready for review.
> > You can get the packages at the usual location:
> >
> > http://avalon.apache.org/~bloritsch/excalibur-dist/
> >
> >
> > Please post all comments so that we can take care of them
> > one at a time.
> >
> > --
> > "You know the world is going crazy when the best
> > rapper is a white guy, the best golfer is a black guy,
> > The Swiss hold the America's Cup, France is
> > accusing the US of arrogance, and Germany doesn't want
> > to go to war. And the 3 most powerful men in America
> > are named 'Bush', 'Dick', and 'Colon' (sic)".
> >
> > -----Chris Rock
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> > For additional commands, e-mail: dev-help@avalon.apache.org
> >
> >
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Shash Chatterjee <sh...@hotmail.com>.
Berin,
Here's one more change for ComponentFactory. In newInstance(), like it used
to be, Parameters.fromConfiguration() should only be called if the component
is an instance of Parameterizable. This breaks backwards compatibility for
Keel, otherwise. We have components which have configuration with
"parameter" elements which do not have "value" attributes (and none are
Parameterizable).
I have attached a patch (but, this also includes the patch I sent earlier
this evening).
Thanks,
Shash
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: <de...@avalon.apache.org>
Sent: Tuesday, April 22, 2003 12:05 PM
Subject: Excalibur Phase III Release Candidate 1
> Excalibur Phase III Release Candidate 1 is ready for review.
> You can get the packages at the usual location:
>
> http://avalon.apache.org/~bloritsch/excalibur-dist/
>
>
> Please post all comments so that we can take care of them
> one at a time.
>
> --
> "You know the world is going crazy when the best
> rapper is a white guy, the best golfer is a black guy,
> The Swiss hold the America's Cup, France is
> accusing the US of arrogance, and Germany doesn't want
> to go to war. And the 3 most powerful men in America
> are named 'Bush', 'Dick', and 'Colon' (sic)".
>
> -----Chris Rock
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
RE: Excalibur Phase III Release Candidate 1
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> If it gets in the way later, we can remove it.
I think you're both wrong.
Final doesn't enhance performance, and opening up something
can be as difficult as locking it down.
(That said, if you're going to make something final/not final,
decide early on.)
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Nicola Ken Barozzi wrote:
>
>> Leo Simons wrote, On 24/04/2003 14.46:
>>
>>> marking classes as final often results in more inlining which speeds
>>> things up considerably depending on your jvm.
>>
>>
>> ;-)) Read the article...
>
>
<snip/>
>
> On the other hand, the run-time environment and JIT compiler have more
> information about what classes are actually loaded, and can make much
> better optimization decisions than the compiler can. If the run-time
> environment knows that no classes are loaded that extend Y, then it can
> safely inline calls to methods of Y, regardless of whether Y is final
> (as long as it can invalidate such JIT-compiled code if a subclass of Y
> is later loaded). So the reality is that while final might be a useful
> hint to a dumb run-time optimizer that doesn't perform any global
> dependency analysis, its use doesn't actually enable very many
> compile-time optimizations, and is not needed by a smart JIT to perform
> run-time optimizations."
>
> jada jada jada :P. Nice theory, but my reality is that marking methods
> as final *does* speed things up. Of course, we don't want to optimize
> prematurely, but in the case of (for example)
> AbstractLogEnabled.getLogger(), the final really has been proven to help
> in some jvms.
Performance hints is never a real reason to use final. However managing
the growth of an API is. That is the reason that I promote the use
of final. If it gets in the way later, we can remove it. I personally
prefer to lock things down by default, and when there is a reason to
open it we can open it.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
> Leo Simons wrote, On 24/04/2003 14.46:
>
>> marking classes as final often results in more inlining which speeds
>> things up considerably depending on your jvm.
>
> ;-)) Read the article...
"Like many myths about Java performance, the erroneous belief that
declaring classes or methods as final results in better performance is
widely held but rarely examined. The argument goes that declaring a
method or class as final means that the compiler can inline method calls
more aggressively, because it knows that at run time this is definitely
the version of the method that's going to be called. But this is simply
not true. Just because class X is compiled against final class Y doesn't
mean that the same version of class Y will be loaded at run time. So the
compiler cannot inline such cross-class method calls safely, final or
not. Only if a method is private can the compiler inline it freely, and
in that case, the final keyword would be redundant.
On the other hand, the run-time environment and JIT compiler have more
information about what classes are actually loaded, and can make much
better optimization decisions than the compiler can. If the run-time
environment knows that no classes are loaded that extend Y, then it can
safely inline calls to methods of Y, regardless of whether Y is final
(as long as it can invalidate such JIT-compiled code if a subclass of Y
is later loaded). So the reality is that while final might be a useful
hint to a dumb run-time optimizer that doesn't perform any global
dependency analysis, its use doesn't actually enable very many
compile-time optimizations, and is not needed by a smart JIT to perform
run-time optimizations."
jada jada jada :P. Nice theory, but my reality is that marking methods
as final *does* speed things up. Of course, we don't want to optimize
prematurely, but in the case of (for example)
AbstractLogEnabled.getLogger(), the final really has been proven to help
in some jvms.
cheers!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote, On 24/04/2003 14.46:
...
> Additional reasons:
...
> marking classes as final often results in more inlining which speeds
> things up considerably depending on your jvm.
;-)) Read the article...
[1] http://www-106.ibm.com/developerworks/java/library/j-jtp1029.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Leo Simons <le...@apache.org>.
Nicola Ken Barozzi wrote:
> Leo Sutic wrote, On 24/04/2003 14.02:
>
>> xmlutil:
>>
>> The XsltProcessorImpl class went from non-final to final. Any opposition
>> to making it non-final again? I need to override the resolve method.
nope.
> Why is it final in the first place?
> We should always IMHO document why something is final.
we should always document a lot more than we do ;)
> As said here [1]
>
> "
> The most common [reason to sometimes write final classes] is that final
> guarantees that classes intended to be immutable stay immutable.
> ....
> Another reason to use final for classes or methods is to prevent
> linkages between methods from being broken.
> ....
> If you must use final classes or methods, document why
> In any event, when you do choose to declare a method or class final,
> document the reasons why.
> ....
> In many cases, it makes sense to defer the decision to declare a class
> or method as final until later in the development process, when you have
> better information about how your classes interact and might be extended.
> "
Additional reasons:
marking classes as final reduces the value of depending on them for
users. This makes users use the interfaces, which is good. It reduces
likelyhood that changing the implementation breaks users' code. So it is
a good idea to mark a class or method as final until it becomes clear
that the final is hampering someone or someone. At that point it can be
easily removed! Adding 'final' later is often more difficult.
marking classes as final often results in more inlining which speeds
things up considerably depending on your jvm.
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Leo Sutic wrote, On 24/04/2003 14.02:
>
>> xmlutil:
>>
>> The XsltProcessorImpl class went from non-final to final. Any opposition
>> to making it non-final again? I need to override the resolve method.
>
>
> Why is it final in the first place?
> We should always IMHO document why something is final.
>
> As said here [1]
>
> "
> The most common [reason to sometimes write final classes] is that final
> guarantees that classes intended to be immutable stay immutable.
> ...
> Another reason to use final for classes or methods is to prevent
> linkages between methods from being broken.
> ...
> If you must use final classes or methods, document why
> In any event, when you do choose to declare a method or class final,
> document the reasons why.
> ...
> In many cases, it makes sense to defer the decision to declare a class
> or method as final until later in the development process, when you have
> better information about how your classes interact and might be extended.
> "
Funny, I have the opposite view.
All classes/methods/variables/etc. should be final until there is a
documented reason to make it not final. This encourages a more managed
growth, and protects from undocumented usage of some "feature".
Many times, it is much harder to make something final late in a
project's life when it should be than it is to start with it final
and remove that declaration when we need to.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote, On 24/04/2003 14.02:
> xmlutil:
>
> The XsltProcessorImpl class went from non-final to final. Any opposition
> to making it non-final again? I need to override the resolve method.
Why is it final in the first place?
We should always IMHO document why something is final.
As said here [1]
"
The most common [reason to sometimes write final classes] is that final
guarantees that classes intended to be immutable stay immutable.
...
Another reason to use final for classes or methods is to prevent
linkages between methods from being broken.
...
If you must use final classes or methods, document why
In any event, when you do choose to declare a method or class final,
document the reasons why.
...
In many cases, it makes sense to defer the decision to declare a class
or method as final until later in the development process, when you have
better information about how your classes interact and might be extended.
"
[1] http://www-106.ibm.com/developerworks/java/library/j-jtp1029.html
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> xmlutil:
>
> The XsltProcessorImpl class went from non-final to final. Any opposition
> to making it non-final again? I need to override the resolve method.
Go for it.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Phase III Release Candidate 1
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
xmlutil:
The XsltProcessorImpl class went from non-final to final. Any opposition
to making it non-final again? I need to override the resolve method.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Phase III Release Candidate 1
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Just a note: I'm testing the release candidate against Cocoon
> CVS HEAD right now. Should have something done in an hour or so.
OK, it works. One file had to be patched, but that patch has already
made it into Cocoon CVS.
And the Jars.xml file had to be updated, but that can only be done
post-release.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Phase III Release Candidate 1
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Just a note: I'm testing the release candidate against Cocoon CVS HEAD
right now. Should have something done in an hour or so.
> From: news [mailto:news@main.gmane.org] On Behalf Of Leo Simons
> Berin Loritsch wrote:
> > Excalibur Phase III Release Candidate 1 is ready for review.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> Excalibur Phase III Release Candidate 1 is ready for review.
- the compatibility zip has two identical jarfiles. Guess you need to do
ant clean :D
- datasource has no src.zip
- fortress has no src.zip
- fortress docs say
Warning
This package is under development, and the API is not guaranteed to be
the same when it is ready for release.
- fortress docs have wrong download info (getting started docs and index
page and menu)
- store has no actual docs
- xmlutil has no actual docs
otherwise, things look good to me!
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 22:24, Nicola Ken Barozzi wrote:
> >> Now, if
> >>we open up the Excalibur/Sandbox to Cocoon developers, they
> >>are able to support those components here.
> >
> > Why do you need to open it up. There is already Jakarta-Commons that
> > offers much better environment for cross-project collaboration.
>
> Not on Avalon Components. They do not accept them.
yes they do.
--
Cheers,
Peter Donald
*---------------------------------------------*
| "The only way to discover the limits of the |
| possible is to go beyond them into the |
| impossible." -Arthur C. Clarke |
*---------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote, On 23/04/2003 14.26:
> On Wed, 23 Apr 2003 22:00, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>
>>>On Wed, 23 Apr 2003 03:05, Berin Loritsch wrote:
>>>
>>>>Please post all comments so that we can take care of them
>>>>one at a time.
>>>
>>>So Store is being released by Avalon?
>>
>>It's a release candidate. All comments are welcome.
>
> You have ignroed it the last couple of times I have said anything.
And you have ignored all other comments. Talk goes both ways.
> I think
> that components should move to where they are supported and where there is a
> community.
The code should be accessible to the community. That does not
necessarily involve moving code round.
>> Now, if
>>we open up the Excalibur/Sandbox to Cocoon developers, they
>>are able to support those components here.
>
> Why do you need to open it up. There is already Jakarta-Commons that offers
> much better environment for cross-project collaboration.
Not on Avalon Components. They do not accept them.
> Theres no reason
> that I know of why people can not collaborate there.
Now you know.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 22:00, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Wed, 23 Apr 2003 03:05, Berin Loritsch wrote:
> >>Please post all comments so that we can take care of them
> >>one at a time.
> >
> > So Store is being released by Avalon?
>
> It's a release candidate. All comments are welcome.
You have ignroed it the last couple of times I have said anything. I think
that components should move to where they are supported and where there is a
community.
> Now, if
> we open up the Excalibur/Sandbox to Cocoon developers, they
> are able to support those components here.
Why do you need to open it up. There is already Jakarta-Commons that offers
much better environment for cross-project collaboration. Theres no reason
that I know of why people can not collaborate there.
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 23 Apr 2003 03:05, Berin Loritsch wrote:
>
>>Please post all comments so that we can take care of them
>>one at a time.
>
>
> So Store is being released by Avalon?
>
It's a release candidate. All comments are welcome. Now, if
we open up the Excalibur/Sandbox to Cocoon developers, they
are able to support those components here.
I also understand that Store is being used by other projects,
or is being planned to be used by other projects. One example
would be FOP (if memory serves correctly).
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 23 Apr 2003 03:05, Berin Loritsch wrote:
> Please post all comments so that we can take care of them
> one at a time.
So Store is being released by Avalon?
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>You mean naming isn't in there? I thought that was included...
>
>
> It is, in *both*.
Really?
Anyway, there were some changes that either you or the other
Leo made that are in there.
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Phase III Release Candidate 1
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> You mean naming isn't in there? I thought that was included...
It is, in *both*.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Excalibur Phase III Release Candidate 1
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Excalibur-compatibility-1.1 contains two jar files:
>
> excalibur-compatibility-1.0.jar
> excalibur-compatibility-1.1.jar
>
> that have identical file sizes. I think they are identical.
You mean naming isn't in there? I thought that was included...
--
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".
-----Chris Rock
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur Phase III Release Candidate 1
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Excalibur-compatibility-1.1 contains two jar files:
excalibur-compatibility-1.0.jar
excalibur-compatibility-1.1.jar
that have identical file sizes. I think they are identical.
/LS
> From: Berin Loritsch [mailto:bloritsch@apache.org]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org