| I'm moving this discussion out of the initial contribution CQ... 
 This sort of conversation is generally appropriate for a "dev" list
    in my world. I'm assuming that it is appropriate discussion for the
    udig-devel list as well. Please correct me if I'm wrong.
 
 I've copied the following discussion out of the CQ and have offered
    some replies inline.
 
 
 
      
      
    The devel/ directory contains some "installer" bits that appear to
    be NullSoft installer-specific. This potentially makes the NullSoft
    installer a third-party dependency that is subject to the IP Due
    Diligence process. I'm not sure about whether or not the
    distribution license is acceptable. This will require some
    additional investigation. 
 If the intent is just to provide scripts that can be used to
    generate the installer, but not actually distribute the results,
    then we may be able to get away with a "works with" CQ (see
    discussion below). If the intent is to distribute the installer,
    then we have some work to do.
 
 
      
    If it's not required, then it should be removed from the initial
    contribution. By virtue of it being a JAR, I believe that Sharon has
    already removed it. 
 
      
    What is lib/scala-csw-client ? Is it project code? Is it distributed
    with uDig builds? 
 
      
    Should we pull the tutorial source as well, or would you rather keep
    it with the project? 
 Perhaps the tutorial can remain on GitHub.
 
 FWIW, some work has been done on jai_imageio, but there was some
    problematic code. At some point--should you choose to pursue it--we
    can just open a CQ and get IP team to help us sort out what needs to
    be done.
 
 
      
    Version 1.2.13 and 1.2.15 are both approved. Can you just update to
    one of those versions? 
 
      
    I assume that you mean that these are placeholders for third party
    JARs that may or may not be present. If a third party library may be
    leveraged if it is present but the project is otherwise functional
    without that library, you'd need a "works with" CQ. 
 These are described in the Third party libraries policy:
 
 http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
 
 The short version is the the project's PMC needs to discuss and
    approve the "works with" use in a public forum (normally the PMC
    mailing list) and unanimously decide that the use is reasonable
    before approving the CQ.
 
 
      
    The policy is that you need a CQ for each third-party JAR directly
    used by the project or by any other third-party JAR. If the JAR is
    inherited through another Eclipse or LocationTech project, but is
    not directly used by uDig, then you don't require a CQ. Hamcrest
    tends to included by virtue of making direct use of JUnit. In this
    case, you would require a CQ, because your test code makes direct
    use of JUnit (a third-party library). If uDig instead had a indirect
    dependency on Hamcrest by virtue of a direct dependency on the
    org.eclipse.platform bundle (a completely made-up example), then you
    wouldn't need to the CQ. Make sense? 
 
      
    I expect that this falls under the "works with" discussion above. 
 
      
     "Works with" ?
 
 
      
    A "piggyback" CQ is needed if you're directly accessing the
    libraries. CQ 1537 covers iText 1.45.2 and CQ 3475 covers iText
    2.1.7. 
 
      
    i.e. they are not required? 
 
      
    They look like p2 artifacts. Frank suggested (on the CQ) that a
    .gitignore entry should be created for these. 
 
      
    Is there any related code that can also be removed? Anything that we
    can take off the IP team's plate will make the approval process run
    faster. 
 Feel free to carve this up into separate threads as appropriate.
 
 Wayne
 
 
 |