| 
 Hi Dave, 
  
Well in an ideal world it would be great to have LOTS of 
software approved by Eclipse Legal and thus ready for 
redistribution. 
  
But in the world today, the resources of the Eclipse Legal 
team are limited and thus any work they would do for ANTR tools is at the 
expense of other libraries to be approved. Of course you could go and apply for 
ANTLR tools, mention in a comment that it's not strictly required (i.e. 
communicate the priority you see for it), and then have the Eclipse Legal team 
determine if and when they want to review. Perhaps they'd do some initial review 
to estimate rough size of the work and if it's even realistic to ever get it 
approved. That may be helpful, but with Galileo wrapping up now you'd get even 
such initial feedback not before August I guess. 
  
Given the long time it needs to get something approved, you 
also need to keep in mind that the library (ANTLR tools) evolves at the same 
time, so at the time Eclipse Legal is ready to review 3.1 you may already want 
3.1.5. 
  
Because of these things, and because I guess you want to 
get something out of the door, I believe that you'll have to live with 
downloading ANTLR tools separately for some time at least. Thus my initial 
suggestion.  
  
If you still believe that you'd want the tools eventually , 
you can file a CQ since it's always good to communicate your intent and wishes 
to those who know what to do with them. Be sure to communicate clearly your 
priority. 
  
Cheers, 
-- 
Martin Oberhuber, Senior Member of Technical 
Staff, Wind River 
Target Management Project 
Lead, DSDP PMC Member 
  
   
  
  
  
  Martin, 
    
  Thanks, it does 
  help.   
    
  One last try at 
  convincing you that distributing the whole antlr jar might be a good thing 
  … 
  
    - the current XDCtools product 
    (from TI) does ship the ANTLR tool (we build and test with the same pieces 
    delivered to the customer) 
    
 - the only other tools required to 
    build XDCtools are a java compiler and a native host C compiler (and a 
    previous release of XDCtools).  Everyone who expects to rebuild 
    something for eclipse has both Java and C already in installed on the 
    development host as are SCM tools. 
    
 - it's one more tool and a 
    sequence of steps that can go wrong; just because there are other error 
    prone steps doesn't mean we can add one more without feeling 
    guilty 
    
 - I might be wrong, but I thought 
    Ant was shipped with eclipse. 
  
    
  That said, if your 
  intuition is that requiring contributors (and committers) to manage the ANTLR 
  tool as a separate "component" of their build environment is better than 
  trying to re-distribute ANTLR within XDCtools (and eclipse), then we'll go 
  with just the runtime.  After all, we _can_ work around the issue and build 
  procedures are not easy. 
    
  This raises a related 
  question.  We (like many other teams) place all of the tools used to 
  produce a product under change control so, if necessary, we can reproduce the 
  product many years after it has been released.  Is there a list of all 
  tools used to build eclipse published with each release of eclipse?  
   
    
  Thanks 
  again, 
    
  dave 
    
    
    
  
  
   
   
  From: 
  Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]  Sent: Monday, May 04, 2009 2:17 
  PM To: Russo, 
  David Cc: DSDP PMC list Subject: RE: antlr 
  CQ  
    
  Hi 
  Dave, 
    
  after a 
  little thought, I think you should apply for ANTLR runtime 
  only. 
    
  I find 
  it quite natural that non-EPL tools are required for building some software: 
  just think about compilers for the DLL's / sharedlibs (MS devstudio, gcc, 
  make), CM tools (subversion), build tools (ant). It's not unexpected IMO that 
  the build instructions for RTSC include instructions where to get and how to 
  install the full ANTLR from some 3rd party source. Since you're not going to 
  ship the ANTLR tools, nobody will care whether they are under EPL or 
  not. 
    
  At the 
  same time, you should probably think about committing the ANTRL-compiled 
  grammars into CVS/SVN -- basically the counterpart of committing precompiled 
  DLL's / sharedlibs into CVS like the Platform team 
  does. 
    
  Does 
  that help? 
  
  Cheers, 
  -- 
  Martin Oberhuber, Senior Member of 
  Technical Staff, Wind 
  River 
  Target Management 
  Project Lead, DSDP PMC Member 
  http://www.eclipse.org/dsdp/tm 
    
  
  
      
    
     
     
    From: 
    Russo, David [mailto:d-russo@xxxxxx]  Sent: Montag, 04. Mai 2009 
    23:03 To: Oberhuber, 
    Martin Subject: RE: antlr 
    CQ 
    I 
    believe it only covers the ANTLR runtime not the tool itself: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3270. 
      
      
    
    
    From: 
    Oberhuber, Martin [mailto:Martin.Oberhuber@xxxxxxxxxxxxx]  Sent: Monday, May 04, 2009 1:59 
    PM To: Russo, 
    David Subject: RE: antlr 
    CQ  
      
    Did 
    you check ipzilla whether any version of antlr has been approved 
    already? 
    I seem 
    to remember that older versions were deemed not to be EPL compatible whereas 
    a newer one (antlr 3.1 ??) was approved. 
    
    Cheers, 
    -- 
    Martin Oberhuber, Senior Member 
    of Technical Staff, Wind 
    River 
    Target 
    Management Project Lead, DSDP PMC Member 
    http://www.eclipse.org/dsdp/tm 
      
    
    
        
      
      From: 
      Russo, David [mailto:d-russo@xxxxxx]  Sent: Montag, 04. Mai 2009 
      22:55 To: Oberhuber, 
      Martin Cc: Russo, 
      David Subject: antlr 
      CQ 
      Martin, 
        
      I have a "judgment call" 
      question I'd like your opinion on.   
        
      Background 
      As you probably know, the RTSC 
      IDL is implemented using and ANTLR grammar.  In addition, in order to 
      ensure RTSC build tooling is regularly tested with "real use", we use RTSC 
      to re-build the RTSC tools.  For the RTSC team there is little 
      difference between  
      ·   what 
      is required to build RTSC 
      and  
      ·   what 
      is required to use RTSC 
      (except for the target C compilers of course).  
        
      During the IP review of the 
      XDCtools, we have a pre-requisite dependency on ANTLR.  Other 
      projects only require the ANTLR runtime; i.e., a subset of the ANTLR 
      distribution sufficient to use an ANTLR generated grammar.  But, in 
      order to re-build the RTSC project's tools from source, more than the 
      runtime is required; the ANTLR tool itself must be used to "compile" the 
      supplied grammar.  Since we currently use RTSC tools to build RTSC's 
      tools we currently distribute more than just the runtime - we distribute 
      an unmodified antlr.jar that contains both the runtime and the ANTLR 
      tool.  However, like other projects, to _use_ RTSC tools only the 
      runtime is required. 
        
      Question 
      Should I request an IP review 
      of the _entire_ ANTLR 
      package (tool and runtime) so that RTSC can re-build RTCS without 
      additional installation steps ("get the full antlr jar with the right 
      version and copy … then modify …."),  
        
      Considerations 
      Re-building RTSC is obviously 
      low on most peoples list of priorities so if it's complicated it may not 
      be a big deal.  Moreover, I don't want to "rock the boat" by 
      insisting on something we can work around.  On the other hand, 
      re-distributing the unmodified antlr.jar from antlr.org ensures that the 
      right version of the ANTLR tool is always available and no additional 
      installation steps are required to rebuild the IDL (in case someone want's 
      to quickly try a change/addition to the 
      Grammar). 
        
      From an ease of use point of 
      view, I'd much prefer to distribute the complete ANTLR.  From an 
      eclipse community member point of view, I don't want to unnecessarily 
      burden others with work just for my convenience.  Any comments or 
      perspectives would be appreciated. 
        
      Thanks 
        
      dave 
            
 |