niclas 2004/02/19 21:46:22
Modified:ide/org.apache.avalon.ide.eclipse.repository .classpath
ide/org.apache.avalon.ide.repository .classpath
ide/org.apache.avalon.ide.repository.testrepo .classpath
Log:
CVS exclusion filter.
Revision ChangesPat
Message:
A new issue has been created in JIRA.
-
View the issue:
http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=EXLBR-1
Here is an overview of the issue:
-
niclas 2004/02/19 21:24:51
Added:
ide/org.apache.avalon.ide.repository/src/java/org/apache/avalon/ide/repository
Compliance.java InvalidSchemeException.java
RepositoryAgent.java
RepositoryAgentCreationException.j
niclas 2004/02/19 19:57:10
Modified:merlin INSTALL.TXT
Log:
Something odd with this file. Even though I have not even opened it, it keeps saying
that it is modified on my system. Which means that it must be the case on someone
else's computer as well, and I intend to find out wh
On Thursday 19 February 2004 15:46, Carsten Ziegeler wrote:
> excalibur-component
> excalibur-sourceresolve
> excalibur-store
> excalibur-xmlutil
> fortress-container
> fortress-tools
> excalibur-logger
The more I see this kind of requests, the more I think that either Avalon
provides the infrast
On Friday 20 February 2004 05:56, Leo Sutic wrote:
> > From: Farr, Aaron [mailto:[EMAIL PROTECTED]
> >
> > - A TCK or similar formal spec would be helpful for just
> > getting our own containers/components working together.
>
> Yes, but no one is willing to write it or maintain it.
>
> I agree that
> From: Farr, Aaron [mailto:[EMAIL PROTECTED]
>
> - A TCK or similar formal spec would be helpful for just
> getting our own containers/components working together.
Yes, but no one is willing to write it or maintain it.
I agree that it would be helpful if a TCK materialized from
nothingness a
Yet another good RT, Leo. I'm going to go home and let this one sink in. A
couple of initial comments:
- A TCK or similar formal spec would be helpful for just getting our own
containers/components working together.
- /LS has a good point about hitting a moving target. There are a couple of
wa
Date: 2004-02-19T13:35:11
Editor: 81.225.9.144 <>
Wiki: Apache Avalon Wiki
Page: AvalonReleaseManagerHowto
URL: http://wiki.apache.org/avalon/AvalonReleaseManagerHowto
FIxed some code blocks.
Change Log:
--
Sylvain Wallez wrote:
Although having released versions of Avalon components is obviously the
better solution, is there anything that prevents Cocoon committers that
are also Avalon committers to tag some of these components?
no.
Is a vote needed to place a tag on the CVS?
no.
Any committer can
Carsten Ziegeler wrote:
Avalon has a lot of different subprojects where some of them are more
"active" then others. I think a general policy however for all projects
should be "release early, release often".
So I kindly ask you for new release for the following subprojects:
excalibur-component
Leo Sutic wrote:
>>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>>
>>that's just about exactly what I did, and it got me into a
>>trademark debate.
>
> With whom?
The Avalon PMC.
I asked the PMC to grant permission for some specific
endorsement/promotional usage according to the A
-Mensagem original-
De: Leo Simons [mailto:[EMAIL PROTECTED]
> this is not intended as a vote on a release, but on a part of the
> release process. I totally agree that things should build, and build
> well, etc etc.
I agree on pragmatism, but I also agree with Steve that have been a l
Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
These guys are not ready for a release - sorry to say that but we still need
to fix its build scripts - with or without maven.
this is not intended as a vote on a release, but on a part of the
release process. I totally agree that things sho
With whom?
/LS
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>
> that's just about exactly what I did, and it got me into a
> trademark debate.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
Leo Sutic wrote:
I suggest you just say "Supports Avalon Components (Framework 4.1.x)"
on your website, and be done with it. Just as I can say "My program
runs on Linux" without getting into a trademark debate with Mr.
Torvalds, because, well, *it does*.
that's just about exactly what I did, and
Stephen McConnell wrote:
The subject of this message starts with [PMC:VOTE], however, I don't see
anything to vote on.
"Proposal: if working and thoroughly tested (with verifiable results of
course) versions of [this specific package list] are produced, lets
agree to release them even if their d
Leo:
The subject of this message starts with [PMC:VOTE], however, I don't see
anything to vote on. I don't see a release manager, a release plan, or
even a release candidate. However, I did see a generic statement
suggesting Avalon adopt the principal of releasing undocumented code.
Is that
> I suggest you just say "Supports Avalon Components (Framework 4.1.x)"
> on your website, and be done with it. Just as I can say "My program
> runs on Linux" without getting into a trademark debate with Mr.
> Torvalds, because, well, *it does*. It's just a feature list.
Agreed. But anyway even
= IMHO =
It is pointless to define a TCK given that the architecture is still
very much evolving.
What about metadata, lifecycle extensions, interceptors, etc.?
I suggest you just say "Supports Avalon Components (Framework 4.1.x)"
on your website, and be done with it. Just as I can say "My prog
Carsten Ziegeler wrote:
And this is exactly what I don't want to do again. The last time
I tried it (and you tried it as well) it all failed because of a
veto for the release as someone said "There are no docs, I don't
know what it's all about and I don't like it". Or something similar.
And I don't
On Friday 20 February 2004 00:03, Leo Simons wrote:
> Proposal: if working and thoroughly tested (with verifiable results of
> course) versions of the packages mentioned above are produced, lets
> agree to release them even if their documentation may not be exactly
> what we would like it to be.
+
Hi gang,
= preface =
[RT] are Ramdom Thoughts. They are tradition in the Avalon community.
RTs are basically long and thought-provocing mails with new project
propositions, that are discussed and scrutinized at length. One
distinguishing characteristic about RTs is the complete and utter lack
o
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>
> Proposal: if working and thoroughly tested (with verifiable results of
> course) versions of the packages mentioned above are produced, lets
> agree to release them even if their documentation may not
-Mensagem original-
De: Leo Simons [mailto:[EMAIL PROTECTED]
> fortress-container
> fortress-tools
These guys are not ready for a release - sorry to say that but we still need
to fix its build scripts - with or without maven.
I'm a big +1 to others.
--
hammett
---
I'll review this tomorrow.
-Mensagem original-
De: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
From: Hamilton Verissimo de Oliveira (Engenharia - SPO)
>
> > b) I can't build the releases as the build process is not
> working for
> > me
>
> Which one? A build in the root of Avalon CVS
Hi gang!
Cocoon (arguably one of the biggest and most important "clients" for
avalon) is using CVS drops of these projects:
excalibur-component
excalibur-sourceresolve
excalibur-store
excalibur-xmlutil
fortress-container
fortress-tools
excalibur-logger
This is an undesirable situation.
Previous
Carsten Ziegeler wrote:
Now, I would prefer, if first a vote would be started about the
release and then the process. Otherwise the work will be (again)
for the trash can.
good point.
--
cheers,
- Leo Simons
---
Weblog
From: Hamilton Verissimo de Oliveira (Engenharia - SPO)
>
> > b) I can't build the releases as the build process is not
> working for
> > me
>
> Which one? A build in the root of Avalon CVS should work for
> us all :-\
>
Perhaps I'm using the wrong commands :) How do I build the
excalibur re
Leo Simons wrote:
>
> all we need is a release manager, and some people willing to
> do some work.
>
> http://wiki.apache.org/avalon/AvalonReleaseManagerHowto
> http://wiki.apache.org/avalon/AvalonDistributionLayout
>
> (latter may be somewhat out of date, I'm not sure)
>
> I got like 60% of
Carsten Ziegeler wrote:
new release for the following subprojects:
excalibur-component
excalibur-sourceresolve
excalibur-store
excalibur-xmlutil
fortress-container
fortress-tools
excalibur-logger
I would release them but two things are preventing me:
a) a pmc vote is required (right?)
b) I can't b
> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
>
> I would release them but two things are preventing me:
> a) a pmc vote is required (right?)
> b) I can't build the releases as the build process is not working for me
>
> So, what do you think?
+1 for getting t
Thanks Leo that's a good idea.
> -Original Message-
> From: Leo Sutic [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 19, 2004 3:28 AM
> To: 'Avalon Developers List'
> Subject: RE: [OT] Bug in NIO
>
> Alex,
>
> what you can do is wrap the buffer in an object that
> implements Object
I don't see any problem releasing:
excalibur-component
excalibur-sourceresolve
excalibur-store
excalibur-xmlutil
excalibur-logger
AFAIK we can call for a vote for them without any problem
On the other hand fortress and fortress-tools needs a simple maven build
that works. We need to remove the
mcconnell2004/02/19 04:25:29
Modified:logging/logkit/impl maven.xml
logging/logkit/impl/src/java/org/apache/avalon/logging/logkit
DefaultLoggingCriteria.java
repository/impl/src/java/org/apache/avalon/repository/impl
cziegeler2004/02/19 01:24:18
Modified:component/examples/instrument-manager ant.properties.sample
default.properties project.xml maven.xml build.xml
project.properties
component/src/java/org/apache/avalon/excalibur/component
While updating the excalibur logger package to the new license I found out
that several java files where there not only twice but three or four times!
And some of them with different versions!
So I deleted all duplicates and tried to keep the most recent version. I
don't know if I did it right, so
cziegeler2004/02/19 01:12:08
Modified:logger/logkit/src/java/org/apache/avalon/excalibur/logger
Facade.java LogTargetFactory.java
LogTargetFactoryManager.java
DefaultLoggerManager.java LogTargetManager.java
mcconnell2004/02/19 00:58:45
Added: merlin/facilities/db README.TXT maven.xml merlin.properties
project.properties project.xml
merlin/facilities/db/api maven.xml project.xml
merlin/facilities/db/api/src/java/org/apache/avalon/db
mcconnell2004/02/19 00:58:05
Modified:logging/logkit/test/src/test/org/apache/avalon/logging/logkit/test
LoggingManagerHelper.java
logging maven.xml
logging/site/xdocs/impl/logkit navigation.xml
logging/site/xdocs/impl
cziegeler2004/02/19 00:36:17
Modified:sourceresolve/src/java/org/apache/excalibur/source
ModifiableTraversableSource.java
SourceValidity.java TraversableSource.java
Source.java SourceResolver.java SourceUtil.java
cziegeler2004/02/19 00:28:34
Modified:xmlutil/src/test/org/apache/excalibur/xml/xpath/test
Saxon6ExtTestCase.xtest XPathTestCase.java
Saxon6TestCase.java Saxon6ExtTestCase.java
XPathTestCase.xtest JaxenTestCase.java
Alex,
what you can do is wrap the buffer in an object that
implements Object.equals by == with the wrapped Buffer,
and hashCode via System.identityHashCode(wrapped Buffer).
/LS
> From: Alex Karasulu [mailto:[EMAIL PROTECTED]
---
43 matches
Mail list logo
