You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2003/01/15 14:32:54 UTC
[VOTE] Inclusion of SAP R/3 components
Team.
The long pending SAP R/3 patches [1] by Michael Gerzabek and Reinhard
Poetz now carry the standard ASF licence plate, mock classes exist, I
have reviewed the code and am happy with it. All issues have been
solved by Michael and it was great working with him on it. I have not
tested the components since I don't have a SAP installation to test
against. Still, I'm confident in this patch.
This has already been discussed [2] and [3]. Especially the long term
perspective really _is_ an issue. However, I believe that these
components will attract users and hopefully, the components can be
maintained that way.
Before actually adding the code to the 2.1 repository, I'd like to
have a final voting on it.
Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
R/3 connectivity components from patch [1] ?
Here's my +1
Chris.
[1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9075
[2] http://marc.theaimsgroup.com/?t=102636870300001&r=1&w=2
[3] http://marc.theaimsgroup.com/?t=104014543000004&r=1&w=2
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Stefano Mazzocchi <st...@apache.org>.
Torsten Curdt wrote:
>> This has already been discussed [2] and [3]. Especially the long term
>> perspective really _is_ an issue. However, I believe that these
>> components will attract users and hopefully, the components can be
>> maintained that way.
>
>
> I am pretty sure this will work out in the end...
>
>> Before actually adding the code to the 2.1 repository, I'd like to
>> have a final voting on it.
>>
>> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
>> R/3 connectivity components from patch [1] ?
>>
>> Here's my +1
>
>
> ...so here is my +1
+1
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Torsten Curdt <tc...@dff.st>.
> This has already been discussed [2] and [3]. Especially the long term
> perspective really _is_ an issue. However, I believe that these
> components will attract users and hopefully, the components can be
> maintained that way.
I am pretty sure this will work out in the end...
> Before actually adding the code to the 2.1 repository, I'd like to
> have a final voting on it.
>
> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
> R/3 connectivity components from patch [1] ?
>
> Here's my +1
...so here is my +1
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Gianugo Rabellino <gi...@apache.org>.
Christian Haul wrote:
>
> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
> R/3 connectivity components from patch [1] ?
+1.
--
Gianugo Rabellino
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Christian Haul wrote:
> Team.
[...]
> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
> R/3 connectivity components from patch [1] ?
[...]
> [1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9075
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 15.Jan.2003 -- 02:58 PM, Steven Noels wrote:
> Christian Haul wrote:
>
> >Before actually adding the code to the 2.1 repository, I'd like to
> >have a final voting on it.
>
> - do they need some SAP-jars in the classpath upon compilation time?
Michael has created Mock objects that are used instead. So no, no SAP
jars are needed at compile time, only at run time.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
[...]
> What I said is that code becomes zombie if it's not included in the
> distro of the source base that _contains_ the code.
>
> Visibility is another problem, and this is chicken and egg : cocoon-apps
> will be visible if it contains substantial material, and substantial
> material will come in only if cocoon-apps is visible... (same applies to
> cocoondev.org)
Cocoon-apps has been created in overlap with cocoon-dev, and to get
stuff from Andy, CocoBlog and Wyona. Andy didn't finish it, CocoBlog is
lingering between that and Cocoondev and Wyona... well, it will probably
be a project itself.
So cocoon-apps is empty now and I don't see it become less-empty soon.
Overmore there is cocoondev which is already active.
Yes, it would be nice not to need to keep all blocks in the Cocoon CVS
repo, but move them *again*? And which? When we'll move to Subversion,
dir moves will be possible, and then we'll be able to make these
decisions without technological problems.
> Also, we have to consider the size of these components : the Cocoon core
> provides so highlevel and powerful abstractions that adding a
> substantial amount of functionnality in a very specific area requires
> only a few classes. Do 10 classes require a separate project/module ?
> But they clearly don't belong to the core. So what ?
If it's not in the core it's a block, even if only one class.
> I'm puzzled... (hence the -0.5)
>
> Sylvain
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Steven Noels <st...@outerthought.org>.
Christian Haul wrote:
> So your suggestion is to move highly specific blocks from the core cvs
> module to the apps cvs module? I fear that it will be very difficult
> to decide which blocks are special enough to be moved. Can't we stick
> with blocks for the moment?
I will give that classification a go in the Wiki.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 16.Jan.2003 -- 11:14 AM, Sylvain Wallez wrote:
> Visibility is another problem, and this is chicken and egg : cocoon-apps
> will be visible if it contains substantial material, and substantial
> material will come in only if cocoon-apps is visible... (same applies to
> cocoondev.org)
Agreed. Only that this is not an application but a connectivity
component IMO. If it were, I'd be convinced already ;-)
> Also, we have to consider the size of these components : the Cocoon core
> provides so highlevel and powerful abstractions that adding a
> substantial amount of functionnality in a very specific area requires
> only a few classes. Do 10 classes require a separate project/module ?
Sorry, this was not intended. I only wanted to say that we are arguing
over only a few classes but you are right, very specific classes,
indeed.
> But they clearly don't belong to the core. So what ?
The original suggestion is to make it a block.
So your suggestion is to move highly specific blocks from the core cvs
module to the apps cvs module? I fear that it will be very difficult
to decide which blocks are special enough to be moved. Can't we stick
with blocks for the moment?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Christian Haul wrote:
>
>> On 16.Jan.2003 -- 10:03 AM, Sylvain Wallez wrote:
>>
>>
>>> Steven Noels wrote:
>>>
>>>
>>>> Other worry: this means adding yet another
>>>> mega-functional-component to Cocoon, and I have have been talking
>>>> offlist about my worries in this direction.
>>>>
>>>> We better start using the -apps module then, I guess (and some
>>>> other components might as well migrate there, too).
>>>>
>>>
>>> I share Steven's feelings (I'm one of the "offlist") : we voted a
>>> cocoon-apps module to host Cocoon-related developments that don't
>>> belong to the core. And this ultra-specific component typically
>>> falls in this category.
>>>
>>> I don't discuss its quality nor its usefullness (SAP is used in
>>> large companies and this could be a "troyan horse" to bring Cocoon
>>> inside), but adding it to the main CVS repository, even in a block,
>>> would increase the bloat.
>>
I tend to agree with Sylvain (+1 on addition to CVS, -0 or so on
addition to main Cocoon CVS).
>> The SAP R/3 connectivity consists of 4 interfaces, 5 implementing
>> classes and a transformer:
>
...
>> It is not an application per se but a connectivity
>> component.
>
I think it's not a problem and, given enough interested people, it can
always grow to at least size of demo app, if not full-featured app.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>On 16.Jan.2003 -- 10:03 AM, Sylvain Wallez wrote:
>
>
>>Steven Noels wrote:
>>
>>
>>>Other worry: this means adding yet another mega-functional-component
>>>to Cocoon, and I have have been talking offlist about my worries in
>>>this direction.
>>>
>>>We better start using the -apps module then, I guess (and some other
>>>components might as well migrate there, too).
>>>
>>>
>>I share Steven's feelings (I'm one of the "offlist") : we voted a
>>cocoon-apps module to host Cocoon-related developments that don't belong
>>to the core. And this ultra-specific component typically falls in this
>>category.
>>
>>I don't discuss its quality nor its usefullness (SAP is used in large
>>companies and this could be a "troyan horse" to bring Cocoon inside),
>>but adding it to the main CVS repository, even in a block, would
>>increase the bloat.
>>
>>
>
>The SAP R/3 connectivity consists of 4 interfaces, 5 implementing
>classes and a transformer:
>
>java/org/apache/cocoon/components/web3/Web3.java
>java/org/apache/cocoon/components/web3/Web3Client.java
>java/org/apache/cocoon/components/web3/Web3DataSource.java
>java/org/apache/cocoon/components/web3/Web3Streamer.java
>
>java/org/apache/cocoon/components/web3/impl/DefaultWeb3StreamerImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3ClientImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3DataSourceImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3DataSourceSelectorImpl.java
>java/org/apache/cocoon/components/web3/impl/Web3Properties.java
>
>java/org/apache/cocoon/transformation/Web3RfcTransformer.java
>
>It is not an application per se but a connectivity
>component. Everything is already nicely organized to fit into a
>block.
>
>For me, the apps module appeared to be more a repository for stuff
>like wyona e.g. complete apps.
>
>>Please also correlate these thoughts with the "zombie code" discussion.
>>
>>
>Sylvain, wasn't it you that said if the component were present by
>default, it would have generated patches from the user base? Wouldn't
>that suggest to have it in a highly visible place like core cvs
>module and hence the main distro?
>
What I said is that code becomes zombie if it's not included in the
distro of the source base that _contains_ the code.
Visibility is another problem, and this is chicken and egg : cocoon-apps
will be visible if it contains substantial material, and substantial
material will come in only if cocoon-apps is visible... (same applies to
cocoondev.org)
Also, we have to consider the size of these components : the Cocoon core
provides so highlevel and powerful abstractions that adding a
substantial amount of functionnality in a very specific area requires
only a few classes. Do 10 classes require a separate project/module ?
But they clearly don't belong to the core. So what ?
I'm puzzled... (hence the -0.5)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 16.Jan.2003 -- 10:03 AM, Sylvain Wallez wrote:
> Steven Noels wrote:
> >
> >Other worry: this means adding yet another mega-functional-component
> >to Cocoon, and I have have been talking offlist about my worries in
> >this direction.
> >
> >We better start using the -apps module then, I guess (and some other
> >components might as well migrate there, too).
>
> I share Steven's feelings (I'm one of the "offlist") : we voted a
> cocoon-apps module to host Cocoon-related developments that don't belong
> to the core. And this ultra-specific component typically falls in this
> category.
>
> I don't discuss its quality nor its usefullness (SAP is used in large
> companies and this could be a "troyan horse" to bring Cocoon inside),
> but adding it to the main CVS repository, even in a block, would
> increase the bloat.
The SAP R/3 connectivity consists of 4 interfaces, 5 implementing
classes and a transformer:
java/org/apache/cocoon/components/web3/Web3.java
java/org/apache/cocoon/components/web3/Web3Client.java
java/org/apache/cocoon/components/web3/Web3DataSource.java
java/org/apache/cocoon/components/web3/Web3Streamer.java
java/org/apache/cocoon/components/web3/impl/DefaultWeb3StreamerImpl.java
java/org/apache/cocoon/components/web3/impl/Web3ClientImpl.java
java/org/apache/cocoon/components/web3/impl/Web3DataSourceImpl.java
java/org/apache/cocoon/components/web3/impl/Web3DataSourceSelectorImpl.java
java/org/apache/cocoon/components/web3/impl/Web3Properties.java
java/org/apache/cocoon/transformation/Web3RfcTransformer.java
It is not an application per se but a connectivity
component. Everything is already nicely organized to fit into a
block.
For me, the apps module appeared to be more a repository for stuff
like wyona e.g. complete apps.
> Please also correlate these thoughts with the "zombie code" discussion.
Sylvain, wasn't it you that said if the component were present by
default, it would have generated patches from the user base? Wouldn't
that suggest to have it in a highly visible place like core cvs
module and hence the main distro?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Thorsten Scherler <th...@wyona.org>.
I think including this connectivity to cocoon will be really like the
troyan horse!
...but it will help me to establish my cocoon app in my company.
...facing the challenge to introduce MySAP CRM within our company we
found out that consultants NOT always tell you the trues about
connectivity of SAP.
If I now have a way to actually get my data from SAP, I have a BIG
problem less.
I am not a dev, but I would give it
+1
King regards
Sylvain Wallez wrote:
<snip/>
> I don't discuss its quality nor its usefullness (SAP is used in large
> companies and this could be a "troyan horse" to bring Cocoon inside),
> but adding it to the main CVS repository, even in a block, would
> increase the bloat.
>
> Sylvain
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> Christian Haul wrote:
>
>> Before actually adding the code to the 2.1 repository, I'd like
>> tohave a final voting on it.
>
<snip/>
> If license issues do not allow these components to be added to ASF
> CVS, we could look and see whether they could be hosted at
> cocoondev.org (since yes, they would be a valuable addition to Cocoon).
>
> Other worry: this means adding yet another mega-functional-component
> to Cocoon, and I have have been talking offlist about my worries in
> this direction.
>
> We better start using the -apps module then, I guess (and some other
> components might as well migrate there, too).
I share Steven's feelings (I'm one of the "offlist") : we voted a
cocoon-apps module to host Cocoon-related developments that don't belong
to the core. And this ultra-specific component typically falls in this
category.
I don't discuss its quality nor its usefullness (SAP is used in large
companies and this could be a "troyan horse" to bring Cocoon inside),
but adding it to the main CVS repository, even in a block, would
increase the bloat.
So +1 for this patch, but -0.5 for the main CVS repo (not a "-1" because
I don't want to stop its publication).
Please also correlate these thoughts with the "zombie code" discussion.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
> - if all that is the case and the license only allows binary
> distribution, we can implement mock classes
>
> If all these are incorrect assumptions, pardon my ignorance.
It was ignorance, sorry about that - better check before ranting ;)
> Other worry: this means adding yet another mega-functional-component to
> Cocoon, and I have have been talking offlist about my worries in this
> direction.
>
> We better start using the -apps module then, I guess (and some other
> components might as well migrate there, too).
I'd still like these points to be addressed.
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Steven Noels <st...@outerthought.org>.
Christian Haul wrote:
> Before actually adding the code to the 2.1 repository, I'd like to
> have a final voting on it.
- do they need some SAP-jars in the classpath upon compilation time?
- if that is the case, do those need to be stored in ASF CVS?
- if that is the case, is that allowed according to their license?
- if all that is the case and the license only allows binary
distribution, we can implement mock classes
If all these are incorrect assumptions, pardon my ignorance.
FYI, Sylvain just asked whether mail/activation/jta.jar (Sun) could be
included in CVS. Apparently, there is something in their license which
doesn't allow this.
If license issues do not allow these components to be added to ASF CVS,
we could look and see whether they could be hosted at cocoondev.org
(since yes, they would be a valuable addition to Cocoon).
Other worry: this means adding yet another mega-functional-component to
Cocoon, and I have have been talking offlist about my worries in this
direction.
We better start using the -apps module then, I guess (and some other
components might as well migrate there, too).
> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
> R/3 connectivity components from patch [1] ?
I would like to see what others think before voting.
Thanks for bringing this up!
</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
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [VOTE] Inclusion of SAP R/3 components
Posted by Giacomo Pati <gi...@apache.org>.
+1
Giacomo
On Wed, 15 Jan 2003, Christian Haul wrote:
> Team.
>
> The long pending SAP R/3 patches [1] by Michael Gerzabek and Reinhard
> Poetz now carry the standard ASF licence plate, mock classes exist, I
> have reviewed the code and am happy with it. All issues have been
> solved by Michael and it was great working with him on it. I have not
> tested the components since I don't have a SAP installation to test
> against. Still, I'm confident in this patch.
>
> This has already been discussed [2] and [3]. Especially the long term
> perspective really _is_ an issue. However, I believe that these
> components will attract users and hopefully, the components can be
> maintained that way.
>
> Before actually adding the code to the 2.1 repository, I'd like to
> have a final voting on it.
>
> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
> R/3 connectivity components from patch [1] ?
>
> Here's my +1
>
> Chris.
>
> [1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9075
> [2] http://marc.theaimsgroup.com/?t=102636870300001&r=1&w=2
> [3] http://marc.theaimsgroup.com/?t=104014543000004&r=1&w=2
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [VOTE] Inclusion of SAP R/3 components
Posted by Matthew Langham <ml...@s-und-n.de>.
>Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
>R/3 connectivity components from patch [1] ?
+1
Is there any chance of setting up a public demo of this somewhere (i.e.
Cocoon accessing SAP)? That would be a really great showcase.
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
-----------------------------------------------------------------
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblogs:
http://radio.weblogs.com/0103021/
http://www.oreillynet.com/weblogs/author/1014
=================================================================
-----Original Message-----
From: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
Sent: Wednesday, January 15, 2003 2:33 PM
To: cocoon-dev@xml.apache.org
Subject: [VOTE] Inclusion of SAP R/3 components
Team.
The long pending SAP R/3 patches [1] by Michael Gerzabek and Reinhard
Poetz now carry the standard ASF licence plate, mock classes exist, I
have reviewed the code and am happy with it. All issues have been
solved by Michael and it was great working with him on it. I have not
tested the components since I don't have a SAP installation to test
against. Still, I'm confident in this patch.
This has already been discussed [2] and [3]. Especially the long term
perspective really _is_ an issue. However, I believe that these
components will attract users and hopefully, the components can be
maintained that way.
Before actually adding the code to the 2.1 repository, I'd like to
have a final voting on it.
Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
R/3 connectivity components from patch [1] ?
Here's my +1
Chris.
[1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9075
[2] http://marc.theaimsgroup.com/?t=102636870300001&r=1&w=2
[3] http://marc.theaimsgroup.com/?t=104014543000004&r=1&w=2
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [VOTE] Inclusion of SAP R/3 components
Posted by Michael Gerzabek <mi...@gmx.net>.
Hi all,
concerning long term perspective: we enjoy Cocoon since release 1.8 and
have at least 2 productive projects running with Cocoon 2.0 and the SAP
part. And we will go on!
So if testing is needed with real SAP we surely can do this. And I'm
also sure that we won't be the only one to use these components in the
future ;)
Michael
> -----Ursprungliche Nachricht-----
> Von: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> Gesendet: Mittwoch, 15. Janner 2003 14:33
> An: cocoon-dev@xml.apache.org
> Betreff: [VOTE] Inclusion of SAP R/3 components
>
>
> Team.
>
> The long pending SAP R/3 patches [1] by Michael Gerzabek and Reinhard
> Poetz now carry the standard ASF licence plate, mock classes exist, I
> have reviewed the code and am happy with it. All issues have been
> solved by Michael and it was great working with him on it. I have not
> tested the components since I don't have a SAP installation to test
> against. Still, I'm confident in this patch.
>
> This has already been discussed [2] and [3]. Especially the long term
> perspective really _is_ an issue. However, I believe that these
> components will attract users and hopefully, the components can be
> maintained that way.
>
> Before actually adding the code to the 2.1 repository, I'd like to
> have a final voting on it.
>
> Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
> R/3 connectivity components from patch [1] ?
>
> Here's my +1
>
> Chris.
>
> [1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9075
> [2] http://marc.theaimsgroup.com/?t=102636870300001&r=1&w=2
> [3] http://marc.theaimsgroup.com/?t=104014543000004&r=1&w=2
>
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org