[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [Subclipse-dev] FW: package org.tigris.subversion.javahl

From: Brad Harper <brad.harper_at_epsiia.com>
Date: 2007-02-01 18:36:45 CET

Mark:
 
I can see that issue tracking is sufficiently ubiquitous to consider it
as an extension-point that is separate from a hypothetical plugin like
one I was attempting to describe, below.
 
Brad
brad.harper@epsiia.com

   -----Original Message-----
   From: Brad Harper
   Sent: Thursday, February 01, 2007 9:40 AM
   To: dev
   Subject: [Subclipse-dev] FW: package org.tigris.subversion.javahl
   
   

   
   Per Mark's request ...
    
   The title, from the original thread, doesn't represent the direction
   that our off-line dialog had taken.
    
   Brad
   brad.harper@epsiia.com
    
    -----Original Message-----
   From: Mark Phippard [mailto:markphip@verizon.net]
   Sent: Thursday, February 01, 2007 9:18 AM
   To: Brad Harper
   Subject: Re: package org.tigris.subversion.javahl
   
   

   Can we have any future conversation about this idea on the
   dev@subclipse.tigris.org mailing list?
   
   Thanks
   
   Mark
   
   
   
   ----- Original Message ----
   From: Brad Harper <brad.harper@epsiia.com>
   To: markphip <markphip@verizon.net>
   Sent: Thursday, February 1, 2007 9:49:06 AM
   Subject: RE: package org.tigris.subversion.javahl
   
   
   Mark:
    
   To help me understand how this would fit within the context of
   Subclipse, I see it integrating
   with the hypothetical extension via the commit log message text.
    
   The hypothetical plugin would supply a ui containing whatever input
   fields it chose, validate
   user input, interpret results, then construct the log message in a
   format compatible with
   the local environment.
    
   Subclipse would simply take the log message it was given and pass it
   to SVN in the commit
   operation. Default behavior might be equivalent what's provided
   currently.
    
   Brad

      -----Original Message-----
      From: Mark Phippard [mailto:markphip@verizon.net]
      Sent: Wednesday, January 31, 2007 1:03 PM
      To: Brad Harper
      Subject: Re: package org.tigris.subversion.javahl
      
      

      We'd have to work that out. It could be they are used as a fall
      back if there are no plugins installed which use the extension
      point, or it could be that we provider a "Bugtraq" plugin that
      fills the extension point and use those properties to get its
      info.
      
      I recall someone submitted a patch for some of this to the dev@
      list a couple of months ago. It lacked some of the things we
      would want/need though, such as letting their be multiple possible
      plugins that use the extension point. Could be a starting point.
      
      The Eclipse Mylar plugin also needs to be considered. Part of why
      we have held off is that there has been some talk of them creating
      a generic issue tracking extension point that we could then reuse.
      
      
      

      ----- Original Message ----
      From: Brad Harper <brad.harper@epsiia.com>
      To: markphip <markphip@verizon.net>
      Sent: Wednesday, January 31, 2007 1:18:05 PM
      Subject: RE: package org.tigris.subversion.javahl
      
      
      Mark:
       
      I understand.
       
      Yes, I am interested -- but I'm reluctant to sign on without a
      better idea
      of what "invest the effort" means [to both you and me].
       
      As I mentioned in an earlier e-mail, I'm new to Eclipse plugin
      development. If
      I understand correctly, you're suggesting the addition of plugin
      extension points to
      the Subclipse plugin. Would this approach mean basically replacing
      the
      [current] implementation where svn bugtraq properties are used to
      configure
      the Subclipse plugin's ui and behavior?
       
      Brad

         -----Original Message-----
         From: Mark Phippard [mailto:markphip@verizon.net]
         Sent: Tuesday, January 30, 2007 7:12 PM
         To: Brad Harper
         Subject: Re: package org.tigris.subversion.javahl
         
         

         We wouldn't be directly interested, but I and others have given
         thoughts to how we could add Eclipse extensions points so that
         this sort of functionality could be added by a plugin. That
         would be the "Eclipse way" to do it. I think the problem is we
         have to consider the scenario where there might be multiple
         plugins that want to contribute, or plugin A for project A and
         plugin B for project B and it then becomes easy to just put it
         off.
         
         I do not want to direct you to another product, and I think
         Subclipse is the best one, but have you looked at Subversive?
         I ask, because the company developing it has added a lot of
         extension points like this so that they can extend the base
         product with their own proprietary tools. They might already
         have an extension point you could use to add this feature and
         that would at least save you from maintaining customizations.
         
         That being said, if you wanted to invest the effort to help us
         do this right, it is possible we could get this into Subclipse.
         
         Mark
         
         

         ----- Original Message ----
         From: Brad Harper <brad.harper@epsiia.com>
         To: markphip <markphip@verizon.net>
         Sent: Tuesday, January 30, 2007 4:36:44 PM
         Subject: RE: package org.tigris.subversion.javahl
         
         
         Mark:
          
         Thanks.
          
         We're wanting to enforce entry of specific information, beyond
         what's
         possible with a template. E.g. introduce separate input
         components for 'code
         reviewer' and an indication when work associated with the
         commit
         operation requires documentation change(s). This and other info
         will help in
         the automatic extraction of release notes content.
          
         How interested is your team in this sort of customization? In
         particular,
          
         Brad
         brad.harper@epsiia.com

            -----Original Message-----
            From: Mark Phippard [mailto:markphip@verizon.net]
            Sent: Tuesday, January 30, 2007 3:00 PM
            To: Brad Harper
            Subject: Re: package org.tigris.subversion.javahl
            
            

            You need svnjavahl.jar for that package, which is the
            Subversion JavaHL source code. You will eventually likely
            need svnkit.jar or the source code for SVNKit as well.
            
            If you are going to customize Subclipse, I'd recommend just
            checking out from the tag, which will include everything you
            need to have it all setup for development.
            
            Mark
            
            

            ----- Original Message ----
            From: Brad Harper <brad.harper@epsiia.com>
            To: markphip <markphip@tigris.org>
            Sent: Tuesday, January 30, 2007 10:42:11 AM
            Subject: package org.tigris.subversion.javahl
            
            
            Hello Mark:
            
            I'm trying to build subclipse plugin from the source
            distribution
            'subclipse-source-1.0.4.zip' before attempting modifications
            that
            will support local process requirements. [I'm new to Eclipse
            plug-in
            development.]
            
            I find compiler error messages complaining that the subject
            package does not exist. Have I missed jar files that should
            be
            added to the project's build path?
            
            Regards,
            
            Brad
            brad.harper@epsiia.com
            

            

         

      

   

   
Received on Thu Feb 1 18:37:16 2007

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.