Re: [recommenders-dev] Stacktrace parser/detector

[Johannes Lerch <lerch@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I have created the repository. You find informations on how to access
it here: http://wiki.eclipse.org/Recommenders/Labs
Projectname is "stacktraces"

I think pure html as prototype is a good idea. Depending on the
framework we will use, we can easily extract templates from that html.
Marcel and me are both phd students at Darmstadt University of
Technology and we spend the whole day on that project. Okay, that's
not right ;-) We have to do teaching too and students are around all
the time.


2011/6/3 Paulo Sérgio Medeiros <pasemes@xxxxxxxxx>:
> Ok, I'll work on the UI. Just to let you know that I'm not a specialist on
> that, but I'll do my best. :-)
>
> I'll start with the web UI. I was thinking to use pure html to implement the
> UI prototype, do you suggest something different? By the way, I will take a
> look at http://grepcode.com/ as Sacha pointed.
>
> As soon as you have set up the repository, please let me know. Another thing
> that I would like to ask is how much time you are dedicating to the project.
> I'll try to ajust mine to your pace.
>
> One last question, you have already mentioned students and the university
> repository. Are you professors? Students? From which university?
>
> On Wed, Jun 1, 2011 at 3:44 AM, Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
> wrote:
>>
>> Hi Paulo,
>> thanks for the papers. I was aware of the latter two (Bettenburg and
>> Schröter) but didn't know the former two.
>>
>> Great idea to have a crawler in platforms like bugzilla, I didn't thought
>> about that. In my “roadmap” I was only thinking about users inserting the
>> stacks via IDEs or the web interface and then discussing about them using
>> the web interface.
>>
>> Yes, a web interface to add and search for stacktraces, an Eclipse UI that
>> finds, searches and collects Userfeedback, and a crawler that fills an
>> initial database to start and continuously updates with latest stacktraces
>> found in Issue trackers, forums, and mailing lists etc., and a couch db that
>> stores these stacktraces along with their information where they have been
>> found/discussed + groupings of related stacktraces. That's roughly the idea
>> of what we would like to see at the end.
>>
>> I'm using Scala (sbt + specs + intellij) and Mongodb. I was planning to
>> use Scalatra or Bowler for a rest interface to this core. I was using them
>> only to learn some new technology, so I'm don't have any problem to change
>> that.
>>
>> That's good to hear. I also would like to work with Scala but I'm not sure
>> whether is is the best way since it needs to be embedded into an existing
>> OSGI architecture on server side and Eclipse UI and Web UI and maven build
>> system. It would take some effort to get this running and I'm not sure
>> whether the integration of scala in the current situation is valuable.
>>
>> At the stage that you are I think that the web ui is natural step. In
>> fact, I was just finishing the basic matcher to try to sketch some UI. So,
>> for me it ok to go with that. Lets try that. I've idealized some screens in
>> my mind, but hasn't stop to draw anything. And, as you said, the UI is a
>> really important component of the system. It should turn the search natural
>> and should really help to discuss and find useful information about the
>> faults. Some touch of social web (or Web 2.0) can be thought also such as
>> users indicating that one stack is related to the same fault of another
>> stack. But this is only in future versions.
>>
>> Having some sketches would be great! In the meanwhile we have to set up a
>> GIT repository for this and move the parts for the server and Eclipse UI
>> into this repository. We will start out with a university repository. After
>> some progress we can ask the Eclipse PMC to get committer access for you on
>> Code Recommenders and move the repository contents to Eclipse.
>>
>> Finally, regarding the papers, well as a PhD student this is always
>> welcome :-). Nevertheless, I was really wanting to push that to a “real”
>> project and not wanting to stop only on the prototype. I don't know what are
>> your expectations about that.
>>
>> That's great to hear (especially the last part :) ). Since you are a PhD
>> student I just wanted to point out that joint research papers is also in the
>> scope of this project. However, what drives us is the vision and how
>> beneficial such a system might get. The efforts we put into code
>> recommenders is by far more than required for a pure research project. Thus:
>> We want a real project too :)
>>
>> For the evaluations, the Eclipse bugzilla dataset will be very useful. I
>> work as software architect at Petrobras and can conduct some evaluations
>> there in the future ;-). My research group expertise is Experimental
>> Software Engineering and my masters was about using Action Research
>> methodology in Software Engineering and we can think about future studies.
>>
>> Sounds good. Let's get back to this when the prototype is up an running.
>>
>> So, how to continue?
>> Paulo, you start with some Web UI sketches?
>> Johannes , can you create a separate repository for stacktraces?
>> @Johannes, @Eric
>> Since this project now involves people w/o committer access at Eclipse I
>> think we have to split the repository for this and create a new, public one
>> on vandyk, right?  If you agree we can start moving things into this new
>> repository one by one and integrate them into the build system.
>> Best,
>> Marcel
>>
>> _______________________________________________
>> recommenders-dev mailing list
>> recommenders-dev@xxxxxxxxxxx
>> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>>
>
>
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>
>