Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jasnell@gmail.com designates
 66.249.82.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=a3oQFjkVZRcdrewRu8La/sW5sOb0SKEWxRe5D5k3lCHYVu99Qus0XuwVdNGe4r2uDbtUXMDtozEJzeqRQpcCxOvYTYJuP5aDfyj9NFxr5jXCaPb2Cx//TE2uO0crJyD88bGtpQBwSuRciuF0YD52iyk6DK9M5S22tH8E26+q4uw=
Message-ID: <46BD0321.9010209@gmail.com>
Date: Fri, 10 Aug 2007 17:30:25 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: [jira] Created: (ABDERA-56) Spring Integration
References: <6111626.1186689702547.JavaMail.jira@brutus>
	 <46BCF0D8.5050809@gmail.com>
	 <7b774c950708101644j3ef01778pf0a93c036d27c744@mail.gmail.com>
	 <46BCF98A.7030204@gmail.com>
 <46BCF9AE.6040907@gmail.com>	 <7b774c950708101652j4723e37ak1601c6ed72e500b4@mail.gmail.com>
	 <46BD0068.7000409@gmail.com>
 <7b774c950708101725u1098dcd6n2ed0012b9057610e@mail.gmail.com>
In-Reply-To: <7b774c950708101725u1098dcd6n2ed0012b9057610e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Well, my concern regarding distribution is mainly with the ant build.
We use the ant build to build the release.  The maven build is provided
primarily as a convenience for developers who prefer to work with that
tool.  I'm sure the folks who actually use maven can speak up for
themselves, but I would not see any problem with spring not being
optional in the maven pom so long as it's not included in the release
zip created by the ant build.

(I certainly hope that makes sense... it's been a long day :-) )

- James

Dan Diephouse wrote:
> I can do that. Although, I would still prefer that it go in the spring
> module. Then the Maven POM stuff works correctly. Otherwise we need to
> declare the spring-web dependency as optional and then people need to pull
> it in themselves. Minor point though I guess.
> 
> - Dan
> 
> On 8/10/07, James M Snell <jasnell@gmail.com> wrote:
>> Ok, then I guess I'm fine with this.  Would it be possible to have you
>> make two tweaks to the patch?
>>
>>   1. Collect all the spring stuff into:
>>        org.apache.abdera.protocol.server.spring.*
>>
>>      We can just drop it in as part of the server module
>>
>>   2. Provide the ant build and deps.properties patches necessary
>>      to build the spring stuff.
>>
>> If you can't do the second, no problem, I can do it if you can provide
>> me with the proper url to download the right version of spring.
>>
>> - James
>>
>> Dan Diephouse wrote:
>>> Oh yeah, a definite -1 to shipping any spring stuff in the distribution.
>> If
>>> people are using the Abdera Spring stuff I think they already have
>> Spring
>>> around.
>>> Cheers,
>>> - Dan
>>>
>>> On 8/10/07, James M Snell <jasnell@gmail.com> wrote:
>>>> "shipping it" == shipping spring, not your patch :-)
>>>>
>>>> - James
>>>>
>>>> James M Snell wrote:
>>>>> My *only* concern with the spring stuff is introducing additional
>>>>> dependencies.  It's not that big of a deal to require spring when
>>>>> building but I would definitely want to make sure we're not shipping
>> it
>>>>> or requiring it.
>>>>>
>>>>> - James
>>>>>
>>>>> Dan Diephouse wrote:
>>>>>> Thanks for taking the time to look it over James.
>>>>>>
>>>>>> Why the contrib module?
>>>>>>
>>>>>> My position would be that:
>>>>>> - This is an important feature and one very likely to increase
>> Abdera's
>>>> user
>>>>>> base. User's shouldn't have to build it on their own (which is what
>> the
>>>>>> contrib module seems to imply - forgive me if I'm wrong here).
>>>>>> - Contrib stuff isn't built with the regular build, so its likely to
>>>> get out
>>>>>> of date.
>>>>>> - My preference would be for it to be outside the server module as
>>>> there is
>>>>>> the potential for some client related stuff as well in the future.
>>>>>> - I'll happily write up some docs to ensure that people use it -
>> right
>>>> now
>>>>>> there are absolutely no server side docs and its quite hard to get
>>>> started
>>>>>> writing APP server stuff.
>>>>>>
>>>>>> The only change in the commit which I feel may be controversial is
>> the
>>>> one
>>>>>> regarding the contextPath and Resolvers. I kind of feel that I as a
>>>> user
>>>>>> shouldn't have to worry about the context path when I set up a
>>>> Resolver. So
>>>>>> I made Abdera set the contextPath. It'd be nice if we could somehow
>> get
>>>> rid
>>>>>> of this requirement altogether, but I'm not familiar enough with
>> abdera
>>>> to
>>>>>> comment on how that should be done.
>>>>>>
>>>>>> - Dan
>>>>>>
>>>>>>
>>>>>> On 8/10/07, James M Snell <jasnell@gmail.com> wrote:
>>>>>>> Dan, at first glance this looks good.  The other committers might
>> have
>>>> a
>>>>>>> different opinion, but I think the spring stuff should likely go
>> into
>>>>>>> the contrib module as opposed to becoming its own module or being
>>>>>>> dropped into the server module.  Does that work for you?
>>>>>>>
>>>>>>> I'll have to go through the rest of the changes later this weekend.
>>>>>>>
>>>>>>> - James
>>>>>>>
>>>>>>> Dan Diephouse (JIRA) wrote:
>>>>>>>> Spring Integration
>>>>>>>> ------------------
>>>>>>>>
>>>>>>>>                  Key: ABDERA-56
>>>>>>>>                  URL:
>> https://issues.apache.org/jira/browse/ABDERA-56
>>>>>>>>              Project: Abdera
>>>>>>>>           Issue Type: New Feature
>>>>>>>>             Reporter: Dan Diephouse
>>>>>>>>              Fix For: 0.3.0
>>>>>>>>          Attachments: spring.patch
>>>>>>>>
>>>>>>>> I've written a spring module for Abdera which providers an
>>>> AbderaServlet
>>>>>>> which works with Spring as well as some XML parsers. With this
>>>> creating an
>>>>>>> Abdera Provider becomes as simple as this:
>>>>>>>>   <a:serviceContext>
>>>>>>>>
>>>>>>>>     <a:provider>
>>>>>>>>       <ref bean="provider"/>
>>>>>>>>     </a:provider>
>>>>>>>>
>>>>>>>>     <a:targetResolver>
>>>>>>>>       <a:regexTargetResolver>
>>>>>>>>         <a:collection>/atom/feed(\\?[^#]*)?</a:collection>
>>>>>>>>         <a:entry>/atom/feed/([^/#?]+)(\\?[^#]*)?</a:entry>
>>>>>>>>         <a:service>/atom(\\?[^#]*)?</a:service>
>>>>>>>>       </a:regexTargetResolver>
>>>>>>>>     </a:targetResolver>
>>>>>>>>
>>>>>>>>   </a:serviceContext>
>>>>>>>>
>>>>>>>>   <bean id="provider" class="org.apache.abdera.spring.TestProvider
>> ">
>>>>>>>>   </bean>
>>>>>>>>
>>>>>>>> The only code you need to write then is the TestProvider class.
>>>>>>>>
>>>>>>>> This patch does make two other changes.
>>>>>>>>
>>>>>>>> 1. It modifies the Resolver interface to add a
>>>>>>> initializeContextPath(String context) method. This makes it so you
>> can
>>>>>>> create target resolvers and not have to worry about the context path
>>>> when
>>>>>>> you initialize it - Abdera will just initialize it later.  I'm not
>>>> sure that
>>>>>>> what I came up with is the best way to do that though. Any other
>>>>>>> suggestions? Maybe Resolver.resolve should take contextPath as a
>>>>>>> parameter? Maybe the request URI should come without the context
>> path
>>>> in it?
>>>>>>>> 2. Uses the correct groupId for Woodstox in MAven
>>>>>>>>
>>>
>>>
> 
> 
>