Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
From: Daniel Kulp <dkulp@apache.org>
To: dev@cxf.apache.org
Cc: gliesian <robert@gliesian.com>
Subject: Re: [DISCUSS] how to handle ws_security/interopfest example
Date: Tue, 20 Sep 2011 15:38:35 -0400
Message-ID: <2219825.3vjMyhBC6m@dilbert.dankulp.com>
User-Agent: KMail/4.7.1 (Linux/3.0.1; KDE/4.7.1; x86_64; ; )
In-Reply-To: <1316513931906-4822033.post@n5.nabble.com>
References: <EAF28C6C-AABE-4C2C-82A0-D22AA5773F72@gmail.com>
 <4E72B1EB.3020108@gmail.com> <1316513931906-4822033.post@n5.nabble.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Tuesday, September 20, 2011 3:18:51 AM gliesian wrote:
> From a user expectation standpoint, example programs should work (e.g.,
> access external dependencies).

Well, from my standpoint, it really depends on  what the purpose of the 
example is.   For example, we COULD have an example that showed how to create 
and use a CXF client to access salesforce.com data.   There definitely could 
be some value in something like that to some people.   However, it would 
obviously require access to external services.    In cases like this, it's 
vital to point out, up front, in the README what the requirements are and set 
the expectations immediately.  Another example may be using CXF clients to 
manipulate your Amazon cloud via AWS.    Again, useful as an example for some 
people, but completely dependent on external services (and actually an AWS 
account for the user).

IMO, this particular sample falls into this type of case.   The purpose of the 
interopfest stuff is (OK, was) specifically to show interopability between CXF 
and .NET.   Without shipping full .NET clients, services, and STS, the only 
way to really show that is to  use external services.   We tried to be as up 
front about that in the README as we could.    The main issue now is that 
those services now seem to be gone for good.


> Perhaps the interopfest project should not be considered a sample (example)
> project... and therefore moved out of the binary distribution and into the
> src distribution only, maybe in it's own folder (i.e, not under the samples
> folder)?
> 
> If in the event, that the external dependencies are restored and/or included
> in the distribution and it makes sense to have the interopfest projects
> within the samples, they could be moved back.

Everything is in SVN.   We can always just restore it or even copy it out of 
one of the tags if the services come back.     That IS why we use version 
control.   :-)

At this point, I just don't see the interop plugfest endpoints coming back 
anytime soon.   I would just remove them from the builds for now.  

Dan


> However, to bring this issue to a expedited closure, a more thorough
> explanation as to the history of the interopfest project(s), as well as
> including information about the current state and future expectation of
> these projects in the README.txt file(s) would probably be sufficient, with
> no other changes necessary.
> 
> Thanks,
> Robert
> 
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/DISCUSS-how-to-handle-ws-security-interopfe
> st-example-tp4805281p4822033.html Sent from the cxf-dev mailing list archive
> at Nabble.com.
-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com