ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: What are the available project ideas for GSOC 2013?
Date Sat, 20 Apr 2013 21:12:18 GMT
That is a good start, but I think that especially phase 1 resembles
too much a waterfall approach. It's better to view this more like an
agile project with a rapid succession of small sprints (lasting a
couple of days each) with well defined incremental goals. You will be
much more comfortable because you will get concrete results very
early. It also allows us to better monitor the progress and to adapt
the plan if there are unexpected issues or the project doesn't
progress fast enough.

Here is what the first few sprints could look like:

Sprint 1

* Goal: Basic support for SOAP 1.1 (without SwA or MTOM) with LLOM and
without databinding
* Test cases to develop: scenario with Spring-WS on client and server
side, without databinding, potentially base on
http://static.springsource.org/spring-ws/sites/2.0/reference/html/tutorial.html#d5e389
* Spring-WS APIs to implement: SoapMessageFactory, SoapMessage,
SoapElement hierarchy
* Axiom APIs to develop/implement: none

Sprint 2

* Goal: Refine the code to support SOAP 1.2 (still without SwA or MTOM) and DOOM
* Test cases to develop: extension of the test cases from sprint 1 to
test SOAP 1.2 and DOOM (may require refactoring to use MatrixTestCase)
* Spring-WS APIs to implement: refinement of the implementations
already created in Sprint 1
* Axiom APIs to develop/implement: none
* Notes: since no databinding is used, OMSourcedElement support is not
yet required

Sprint 3

* Goal: Add databinding support (LLOM only)
* Test cases to develop: new scenario using JAXB2
* Spring-WS APIs to implement: StreamingWebServiceMessage
* Axiom APIs to develop/implement: none
* Notes: at this point we will leverage AXIOM-420 (introduced in Axiom 1.2.14)

Sprint 4

* Goal: Extend databinding support to DOOM
* Test cases to develop: extension of the test cases from sprint 3 to cover DOOM
* Spring-WS APIs to implement: none
* Axiom APIs to develop/implement: OMSourcedElement support for DOOM
* Notes: in addition to the new test cases this sprint will also
leverage the existing test suite (which is trivial to enable for DOOM)
to ensure that that the OMSourcedElement implementation in DOOM works
as expected

Andreas


On Thu, Apr 18, 2013 at 7:15 AM, Andun Sameera <andunslg@gmail.com> wrote:
> Hi Andreas,
>
> I am sending the proposal attached.
>
> Thanks!
>
>
>
> On Wed, Apr 17, 2013 at 8:58 AM, Andun Sameera <andunslg@gmail.com> wrote:
>>
>> Hi Andreas,
>>
>> I have created a draft already, but have to add TDD and some milestones.
>> Will come up with the first draft ASAP.
>>
>>
>> Thanks!
>>
>>
>> On Wed, Apr 17, 2013 at 12:20 AM, Andreas Veithen
>> <andreas.veithen@gmail.com> wrote:
>>>
>>> I think that all stakeholders agree with the proposed approach. We
>>> should now start working on a project plan that defines the different
>>> milestones and phases/iterations.
>>>
>>> One thing that is really important for me is to ensure that the code
>>> produced during the project has a high level of test coverage. At the
>>> end of the project I prefer to have an incomplete implementation with
>>> complete test coverage (of the parts that are implemented of course)
>>> instead of having a complete implementation with incomplete test
>>> coverage. Therefore I would suggest to use a test driven approach
>>> where every iteration starts with writing the unit tests corresponding
>>> to the goals of the iteration, before writing the implementation code
>>> that makes these tests pass. Since the API that we are going to
>>> implement has already two existing implementations (the existing Axiom
>>> support and another one based on SAAJ), one could even develop the
>>> unit tests using the existing implementations (to ensure that the unit
>>> tests themselves are correct) and only then switch them to the new
>>> Axiom/Spring-WS integration.
>>>
>>> Andun, based on this can you create an initial draft of what the
>>> project plan might look like? Don't worry, I don't expect something
>>> realistic and complete right from the start. Just write down your
>>> ideas. We will then refine that until we get to something realistic.
>>>
>>> Andreas
>>>
>>>
>>> On Fri, Apr 12, 2013 at 6:51 PM, Andun Sameera <andunslg@gmail.com>
>>> wrote:
>>> > Hi All,
>>> >
>>> > Arjen has replied to Andreas's mail like this,
>>> >
>>> > Hi,
>>> >
>>> > On 7 apr. 2013, at 22:21, Andreas Veithen <andreas.veithen@gmail.com>
>>> > wrote:
>>> >
>>> >> First of all, I would like to stress that I made it clear on the Axiom
>>> >> mailing list that the project will not going to happen if the
>>> >> Spring-WS community has concerns or objections about it. Now let me
>>> >> answer the different points mentioned in your mail.
>>> >
>>> > I have no objections, nor concerns; in fact I am quite happy with the
>>> > fact that this project is proposed. I just want to make sure we set
>>> > things up correctly before we get started.
>>> >
>>> >> Regarding the circular dependency, I don’t think there is one. The
>>> >> current Axiom/Spring-WS integration only depends on the Spring-WS
>>> >> APIs, the Axiom API and the Axiom LLOM implementation (at runtime).
>>> >> The same will be true for the new Axiom/Spring-WS integration (except
>>> >> that LLOM may be replaced by DOOM). The new Axiom/Spring-WS
>>> >> integration would not depend on the existing one, and vice-versa.
>>> >> Therefore there is no circular dependency, at least not from a code
>>> >> point of view. Since the existing Axiom/Spring-WS integration is part
>>> >> of the same Maven artifact as the Spring-WS API, technically there
>>> >> will be a (Maven) dependency between the new integration (which would
>>> >> be in a separate Maven project) and the existing one. However, this
>>> >> would not cause any issues.
>>> >
>>> > Perhaps I wasn't clear enough: I was talking about circular artifact
>>> > (i.e. jar) dependencies, not code. Let me explain what I meant: The
>>> > spring-ws-core.jar currently has a compile-time dependency on the
>>> > axiom-api jar. If the new Axiom/SWS integration would live in this
>>> > jar, we will have a circular dependency, since the new integration
>>> > will probably need to compile against the SWS apis.
>>> >
>>> > But from your response I gather that the new integration is going to
>>> > live in a new Maven artifact, and that is a perfect solution to this
>>> > problem. Just to be clear, this means that we will have the following
>>> > dependency chain:
>>> >
>>> > axiom-sws-integration (the new artifact) --> spring-ws-core -->
>>> > axiom-api
>>> >
>>> > Is that correct?
>>> >
>>> >> Regarding the future of the existing Axiom support in Spring-WS, I
>>> >> would expect it to continue to exist for some time. Actually it could
>>> >> stay there forever, but at some point one would probably deprecate it
>>> >> and stop updating it to most recent Axiom versions, especially once we
>>> >> start to work on Axiom 1.3. The only reason to remove it would be if
>>> >> there is a major change in the Spring-WS APIs that makes it too costly
>>> >> to update the code (which is probably not a likely event).
>>> >
>>> > I agree: deprecation might be in order at some point, probably for a
>>> > new major version. The Spring-WS APIs have been pretty stable for the
>>> > last 5 years or so, so I don't expect any major changes.
>>> >
>>> >> Regarding the reasons to host the new Axiom/Spring-WS integration in
>>> >> the Axiom project, there are of course some opportunistic reasons. One
>>> >> reason I proposed this project is because it is a great opportunity to
>>> >> improve Axiom itself. Currently the development of Axiom is pretty
>>> >> much driven by the needs of a small set of downstream projects, namely
>>> >> Axis2, Rampart, Synapse and Abdera. Although Spring-WS uses Axiom, it
>>> >> currently doesn't act as a driver for the development of Axiom. With
>>> >> the proposed GSoC project, I would like to change that, but for me
>>> >> hosting the code in the Axiom project is much more efficient.
>>> >>
>>> >> That being said, there is a very good technical reason to develop the
>>> >> code inside the Axiom project. Both the existing and the new
>>> >> Axiom/Spring-WS integration is/will be more sensitive to the Axiom
>>> >> version than to the Spring-WS version. If the current code was
>>> >> released as an independent artifact, then it would probably work with
>>> >> a wide range of Spring-WS versions, but only with a much narrower
>>> >> range of Axiom versions. In fact, when one looks at the history of
>>> >> Spring-WS JIRA reports, one can see that users frequently encounter
>>> >> issues when upgrading to a new Axiom version. Releasing the
>>> >> Axiom/Spring-WS integration together with Axiom would definitely
>>> >> alleviate that problem.
>>> >
>>> > Ok, that makes sense.
>>> >
>>> > Once again, I do want to make clear that I am fully behind this
>>> > project. If that didn't come across in my original email, I apologize
>>> > for any confusion.
>>> >
>>> > Best regards,
>>> >
>>> > Arjen
>>> >
>>> > Also the GSOC's application process will be starting on 21st April. So
>>> > What will be the final decision for these approaches? I so that Arjen
>>> > has no objection for creating new Spring WS/AXIOM integration as a new
>>> > maven artifact inside AXIOM.
>>> >
>>> > Thanks!
>>> >
>>> > On Mon, Apr 8, 2013 at 1:52 AM, Andreas Veithen
>>> > <andreas.veithen@gmail.com> wrote:
>>> >> I just sent Arjen the following reply:
>>> >>
>>> >> ================================
>>> >>
>>> >> Arjen,
>>> >>
>>> >> First of all, I would like to stress that I made it clear on the Axiom
>>> >> mailing list that the project will not going to happen if the
>>> >> Spring-WS community has concerns or objections about it. Now let me
>>> >> answer the different points mentioned in your mail.
>>> >>
>>> >> Regarding the circular dependency, I don’t think there is one. The
>>> >> current Axiom/Spring-WS integration only depends on the Spring-WS
>>> >> APIs, the Axiom API and the Axiom LLOM implementation (at runtime).
>>> >> The same will be true for the new Axiom/Spring-WS integration (except
>>> >> that LLOM may be replaced by DOOM). The new Axiom/Spring-WS
>>> >> integration would not depend on the existing one, and vice-versa.
>>> >> Therefore there is no circular dependency, at least not from a code
>>> >> point of view. Since the existing Axiom/Spring-WS integration is part
>>> >> of the same Maven artifact as the Spring-WS API, technically there
>>> >> will be a (Maven) dependency between the new integration (which would
>>> >> be in a separate Maven project) and the existing one. However, this
>>> >> would not cause any issues.
>>> >>
>>> >> Regarding the future of the existing Axiom support in Spring-WS, I
>>> >> would expect it to continue to exist for some time. Actually it could
>>> >> stay there forever, but at some point one would probably deprecate it
>>> >> and stop updating it to most recent Axiom versions, especially once we
>>> >> start to work on Axiom 1.3. The only reason to remove it would be if
>>> >> there is a major change in the Spring-WS APIs that makes it too costly
>>> >> to update the code (which is probably not a likely event).
>>> >>
>>> >> Regarding the reasons to host the new Axiom/Spring-WS integration in
>>> >> the Axiom project, there are of course some opportunistic reasons. One
>>> >> reason I proposed this project is because it is a great opportunity to
>>> >> improve Axiom itself. Currently the development of Axiom is pretty
>>> >> much driven by the needs of a small set of downstream projects, namely
>>> >> Axis2, Rampart, Synapse and Abdera. Although Spring-WS uses Axiom, it
>>> >> currently doesn't act as a driver for the development of Axiom. With
>>> >> the proposed GSoC project, I would like to change that, but for me
>>> >> hosting the code in the Axiom project is much more efficient.
>>> >>
>>> >> That being said, there is a very good technical reason to develop the
>>> >> code inside the Axiom project. Both the existing and the new
>>> >> Axiom/Spring-WS integration is/will be more sensitive to the Axiom
>>> >> version than to the Spring-WS version. If the current code was
>>> >> released as an independent artifact, then it would probably work with
>>> >> a wide range of Spring-WS versions, but only with a much narrower
>>> >> range of Axiom versions. In fact, when one looks at the history of
>>> >> Spring-WS JIRA reports, one can see that users frequently encounter
>>> >> issues when upgrading to a new Axiom version. Releasing the
>>> >> Axiom/Spring-WS integration together with Axiom would definitely
>>> >> alleviate that problem.
>>> >>
>>> >> Regards,
>>> >>
>>> >> Andreas
>>> >>
>>> >> ================================
>>> >>
>>> >> On Thu, Apr 4, 2013 at 5:36 PM, Andun Sameera <andunslg@gmail.com>
>>> >> wrote:
>>> >>> Hi All,
>>> >>>
>>> >>> I have sent a mail to  Mr Arjen as relpy to above mail which he sent
>>> >>> me. I have added some point for his comments. Here is the reply he
>>> >>> sent me. what will be your comments on his points.
>>> >>>
>>> >>> Hi,
>>> >>>
>>> >>> Answers are inline.
>>> >>>
>>> >>> On 26 mrt. 2013, at 18:59, Andun Sameera <andunslg@gmail.com> wrote:
>>> >>>
>>> >>>> Thank you very much for replying quickly. As I mentioned earlier
>>> >>>> this project is focusing on rewriting the complete AXIOM support of Spring
>>> >>>> WS. So what are your comments on this particular statement in the project
>>> >>>> proposal,
>>> >>>>
>>> >>>> "In its present form, the project proposes to create a new
>>> >>>> Axiom/Spring-WS integration that would be maintained by the Axiom project,
>>> >>>> while the existing implementation is maintained by the Spring WS project."
>>> >>>
>>> >>> Well, I can certainly see a problem resulting from that approach if
>>> >>> we're not careful: circular dependencies. Spring-WS currently depends
>>> >>> on Axiom, for obvious reasons. If the new code lives in the Axiom
>>> >>> project, we can have a circular dependency, as Axiom will depend on
>>> >>> the Spring-WS APIs. I can see a couple of solutions to this:
>>> >>>
>>> >>> 1. Drop the Axiom support in Spring-WS. This might certainly be
>>> >>> possible in the future, but in Spring we have always had a strong
>>> >>> tendency to stay backwards compatible. If we require users to change
>>> >>> their configuration to use the new, Axiom-owned code, we will break
>>> >>> backwards compatibility. Also, the new API might not be completely
>>> >>> bug-free on the initial release, or behave differently in subtle
>>> >>> cases, giving users a reason to be reluctant to upgrade.
>>> >>>
>>> >>> 2. Host the new Axiom support in the Spring-WS project, possibly even
>>> >>> replacing the old Axiom support. From the proposal I gather that this
>>> >>> is not the goal, and I can respect that. I do wonder if there are any
>>> >>> technical reasons for doing so, since it would solve the circular
>>> >>> dependency problem nicely.
>>> >>>
>>> >>> 3. Implement an mirror of the Spring-WS APIs in the new Axiom support
>>> >>> project, making it trivial for me (or another Spring-WS committer) to
>>> >>> use the new Axiom support from within Spring-WS. Essentially, you
>>> >>> would create counterparts that mirror the interfaces in
>>> >>> org.springframework.ws.soap, which I would use in Spring-WS. To
>>> >>> illustrate:
>>> >>>
>>> >>> IN AXIOM:
>>> >>>
>>> >>> package org.apache.axiom.spring.ws;
>>> >>>
>>> >>> class NewAxiomSoapElement { // <-- does not implement Spring-WS
>>> >>> interface
>>> >>>
>>> >>>   public QName getName() { // <-- does follow Spring-WS API (see
>>> >>> org.springframework.ws.soap.SoapElement.getName())
>>> >>>     // implementation
>>> >>>   }
>>> >>>
>>> >>>   // more methods
>>> >>> }
>>> >>>
>>> >>> IN SPRING-WS:
>>> >>>
>>> >>> package org.springframework.ws.soap.axiom
>>> >>>
>>> >>> import org.springframework.ws.soap.SoapElement;
>>> >>> import org.apache.axiom.spring.ws.NewAxiomSoapElement;
>>> >>>
>>> >>> class AxiomSoapElement implements SoapElement { // <-- does implement
>>> >>> Spring-WS interface
>>> >>>   private NewAxiomSoapElement delegate;
>>> >>>
>>> >>>  public QName getName() {
>>> >>>    return delegate.getName(); // <-- uses delegate
>>> >>>  }
>>> >>>
>>> >>> }
>>> >>>
>>> >>> If solution 2 is not an option, I would strongly recommend going for
>>> >>> 3. At any rate, solution 1 is not an option for me. Also, there might
>>> >>> be other solutions to this problem, so if you see them let me know.
>>> >>>
>>> >>>> Also I have gone through your code based to understand how you use
>>> >>>> AXIOM in your implementation. Basically I have gone though
>>> >>>> https://fisheye.springsource.org/browse/spring-ws/trunk/core/src/main/java/org/springframework/ws/soap/axiom/.
>>> >>>> I think that particular package give the integration of AXIOM to Spring-WS.
>>> >>>> Am I correct ?
>>> >>>
>>> >>> Correct, that is where most of the integration lives. Note, however,
>>> >>> that we recently switched to GitHub and that the Fisheye URL still
>>> >>> points the old SVN repo. The correct Github URL is
>>> >>>
>>> >>>
>>> >>> https://github.com/springsource/spring-ws/tree/master/core/src/main/java/org/springframework/ws/soap/axiom
>>> >>>
>>> >>> Let me know if there is anything else you need help with.
>>> >>>
>>> >>> Best regards,
>>> >>>
>>> >>> Arjen
>>> >>>
>>> >>> On Tue, Apr 2, 2013 at 11:15 AM, Andun Sameera <andunslg@gmail.com>
>>> >>> wrote:
>>> >>>> Hi Andreas,
>>> >>>>
>>> >>>> I have participated in GSOC 2012(My project was not selected to the
>>> >>>> assigned slots for that particular mentoring organization). So have
>>> >>>> the experience of application process. Basically most of the
>>> >>>> mentoring
>>> >>>> organizations have some per-defined steps for application process.
>>> >>>> Also they are publishing some template applications.(I think Apache
>>> >>>> is
>>> >>>> publishing such a application, but last time there was not such
>>> >>>> application) Students are required to fill that template application
>>> >>>> with there project proposal(Or create own application with the
>>> >>>> proposal) and submit it to Google's http://www.google-melange.com
>>> >>>> site. Then they can review the application until the dead line.
>>> >>>>
>>> >>>> So can I proceed with the initial steps of process of creating a
>>> >>>> application? Assuming I can apply for this GSOC project.
>>> >>>>
>>> >>>> Thank You!
>>> >>>>
>>> >>>> On Tue, Apr 2, 2013 at 1:15 AM, Andreas Veithen
>>> >>>> <andreas.veithen@gmail.com> wrote:
>>> >>>>> That is good news.
>>> >>>>>
>>> >>>>> I had a look at the next deadlines for GSoC 2013:
>>> >>>>>
>>> >>>>> April 8: List of accepted mentoring organizations published on the
>>> >>>>> Google Summer of Code 2011 site.
>>> >>>>> April 9-21: Would-be student participants discuss application ideas
>>> >>>>> with mentoring organizations.
>>> >>>>> April 22: Student application period opens.
>>> >>>>> May 3: Student application deadline.
>>> >>>>>
>>> >>>>> So we basically have one month to get your application ready. It's
>>> >>>>> the
>>> >>>>> first time that I'm mentoring a GSoC project, so I'm not familiar
>>> >>>>> with
>>> >>>>> that process. Did you already do some research to get an idea what
>>> >>>>> is
>>> >>>>> involved here?
>>> >>>>>
>>> >>>>> Andreas
>>> >>>>>
>>> >>>>>
>>> >>>>> On Tue, Mar 26, 2013 at 11:26 AM, Andun Sameera
>>> >>>>> <andunslg@gmail.com> wrote:
>>> >>>>>> Hi,
>>> >>>>>>
>>> >>>>>> Having a early discussion with Spring WS Community about
>>> >>>>>> https://issues.apache.org/jira/browse/AXIOM-447 is a important
>>> >>>>>> thing to all
>>> >>>>>> the GSOC participants. As Andreas mentioned the idea have to
>>> >>>>>> calibrated upon
>>> >>>>>> there comment. So thought to go ahead and initialize the
>>> >>>>>> discussion. They
>>> >>>>>> didn't have a developer forum or a mailing list but only two email
>>> >>>>>> address
>>> >>>>>> of the main developers. I have given below the reply came from
>>> >>>>>> Arjen Poutsma
>>> >>>>>> when I mentioned that there is such a idea. I think he is really
>>> >>>>>> intrested
>>> >>>>>> in the idea.
>>> >>>>>>
>>> >>>>>> Thanks
>>> >>>>>> AndunSLG
>>> >>>>>>
>>> >>>>>> Hi,
>>> >>>>>>
>>> >>>>>> That sounds very interesting. I definitely think Spring-WS can
>>> >>>>>> benefit from
>>> >>>>>> some attention when it comes to Axiom. I am certainly willing to
>>> >>>>>> help on the
>>> >>>>>> Spring-WS side of things, since that is my speciality. I can't
>>> >>>>>> help much on
>>> >>>>>> the Axiom side of things, though.
>>> >>>>>>
>>> >>>>>> Best regards,
>>> >>>>>>
>>> >>>>>> Arjen
>>> >>>>>>
>>> >>>>>> On 24 mrt. 2013, at 09:44, Andun Sameera <andunslg@gmail.com>
>>> >>>>>> wrote:
>>> >>>>>>
>>> >>>>>>> Hi All,
>>> >>>>>>>
>>> >>>>>>> I am a student who is willing to participate in Google Summer of
>>> >>>>>>> Code
>>> >>>>>>> 2013. I am focusing on a project idea at Apache AXIOM. That idea
>>> >>>>>>> is to
>>> >>>>>>> improve the AXIOM support to Spring WS leverage the benefits of
>>> >>>>>>> new AXIOM
>>> >>>>>>> features.
>>> >>>>>>>
>>> >>>>>>> After the original implementation of AXIOM support in Spring WS
>>> >>>>>>> there were
>>> >>>>>>> many changes in AXIOM APIs etc. So some APIs have been deprecated
>>> >>>>>>> and some
>>> >>>>>>> new optimized APIs have been created. So most of the time Spring
>>> >>>>>>> WS does not
>>> >>>>>>> use the full potential of AXIOM.
>>> >>>>>>>
>>> >>>>>>> So the idea is to create a AXIOM/Spring-WS integration API form
>>> >>>>>>> the
>>> >>>>>>> scratch with all the new optimizations. This API will be
>>> >>>>>>> maintained by the
>>> >>>>>>> AXIOM project it self and have to be integrated to Spring WS to
>>> >>>>>>> get the
>>> >>>>>>> expected befits.
>>> >>>>>>>
>>> >>>>>>> Need your comments. Also the particular project is given in
>>> >>>>>>> https://issues.apache.org/jira/browse/AXIOM-447.
>>> >>>>>>>
>>> >>>>>>> BTW I have created a Jira issue @
>>> >>>>>>> https://jira.springsource.org/browse/SWS-826
>>> >>>>>>
>>> >>>>>>>
>>> >>>>>>> Thank You!
>>> >>>>>>>
>>> >>>>>>> Regards
>>> >>>>>>> Andun S.L. Gunawardana
>>> >>>>>>> Undergraduate
>>> >>>>>>> Department of Computer Science And Engineering
>>> >>>>>>> University of Moratuwa, Sri Lanka
>>> >>>>>>
>>> >>>>>> Regards
>>> >>>>>>
>>> >>>>>> Andun S.L. Gunawardana
>>> >>>>>> Undergraduate
>>> >>>>>>
>>> >>>>>> Department of Computer Science And Engineering
>>> >>>>>>
>>> >>>>>> University of Moratuwa, Sri Lanka
>>> >>>>>>
>>> >>>>>> Mobile - +94772019246
>>> >>>>>> Home  - +94412253032
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Contact me: AndunSLG AndunSLG
>>> >>>>>> Want a signature like mine? CLICK HERE.
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> On Sat, Mar 23, 2013 at 11:18 PM, Andun Sameera
>>> >>>>>> <andunslg@gmail.com> wrote:
>>> >>>>>>>
>>> >>>>>>> Hi,
>>> >>>>>>>
>>> >>>>>>> As you highlighted in the previous mail we have this special
>>> >>>>>>> requirement tightly coupled to the GSOC project , "The project
>>> >>>>>>> has a
>>> >>>>>>> specific requirement (see the second last item in
>>> >>>>>>> the description) to get "approval" by the Spring-WS community.
>>> >>>>>>> More
>>> >>>>>>> precisely the project is not going to happen if the Spring-WS
>>> >>>>>>> developers have concerns or objections about it."
>>> >>>>>>>
>>> >>>>>>> I have continued background reading which I started parallel to
>>> >>>>>>> the
>>> >>>>>>> discussion we had in
>>> >>>>>>> https://issues.apache.org/jira/browse/AXIOM-447.
>>> >>>>>>> So came across this question. As I think the process fulfilling
>>> >>>>>>> the
>>> >>>>>>> above requirement take much time, Since It has to be discussed in
>>> >>>>>>> the
>>> >>>>>>> spring community. Isn't it a good idea to star the discussion
>>> >>>>>>> process?
>>> >>>>>>> Also you have this statement in the description "candidate is
>>> >>>>>>> expected
>>> >>>>>>> to engage with the Spring WS developer community" So do all the
>>> >>>>>>> students who are willing to participate have to discuss or
>>> >>>>>>> someone
>>> >>>>>>> have to start the discussion?
>>> >>>>>>>
>>> >>>>>>> Please be kind enough to provide some instructions about those
>>> >>>>>>> queries. Eagerly waiting to participate in GSOC 2013.
>>> >>>>>>>
>>> >>>>>>> Thank You!
>>> >>>>>>>
>>> >>>>>>> Regards
>>> >>>>>>> Andun S.L. Gunawardana
>>> >>>>>>>
>>> >>>>>>> Blog - http://www.insightforfuture.blogspot.com/
>>> >>>>>>> LinkedIN -
>>> >>>>>>> http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>>> >>>>>>>
>>> >>>>>>> On Wed, Mar 6, 2013 at 9:55 AM, Andun Sameera
>>> >>>>>>> <andunslg@gmail.com> wrote:
>>> >>>>>>> > I got the point which you are highlighting. Until the required
>>> >>>>>>> > things
>>> >>>>>>> > are fulfilled, I will be in touch with this project while
>>> >>>>>>> > looking at
>>> >>>>>>> > the background more.
>>> >>>>>>> >
>>> >>>>>>> > Regards
>>> >>>>>>> > Andun S.L. Gunawardana
>>> >>>>>>> >
>>> >>>>>>> > Blog - http://www.insightforfuture.blogspot.com/
>>> >>>>>>> > LinkedIN -
>>> >>>>>>> > http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>>> >>>>>>> >
>>> >>>>>>> > On Wed, Mar 6, 2013 at 1:43 AM, Andreas Veithen
>>> >>>>>>> > <andreas.veithen@gmail.com> wrote:
>>> >>>>>>> >> You should not start working actively on this project (i.e.
>>> >>>>>>> >> coding)
>>> >>>>>>> >> before it has been accepted. For that to happen a couple of
>>> >>>>>>> >> things are
>>> >>>>>>> >> required:
>>> >>>>>>> >> * The ASF has to be accepted as a participating organization
>>> >>>>>>> >> in GSoC
>>> >>>>>>> >> (shouldn't be a problem).
>>> >>>>>>> >> * My proposal needs to receive sufficient support to be
>>> >>>>>>> >> accepted (only
>>> >>>>>>> >> a limited number of projects will be funded by Google).
>>> >>>>>>> >> * Other candidates may be interested in the project, and I
>>> >>>>>>> >> will not
>>> >>>>>>> >> assign the project to a student on a first come first serve
>>> >>>>>>> >> basis.
>>> >>>>>>> >> * The project has a specific requirement (see the second last
>>> >>>>>>> >> item in
>>> >>>>>>> >> the description) to get "approval" by the Spring-WS community.
>>> >>>>>>> >> More
>>> >>>>>>> >> precisely the project is not going to happen if the Spring-WS
>>> >>>>>>> >> developers have concerns or objections about it.
>>> >>>>>>> >>
>>> >>>>>>> >> Andreas
>>> >>>>>>> >>
>>> >>>>>>> >> On Tue, Mar 5, 2013 at 6:23 PM, Andun Sameera
>>> >>>>>>> >> <andunslg@gmail.com>
>>> >>>>>>> >> wrote:
>>> >>>>>>> >>> Hi,
>>> >>>>>>> >>>
>>> >>>>>>> >>> I have gone through most of the background information you
>>> >>>>>>> >>> given in
>>> >>>>>>> >>> the project description. Specially I have read the [1], [2],
>>> >>>>>>> >>> [3]
>>> >>>>>>> >>> articles which can be used to identify performance related
>>> >>>>>>> >>> issues in
>>> >>>>>>> >>> the combination of  Spring-WS/Axiom/WSS4J. Also I have put a
>>> >>>>>>> >>> comment
>>> >>>>>>> >>> in the JIRA issue with some questions.
>>> >>>>>>> >>>
>>> >>>>>>> >>> Since for further works need the answers to above mentioned
>>> >>>>>>> >>> questioned, I am currently looking at OMSourcedElement API to
>>> >>>>>>> >>> integrate DOOM support to it.
>>> >>>>>>> >>>
>>> >>>>>>> >>> [1] -
>>> >>>>>>> >>> http://www.ibm.com/developerworks/library/j-jws14/index.html
>>> >>>>>>> >>> [2] -
>>> >>>>>>> >>>
>>> >>>>>>> >>> http://www.ibm.com/developerworks/java/library/j-jws11/index.html
>>> >>>>>>> >>> [3] -
>>> >>>>>>> >>> http://www.ibm.com/developerworks/java/library/j-jws6/index.html
>>> >>>>>>> >>>
>>> >>>>>>> >>> Thank You!
>>> >>>>>>> >>>
>>> >>>>>>> >>> Regards
>>> >>>>>>> >>> Andun S.L. Gunawardana
>>> >>>>>>> >>>
>>> >>>>>>> >>> Blog - http://www.insightforfuture.blogspot.com/
>>> >>>>>>> >>> LinkedIN -
>>> >>>>>>> >>> http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>>> >>>>>>> >>>
>>> >>>>>>> >>>
>>> >>>>>>> >>> On Fri, Mar 1, 2013 at 12:54 PM, Andun Sameera
>>> >>>>>>> >>> <andunslg@gmail.com>
>>> >>>>>>> >>> wrote:
>>> >>>>>>> >>>>
>>> >>>>>>> >>>> Thank You for pointing me to a project. On the first read, I
>>> >>>>>>> >>>> had gone
>>> >>>>>>> >>>> through lot of questions in my mind. I will brought them up
>>> >>>>>>> >>>> after
>>> >>>>>>> >>>> further background reading. Also I will look in to your
>>> >>>>>>> >>>> description
>>> >>>>>>> >>>> deeply and will proceed with the necessary steps ASAP.
>>> >>>>>>> >>>>
>>> >>>>>>> >>>> Regards
>>> >>>>>>> >>>> Andun S.L. Gunawardana
>>> >>>>>>> >>>> Undergraduate
>>> >>>>>>> >>>> Department of Computer Science And Engineering
>>> >>>>>>> >>>> University of Moratuwa, Sri Lanka
>>> >>>>>>> >>>>
>>> >>>>>>> >>>> On Fri, Mar 1, 2013 at 4:17 AM, Andreas Veithen
>>> >>>>>>> >>>> <andreas.veithen@gmail.com> wrote:
>>> >>>>>>> >>>> > I just documented one project idea (that I would be
>>> >>>>>>> >>>> > willing to
>>> >>>>>>> >>>> > mentor) here:
>>> >>>>>>> >>>> >
>>> >>>>>>> >>>> > https://issues.apache.org/jira/browse/AXIOM-447
>>> >>>>>>> >>>> >
>>> >>>>>>> >>>> > Andreas
>>> >>>>>>> >>>> >
>>> >>>>>>> >>>> > On Thu, Feb 28, 2013 at 3:49 PM, Andun Sameera
>>> >>>>>>> >>>> > <andunslg@gmail.com>
>>> >>>>>>> >>>> > wrote:
>>> >>>>>>> >>>> >> Hi Devs,
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> I am a final year undergraduate who is willing to
>>> >>>>>>> >>>> >> participate in
>>> >>>>>>> >>>> >> GSOC
>>> >>>>>>> >>>> >> 2013. Because of my earlier experience and future
>>> >>>>>>> >>>> >> interests, it
>>> >>>>>>> >>>> >> will
>>> >>>>>>> >>>> >> be great chance to do a project in AXIOM or related. So
>>> >>>>>>> >>>> >> my query
>>> >>>>>>> >>>> >> is
>>> >>>>>>> >>>> >> $Subject.
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> I had the chance to complete my software engineering
>>> >>>>>>> >>>> >> internship at
>>> >>>>>>> >>>> >> WSO2 Lanka Pvt Ltd, which is a leading middle-ware
>>> >>>>>>> >>>> >> solutions
>>> >>>>>>> >>>> >> development company. Since they are using most of the
>>> >>>>>>> >>>> >> Apache
>>> >>>>>>> >>>> >> projects
>>> >>>>>>> >>>> >> to build there solutions, I had many chances to get a
>>> >>>>>>> >>>> >> good
>>> >>>>>>> >>>> >> exposure to
>>> >>>>>>> >>>> >> the projects and there code-bases. Specially I have used
>>> >>>>>>> >>>> >> AXIOM in
>>> >>>>>>> >>>> >> my
>>> >>>>>>> >>>> >> all the projects at internship. That gave me the chance
>>> >>>>>>> >>>> >> to explore
>>> >>>>>>> >>>> >> about AXIOM more. Also I have did lot of projects related
>>> >>>>>>> >>>> >> to
>>> >>>>>>> >>>> >> middle-ware and cloud where AXIOM is used. You can find
>>> >>>>>>> >>>> >> more about
>>> >>>>>>> >>>> >> those from my LinkedIn profile -
>>> >>>>>>> >>>> >> lk.linkedin.com/pub/andun-s-l-gunawardana/34/646/703/ or
>>> >>>>>>> >>>> >> from my
>>> >>>>>>> >>>> >> blog
>>> >>>>>>> >>>> >> http://www.insightforfuture.blogspot.com/
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> Specially I want highlight the project Streaming XPath
>>> >>>>>>> >>>> >> Parser for
>>> >>>>>>> >>>> >> WSO2
>>> >>>>>>> >>>> >> ESB
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> (http://wso2.org/library/articles/2013/01/streaming-xpath-parser-wso2-esb)
>>> >>>>>>> >>>> >> which mainly built on top of AXIOM and Data Streams. This
>>> >>>>>>> >>>> >> implementation provides a high performance XPath parser
>>> >>>>>>> >>>> >> to the
>>> >>>>>>> >>>> >> ESB.
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> So I think the above highlighted experiences makes me a
>>> >>>>>>> >>>> >> good
>>> >>>>>>> >>>> >> candidate
>>> >>>>>>> >>>> >> to do a project in GSOC. Can you help me to proceed.
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> Regards
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> Andun S.L. Gunawardana
>>> >>>>>>> >>>> >> Undergraduate
>>> >>>>>>> >>>> >> Department of Computer Science And Engineering
>>> >>>>>>> >>>> >> University of Moratuwa, Sri Lanka
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >> ---------------------------------------------------------------------
>>> >>>>>>> >>>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >>>>>>> >>>> >> For additional commands, e-mail: dev-help@ws.apache.org
>>> >>>>>>> >>>> >>
>>> >>>>>>> >>>> >
>>> >>>>>>> >>>> >
>>> >>>>>>> >>>> >
>>> >>>>>>> >>>> > ---------------------------------------------------------------------
>>> >>>>>>> >>>> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >>>>>>> >>>> > For additional commands, e-mail: dev-help@ws.apache.org
>>> >>>>>>> >>>> >
>>> >>>>>>> >>
>>> >>>>>>> >>
>>> >>>>>>> >> ---------------------------------------------------------------------
>>> >>>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >>>>>>> >> For additional commands, e-mail: dev-help@ws.apache.org
>>> >>>>>>> >>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >>>>> For additional commands, e-mail: dev-help@ws.apache.org
>>> >>>>>
>>> >>>>
>>> >>>> --
>>> >>>> Regards
>>> >>>> Andun S.L. Gunawardana
>>> >>>> Undergraduate
>>> >>>> Department of Computer Science And Engineering
>>> >>>> University of Moratuwa
>>> >>>> Sri Lanka
>>> >>>>
>>> >>>> Blog - http://www.insightforfuture.blogspot.com/
>>> >>>> LinkedIn -
>>> >>>> http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>>> >>>> Twitter -http://twitter.com/AndunSLG
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Regards
>>> >>> Andun S.L. Gunawardana
>>> >>> Undergraduate
>>> >>> Department of Computer Science And Engineering
>>> >>> University of Moratuwa
>>> >>> Sri Lanka
>>> >>>
>>> >>> Blog - http://www.insightforfuture.blogspot.com/
>>> >>> LinkedIn -
>>> >>> http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>>> >>> Twitter -http://twitter.com/AndunSLG
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >>> For additional commands, e-mail: dev-help@ws.apache.org
>>> >>>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> >> For additional commands, e-mail: dev-help@ws.apache.org
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Regards
>>> > Andun S.L. Gunawardana
>>> > Undergraduate
>>> > Department of Computer Science And Engineering
>>> > University of Moratuwa
>>> > Sri Lanka
>>> >
>>> > Blog - http://www.insightforfuture.blogspot.com/
>>> > LinkedIn - http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>>> > Twitter -http://twitter.com/AndunSLG
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> > For additional commands, e-mail: dev-help@ws.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: dev-help@ws.apache.org
>>>
>>
>>
>>
>> --
>> Regards
>> Andun S.L. Gunawardana
>> Undergraduate
>> Department of Computer Science And Engineering
>> University of Moratuwa
>> Sri Lanka
>>
>> Blog - http://www.insightforfuture.blogspot.com/
>> LinkedIn - http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
>> Twitter -http://twitter.com/AndunSLG
>>
>>
>>
>>
>
>
>
>
> --
> Regards
> Andun S.L. Gunawardana
> Undergraduate
> Department of Computer Science And Engineering
> University of Moratuwa
> Sri Lanka
>
> Blog - http://www.insightforfuture.blogspot.com/
> LinkedIn - http://www.linkedin.com/pub/andun-s-l-gunawardana/34/646/703
> Twitter -http://twitter.com/AndunSLG
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message