You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by cz...@apache.org on 2003/08/25 09:41:18 UTC
cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
cziegeler 2003/08/25 00:41:18
Modified: . gump.xml
lib jars.xml
Added: src/blocks/portal/java/org/apache/cocoon/portal/reading
ProxyReader.java
src/blocks/portal/java/org/apache/cocoon/portal/application
PortalApplicationConfig.java
PortalApplicationConfigFactory.java
src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl
ApplicationCopletAdapter.java
CachingURICopletAdapter.java
src/blocks/portal/java/org/apache/cocoon/portal/transformation
LinkTransformer.java NewEventLinkTransformer.java
ProxyTransformer.java
lib/optional jtidy-04aug2000r7-dev.jar
src/blocks/html/lib .cvsignore
Removed: src/blocks/html/lib jtidy-04aug2000r7-dev.jar
Log:
Contributions to the portal from Friedrich Klenner (friedrich.klenner@rzb.at),
Gerald Kahrer (gerald.kahrer@rizit.at) and Gernot Koller (gernot.koller@rizit.at).
Revision Changes Path
1.76 +2 -1 cocoon-2.1/gump.xml
http://cvs.apache.org/viewcvs/cocoon-2.1/gump.xml.diff?r1=1.75&r2=1.76
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/reading/ProxyReader.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/reading/ProxyReader.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/application/PortalApplicationConfig.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/application/PortalApplicationConfig.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/application/PortalApplicationConfigFactory.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/application/PortalApplicationConfigFactory.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl/ApplicationCopletAdapter.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl/ApplicationCopletAdapter.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl/CachingURICopletAdapter.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl/CachingURICopletAdapter.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/LinkTransformer.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/LinkTransformer.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/NewEventLinkTransformer.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/NewEventLinkTransformer.java?rev=1.1
1.1 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/ProxyTransformer.java
http://cvs.apache.org/viewcvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/transformation/ProxyTransformer.java?rev=1.1
1.80 +2 -2 cocoon-2.1/lib/jars.xml
http://cvs.apache.org/viewcvs/cocoon-2.1/lib/jars.xml.diff?r1=1.79&r2=1.80
1.3 +0 -0 cocoon-2.1/lib/optional/jtidy-04aug2000r7-dev.jar
<<Binary file>>
1.3 +0 -0 cocoon-2.1/src/blocks/html/lib/.cvsignore
<<Binary file>>
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Steven Noels dijo:
> OTOH, I'm still seriously concerned with this happening, especially
> since I've seen this before. We (= the Cocoon PMC) have the duty to
> provide legal oversight over the ASF Cocoon codebase. For anything else
> than bugfixes and minor patches, especially for new code, we must ensure
> copyright is correctly transferred, and that the ASF cannot be subject
> of patent infringement lawsuits, and all that. Hence the CLA all
> committers are supposed to sign and fax.
Yep. This is very important! We dont want to be involved in a case of
style SCO-IBM? Sometimes for us (developers), legal issues (licenses, etc)
are not important, but in the world we live we must take care of that. If
someone does not believe this just review the SCO-IBM case. Many companies
out there will be glad to hit ASF and if all ASF effort is destroyed by a
little mistake from us. So Steven advise is right.
As he told maybe the "style" as he addressed this concern was not the best
but it is still valid.
Best Regards,
Antonio Gallardo.
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Vadim Gritsenko wrote, On 26/08/2003 14.01:
> Carsten Ziegeler wrote:
>
>> Vadim Gritsenko wrote:
...
>>> I also would like to see a bit more descriptive commit message. And
>>> may be entry in status.xml too.
>>
>> As long as the portal is alpha this would imho only mess up the
>> status.xml.
>> As soon as it's not alpha anymore, yes, it makes sense to add everything
>> to status.xml.
>
> Then you will have to provide a blurb about portal in status.xml
> *before* next milestone/beta/rc/release, because portal was released
> once as part of 2.1 and users deserve to know what has been changed from
> 2.1 to <insert version number here - most probably 2.1.1>.
As I had outlined before, making blocks live in the same space makes it
impossible to really see the difference from scratchpad ones and real
ones, generating these issues.
Since blocks are not "scratchpad" anymore, and there is no hard
distinction, I want to see the entry in status.xml now too.
>>> I noticed that jtidy has been moved out of html block and into
>>> lib/optional. What will happen if I to remove jtidy from the
>>> lib/optional? Will this break the build?
>>
>> Yepp, you can see it in the gump.xml dependency description.
>
> But that means that we are busting build even more instead of fixing it?
The only real way in which it can be fixed is to do away with including
libs in CVS, and instead getting them from the web and in a local
repository.
I can set up such a system quite quickly if we decide to use it, using
Krysalis Ruper (that does exactly this).
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Roger I Martin PhD <hy...@hypernexinc.com>.
I see jdk1.3.1 jar has an i option but jdk1.2.2 does not. I've never tried
it with 1.3.1; only 1.4.2. If I'm reading the docs correctly only the
primary jars need indexed. Haven't tried it with Cocoon jars yet. I did
find on my own code that the manifest Class-path when defined but the jar
not indexed it would not find the dependent jars according to the
commandline classpath; it needed the indexing. Also found I could put a
patch jar in front of the indexed jar and see it use the patch.
Maintainance of the manifest Class-path could be difficult...
----- Original Message -----
From: "Geoff Howard" <co...@leverageweb.com>
To: <de...@cocoon.apache.org>
Sent: Tuesday, August 26, 2003 10:16 AM
Subject: Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore
jtidy-04aug2000r7-dev.jar
> Roger I Martin PhD wrote:
> > Hi Carsten,
> >
> > Just a thought about something I've run into. When a third party makes
a
> > block or webapp that depends on the same lib but a different version,
can
> > the jar indexing capability of jdk1.4 jar utility be employed to resolve
the
> > issues? It involves placing and maintaining a correct Class-Path: ...
in
> > the jar's manifest and then running jar -i *.jar.
> > http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i
> >
> > Also does anyone know if the indexing really does or would affect the
speed
> > of bringing up a wepapp and say Tomcat?
> >
> > Roger
>
> I have no experience with this but have been interested in it. Would
> this necessarily introduce a dependency on 1.4? (in which case I doubt
> we'd decide to go that way?) Or would it only require jar-ing with 1.4
> and writing backwards compatible classloaders which respect the indexing?
>
> Geoff (reading the link now)
>
>
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Geoff Howard <co...@leverageweb.com>.
Roger I Martin PhD wrote:
> Hi Carsten,
>
> Just a thought about something I've run into. When a third party makes a
> block or webapp that depends on the same lib but a different version, can
> the jar indexing capability of jdk1.4 jar utility be employed to resolve the
> issues? It involves placing and maintaining a correct Class-Path: ... in
> the jar's manifest and then running jar -i *.jar.
> http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i
>
> Also does anyone know if the indexing really does or would affect the speed
> of bringing up a wepapp and say Tomcat?
>
> Roger
I have no experience with this but have been interested in it. Would
this necessarily introduce a dependency on 1.4? (in which case I doubt
we'd decide to go that way?) Or would it only require jar-ing with 1.4
and writing backwards compatible classloaders which respect the indexing?
Geoff (reading the link now)
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Geoff Howard <co...@leverageweb.com>.
Carsten Ziegeler wrote:
> Roger I Martin PhD wrote:
>
>>Just a thought about something I've run into. When a third party makes a
>>block or webapp that depends on the same lib but a different version, can
>>the jar indexing capability of jdk1.4 jar utility be employed to
>>resolve the
>>issues? It involves placing and maintaining a correct Class-Path: ... in
>>the jar's manifest and then running jar -i *.jar.
>>http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i
>>
>
> Perhaps, but we have must be compatible with jdk 1.3 and we have the same
> version of a jar twice :(
>
> But thanks for the pointer anyway!
Actually, I'm looking into it now, but it seems to be identical in 1.4
and 1.3 so it may actually come in useful in general in real blocks. It
won't help us with the current build problem of having two versions when
we only want one. If I understand it right though, it should help us
sort out the thorny classloader issues that could arise when blocks
contain competing versions of the same jars/classes.
Geoff
RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Roger I Martin PhD wrote:
> Just a thought about something I've run into. When a third party makes a
> block or webapp that depends on the same lib but a different version, can
> the jar indexing capability of jdk1.4 jar utility be employed to
> resolve the
> issues? It involves placing and maintaining a correct Class-Path: ... in
> the jar's manifest and then running jar -i *.jar.
> http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i
>
Perhaps, but we have must be compatible with jdk 1.3 and we have the same
version of a jar twice :(
But thanks for the pointer anyway!
Carsten
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Roger I Martin PhD <hy...@hypernexinc.com>.
Hi Carsten,
Just a thought about something I've run into. When a third party makes a
block or webapp that depends on the same lib but a different version, can
the jar indexing capability of jdk1.4 jar utility be employed to resolve the
issues? It involves placing and maintaining a correct Class-Path: ... in
the jar's manifest and then running jar -i *.jar.
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/jar.html#i
Also does anyone know if the indexing really does or would affect the speed
of bringing up a wepapp and say Tomcat?
Roger
----- Original Message -----
From: "Carsten Ziegeler" <cz...@s-und-n.de>
To: <de...@cocoon.apache.org>
Sent: Tuesday, August 26, 2003 8:10 AM
Subject: RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore
jtidy-04aug2000r7-dev.jar
> Vadim Gritsenko wrote:
> >
> > >>I noticed that jtidy has been moved out of html block and into
> > >>lib/optional. What will happen if I to remove jtidy from the
> > >>lib/optional? Will this break the build?
> > >>
> > >>
> > >Yepp, you can see it in the gump.xml dependency description.
> > >
> >
> > But that means that we are busting build even more instead of fixing it?
> >
> Vadim, this is a point a stressed several times in the last months, but
> noone was really interested. Yes, we have a problem with libs, e.g. we
> have the same lib (velocity) at different places!
>
> We are not "busting the build". Currently, if two blocks require the same
> lib, it has to be in lib/optional. When the blocks directory structure
> was built, someone moved the libs into the blocks directories making it
> impossible to use the same jar in several projects. Now, each time
> a second block needs the jar we have to move it :(
> As I pointed out several times, this can be solved with an updated build
> system where we have all jars in lib/optional. These jars are not copied
> automatically to WEB-INF/lib. They are only copied if a included block
> depends on them.
>
> Carsten
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>>>I noticed that jtidy has been moved out of html block and into
>>>>lib/optional. What will happen if I to remove jtidy from the
>>>>lib/optional? Will this break the build?
>>>>
>>>>
>>>>
>>>>
>>>Yepp, you can see it in the gump.xml dependency description.
>>>
>>>
>>>
>>But that means that we are busting build even more instead of fixing it?
>>
...
>As I pointed out several times, this can be solved with an updated build
>system where we have all jars in lib/optional. These jars are not copied
>automatically to WEB-INF/lib. They are only copied if a included block
>depends on them.
>
Will it be a problem with "real blocks" if all the jars are in the
WEB-INF? AFAIU, "real blocks" will have a per-block classloader, so libs
will go into the BLOCK-INF/lib, and won't be seen outside of the block.
How we will solve this issue with real blocks then?
Vadim
RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> >>I noticed that jtidy has been moved out of html block and into
> >>lib/optional. What will happen if I to remove jtidy from the
> >>lib/optional? Will this break the build?
> >>
> >>
> >Yepp, you can see it in the gump.xml dependency description.
> >
>
> But that means that we are busting build even more instead of fixing it?
>
Vadim, this is a point a stressed several times in the last months, but
noone was really interested. Yes, we have a problem with libs, e.g. we
have the same lib (velocity) at different places!
We are not "busting the build". Currently, if two blocks require the same
lib, it has to be in lib/optional. When the blocks directory structure
was built, someone moved the libs into the blocks directories making it
impossible to use the same jar in several projects. Now, each time
a second block needs the jar we have to move it :(
As I pointed out several times, this can be solved with an updated build
system where we have all jars in lib/optional. These jars are not copied
automatically to WEB-INF/lib. They are only copied if a included block
depends on them.
Carsten
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Vadim Gritsenko <va...@verizon.net>.
Carsten Ziegeler wrote:
>Vadim Gritsenko wrote:
>
>
>>Steven Noels wrote:
>>
>>
>>
>>>Of course, I'm very confident that Carsten has done this with the best
>>>possible intentions, but "Contributions to the portal" is hardly an
>>>intuitive commit message, and a quick search for the three people
>>>involved didn't bring up much prior discussion on the lists.
>>>
>>>
>>I also would like to see a bit more descriptive commit message. And may
>>be entry in status.xml too.
>>
>>
>>
>As long as the portal is alpha this would imho only mess up the status.xml.
>As soon as it's not alpha anymore, yes, it makes sense to add everything
>to status.xml.
>
Then you will have to provide a blurb about portal in status.xml
*before* next milestone/beta/rc/release, because portal was released
once as part of 2.1 and users deserve to know what has been changed from
2.1 to <insert version number here - most probably 2.1.1>.
>>I noticed that jtidy has been moved out of html block and into
>>lib/optional. What will happen if I to remove jtidy from the
>>lib/optional? Will this break the build?
>>
>>
>Yepp, you can see it in the gump.xml dependency description.
>
But that means that we are busting build even more instead of fixing it?
Vadim
RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Vadim Gritsenko wrote:
>
> Steven Noels wrote:
>
> > Of course, I'm very confident that Carsten has done this with the best
> > possible intentions, but "Contributions to the portal" is hardly an
> > intuitive commit message, and a quick search for the three people
> > involved didn't bring up much prior discussion on the lists.
>
>
> I also would like to see a bit more descriptive commit message. And may
> be entry in status.xml too.
>
As long as the portal is alpha this would imho only mess up the status.xml.
As soon as it's not alpha anymore, yes, it makes sense to add everything
to status.xml.
> I noticed that jtidy has been moved out of html block and into
> lib/optional. What will happen if I to remove jtidy from the
> lib/optional? Will this break the build?
Yepp, you can see it in the gump.xml dependency description.
Carsten
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Vadim Gritsenko <va...@verizon.net>.
Steven Noels wrote:
> Of course, I'm very confident that Carsten has done this with the best
> possible intentions, but "Contributions to the portal" is hardly an
> intuitive commit message, and a quick search for the three people
> involved didn't bring up much prior discussion on the lists.
I also would like to see a bit more descriptive commit message. And may
be entry in status.xml too.
I noticed that jtidy has been moved out of html block and into
lib/optional. What will happen if I to remove jtidy from the
lib/optional? Will this break the build?
Vadim
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Gianugo Rabellino <gi...@apache.org>.
Carsten Ziegeler wrote:
> Now, the usual way of contributing would be submitting a patch into
> bugzilla and someone of the committers would look at the patch and
> (perhaps) apply it, right?
> So, if instead of entering this into bugzilla, the patch is send
> directly to a committer looking at the patch and then (perhaps) applying
> it, where is the difference?
I would say that there are at least three differences:
1. it's more "politically correct" to the community: in practice there
is little or no difference, but at a very least there is a delta of time
where it's possible to discuss the patch;
2. <lawyer-hat-on>if a user uploads a patch to Bugzilla, from a legal
standpoint it's more clear that it's been *him* willing to donate the
code to the ASF. As of now it's just you acting both as a proxy and as a
witness for him</lawyer-hat-on>;
3. the contributing user gets more recognition and, since recognition is
our only way to pay him back, I think it's better for both us and them
to go through Bugzilla.
No one of the above is a compelling reason: there are cases when it just
makes sense to commit right away. I'd just think of it as a "best practice".
This is no different from what I did with Guido. I think it's pretty
clear to everyone here that I and Guido have many reason to work offlist
being both working for Orixo companies, but after the initial joint
WebDAV contribution, when he sent me a first patch I asked him to go
through Bugzilla so that the community was at least aware of what he was
doing.
This, however, doesn't change the fact that me too:
> I'm really happy that people are contributing to
> Cocoon, especially to the Cocoon portal.
All contributions are most welcome. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Now blogging at: http://blogs.cocoondev.org/gianugo/)
RE: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
>
>
> First, let's make this clear: it's good that people contribute to the
> new portal framework. So thanks, Friedrich, Gerald and Gernot, for
> donating this back to the community. Also, I fully trust Carsten in
> reviewing the code before committing.
>
> OTOH, I'm still seriously concerned with this happening, especially
> since I've seen this before. We (= the Cocoon PMC) have the duty to
> provide legal oversight over the ASF Cocoon codebase. For anything else
> than bugfixes and minor patches, especially for new code, we must ensure
> copyright is correctly transferred, and that the ASF cannot be subject
> of patent infringement lawsuits, and all that. Hence the CLA all
> committers are supposed to sign and fax.
>
> Of course, I'm very confident that Carsten has done this with the best
> possible intentions, but "Contributions to the portal" is hardly an
> intuitive commit message, and a quick search for the three people
> involved didn't bring up much prior discussion on the lists. If people
> show up off-list with anything but trivial contributions, they should be
> discussed or at the very least mentioned on the dev list before being
> committed.
>
> I know I'm not making myself popular here and now, but given the
> increased number of commercial entities involved with Cocoon and its
> community, we're better safe than sorry.
>
> Sorry again for the tone.
>
No problem.
Now, the usual way of contributing would be submitting a patch into
bugzilla and someone of the committers would look at the patch and
(perhaps) apply it, right?
So, if instead of entering this into bugzilla, the patch is send
directly to a committer looking at the patch and then (perhaps) applying
it, where is the difference?
All files checked in have the appropriate licence, have the correct
author tags etc and I'm really happy that people are contributing to
Cocoon, especially to the Cocoon portal.
Carsten
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Steven Noels <st...@outerthought.org>.
Joerg Heinicke wrote:
> Ui, Steven, hard words. I can understand your irritation, it's not the
> way I would like to see such stuff goes. But offending somebody in such
> an aggressive way on the public list ??
Well, it's the classical case of not paying enough attention before
pressing the send button. I'm really good at this. :-|
So apologies for the tone, it was intended for the PMC list, and I was
composing a follow-up message already. But I guess I'd better continue
the discussion in public:
First, let's make this clear: it's good that people contribute to the
new portal framework. So thanks, Friedrich, Gerald and Gernot, for
donating this back to the community. Also, I fully trust Carsten in
reviewing the code before committing.
OTOH, I'm still seriously concerned with this happening, especially
since I've seen this before. We (= the Cocoon PMC) have the duty to
provide legal oversight over the ASF Cocoon codebase. For anything else
than bugfixes and minor patches, especially for new code, we must ensure
copyright is correctly transferred, and that the ASF cannot be subject
of patent infringement lawsuits, and all that. Hence the CLA all
committers are supposed to sign and fax.
Of course, I'm very confident that Carsten has done this with the best
possible intentions, but "Contributions to the portal" is hardly an
intuitive commit message, and a quick search for the three people
involved didn't bring up much prior discussion on the lists. If people
show up off-list with anything but trivial contributions, they should be
discussed or at the very least mentioned on the dev list before being
committed.
I know I'm not making myself popular here and now, but given the
increased number of commercial entities involved with Cocoon and its
community, we're better safe than sorry.
Sorry again for the tone.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Joerg Heinicke <jh...@virbus.de>.
Steven Noels wrote:
> cziegeler@apache.org wrote:
>
>> Contributions to the portal from Friedrich Klenner
>> (friedrich.klenner@rzb.at),
>> Gerald Kahrer (gerald.kahrer@rizit.at) and Gernot Koller
>> (gernot.koller@rizit.at).
>
> I'm getting increasingly annoyed that, to the best of my knowledge,
> these contributions have been made off-list. ASF CVS is _not_ a
> corporate dumping ground.
>
> </Steven>
Ui, Steven, hard words. I can understand your irritation, it's not the
way I would like to see such stuff goes. But offending somebody in such
an aggressive way on the public list ??
Joerg
Re: cvs commit: cocoon-2.1/src/blocks/html/lib .cvsignore jtidy-04aug2000r7-dev.jar
Posted by Steven Noels <st...@outerthought.org>.
cziegeler@apache.org wrote:
> cziegeler 2003/08/25 00:41:18
>
> Modified: . gump.xml
> lib jars.xml
> Added: src/blocks/portal/java/org/apache/cocoon/portal/reading
> ProxyReader.java
> src/blocks/portal/java/org/apache/cocoon/portal/application
> PortalApplicationConfig.java
> PortalApplicationConfigFactory.java
> src/blocks/portal/java/org/apache/cocoon/portal/coplet/adapter/impl
> ApplicationCopletAdapter.java
> CachingURICopletAdapter.java
> src/blocks/portal/java/org/apache/cocoon/portal/transformation
> LinkTransformer.java NewEventLinkTransformer.java
> ProxyTransformer.java
> lib/optional jtidy-04aug2000r7-dev.jar
> src/blocks/html/lib .cvsignore
> Removed: src/blocks/html/lib jtidy-04aug2000r7-dev.jar
> Log:
> Contributions to the portal from Friedrich Klenner (friedrich.klenner@rzb.at),
> Gerald Kahrer (gerald.kahrer@rizit.at) and Gernot Koller (gernot.koller@rizit.at).
I'm getting increasingly annoyed that, to the best of my knowledge,
these contributions have been made off-list. ASF CVS is _not_ a
corporate dumping ground.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org