JSPWiki
  1. JSPWiki
  2. JSPWIKI-738

Dependencies should not be distributed with source archive

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Graduating, 2.9
    • Fix Version/s: Graduating, 2.9
    • Component/s: None
    • Labels:
      None

      Description

      As pointed out in the revision of the July 2012 incubation report, JSPWiki ships binary dependencies in the source archive, which is contrary to Apache principles.

      As we are downloading some dependencies in current trunk, I would take the path of downloading all needed jars.

        Activity

        Hide
        Florian Holeczek added a comment -

        Closing this, since 2.9 has been released

        Show
        Florian Holeczek added a comment - Closing this, since 2.9 has been released
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Hello Florian,

        there are several things to note:

        The download mechanism: it was introduced because having external jars in the source code is considered against Apache principles, which was noted in the follow-up of the July status report. Keeping the jars in libs tests/libs will most probably be a blocker for IPMC.

        The growing libs directory: I'm thinking we could avoid that problem by directly download them from Central, except for sandler and freshcookies-security, which are not available there.

        maven ant tasks: to introduce cobertura and sonar support we needed some (L)GPL jars, which we couldn't have in our SVN repository, hence the mechanism to download them. I was thinking of downloading all dependencies via these tasks, but as sandler and freshcookies-security are not published on central, so may be we could just download the needed jars from central and get rid off these tasks. Thoughts?

        Show
        Juan Pablo Santos Rodríguez added a comment - Hello Florian, there are several things to note: The download mechanism: it was introduced because having external jars in the source code is considered against Apache principles, which was noted in the follow-up of the July status report . Keeping the jars in libs tests/libs will most probably be a blocker for IPMC. The growing libs directory: I'm thinking we could avoid that problem by directly download them from Central, except for sandler and freshcookies-security, which are not available there. maven ant tasks: to introduce cobertura and sonar support we needed some (L)GPL jars, which we couldn't have in our SVN repository, hence the mechanism to download them. I was thinking of downloading all dependencies via these tasks, but as sandler and freshcookies-security are not published on central, so may be we could just download the needed jars from central and get rid off these tasks. Thoughts?
        Hide
        Florian Holeczek added a comment -

        Juan Pablo, I have some questions and thoughts on the currently implemented solution:

        What is the exact requirement and where is it documented at ASF?
        IMO we're dealing with two aspects here:

        • (binary) dependencies in the source artifact
        • dependency handling in the project

        Taking the title, "Dependencies should not be distributed with source archive", as the requirement, wouldn't it be enough to simply exclude the libs from being added to the ZIP file?

        Regarding dependency management: Is there a reason for not leaving the libs under libs and test/libs in the trunk, branch, etc.? With the current solution, we will have a growing libs directory on the top level, since we still need all older versions in there in order to be able to still build older versions.

        Show
        Florian Holeczek added a comment - Juan Pablo, I have some questions and thoughts on the currently implemented solution: What is the exact requirement and where is it documented at ASF? IMO we're dealing with two aspects here: (binary) dependencies in the source artifact dependency handling in the project Taking the title, "Dependencies should not be distributed with source archive", as the requirement, wouldn't it be enough to simply exclude the libs from being added to the ZIP file? Regarding dependency management: Is there a reason for not leaving the libs under libs and test/libs in the trunk, branch, etc.? With the current solution, we will have a growing libs directory on the top level, since we still need all older versions in there in order to be able to still build older versions.
        Hide
        Janne Jalkanen added a comment -

        We're currently doing something like this: first have a pom.xml with the dependencies (which will include transitive stuff) and then in the build.xml have something like this:

         
        <!--
                   Maven ant tasks
          -->
        
        <property name="mvn.jar.dir" value="${user.home}/.ant"/>
        <target name="download-mvn">
            <mkdir dir="${mvn.jar.dir}"/>
            <get src="http://www.nic.funet.fi/pub/mirrors/apache.org/maven/binaries/maven-ant-tasks-2.1.3.jar " dest="${mvn.jar.dir}" usetimestamp="true" skipexisting="true" />
        </target>
        
        <target name="init-mvn" depends="download-mvn" unless="mvn.init.called">
            <path id="maven-ant-tasks.classpath" path="${mvn.jar.dir}/maven-ant-tasks-2.1.3.jar" />
            <typedef resource="org/apache/maven/artifact/ant/antlib.xml"
                         uri="antlib:org.apache.maven.artifact.ant"
                         classpathref="maven-ant-tasks.classpath" />
            <artifact:pom id="pom" file="pom.xml" />
            <artifact:dependencies filesetId="mvn.fileset" pathId="mvn.classpath" pomRefId="pom" scopes="provided,compile"/>
            <property name="mvn.init.called" value="true" />
        </target>
        
        
        Show
        Janne Jalkanen added a comment - We're currently doing something like this: first have a pom.xml with the dependencies (which will include transitive stuff) and then in the build.xml have something like this: <!-- Maven ant tasks --> <property name= "mvn.jar.dir" value= "${user.home}/.ant" /> <target name= "download-mvn" > <mkdir dir= "${mvn.jar.dir}" /> <get src= "http://www.nic.funet.fi/pub/mirrors/apache.org/maven/binaries/maven-ant-tasks-2.1.3.jar " dest= "${mvn.jar.dir}" usetimestamp= "true" skipexisting= "true" /> </target> <target name= "init-mvn" depends= "download-mvn" unless= "mvn.init.called" > <path id= "maven-ant-tasks.classpath" path= "${mvn.jar.dir}/maven-ant-tasks-2.1.3.jar" /> <typedef resource= "org/apache/maven/artifact/ant/antlib.xml" uri= "antlib:org.apache.maven.artifact.ant" classpathref= "maven-ant-tasks.classpath" /> <artifact:pom id= "pom" file= "pom.xml" /> <artifact:dependencies filesetId= "mvn.fileset" pathId= "mvn.classpath" pomRefId= "pom" scopes= "provided,compile" /> <property name= "mvn.init.called" value= "true" /> </target>
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        done, both jars are properly excluded from war now.

        Regarding servlet-api, doc/Compiling.txt states a 2.4 version for servlet-api.

        I think the best we can do is upload the info on that file to the site with the proper explanations, so that information gets really visible.

        regards,
        juan pablo

        Show
        Juan Pablo Santos Rodríguez added a comment - done, both jars are properly excluded from war now. Regarding servlet-api, doc/Compiling.txt states a 2.4 version for servlet-api. I think the best we can do is upload the info on that file to the site with the proper explanations, so that information gets really visible. regards, juan pablo
        Hide
        Florian Holeczek added a comment -

        Ok, so deleting the servlet-api as well as the jsp-api JARs from WEB-INF/lib does it! These hadn't been included before either.

        Regarding the API version, I think it's only a matter of decision. If we want to keep on supporting 2.3, we should downgrade to these libraries. Otherwise, we should clearly state that 2.3 should work, but we don't support it. The Servlet and JSP APIs have always been upwards compatible yet, haven't they?

        Show
        Florian Holeczek added a comment - Ok, so deleting the servlet-api as well as the jsp-api JARs from WEB-INF/lib does it! These hadn't been included before either. Regarding the API version, I think it's only a matter of decision. If we want to keep on supporting 2.3, we should downgrade to these libraries. Otherwise, we should clearly state that 2.3 should work, but we don't support it. The Servlet and JSP APIs have always been upwards compatible yet, haven't they?
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Hallo Florian,

        I'll take a look this afternoon/tonight. Please reopen and attach relevant tomcat logs to see what's happening.

        Regarding servlet-api, we were including 2.4 although we're stating it should run on 2.3. AFAIK it deploys on tomcat 5.5, so, theorically, we could probably downgrade the servlet-api to 2.3. Haven't done tests on this, though.

        regards,
        juan pablo

        Show
        Juan Pablo Santos Rodríguez added a comment - Hallo Florian, I'll take a look this afternoon/tonight. Please reopen and attach relevant tomcat logs to see what's happening. Regarding servlet-api, we were including 2.4 although we're stating it should run on 2.3. AFAIK it deploys on tomcat 5.5, so, theorically, we could probably downgrade the servlet-api to 2.3. Haven't done tests on this, though. regards, juan pablo
        Hide
        Florian Holeczek added a comment -

        Hi Juan Pablo,

        nice work, it's building the distribution archives without any errors and without any binary libs in the source archive.

        However, I couldn't get the output up and running on my Tomcat 6 instance. There seem to be problems regarding the Servlet and/or JSP API. Deleting the servlet-api-2.4.jar from WEB-INF/lib didn't help.

        Please also note that we're saying to require a Servlet 2.3 container only so far.

        Regards
        Florian

        Show
        Florian Holeczek added a comment - Hi Juan Pablo, nice work, it's building the distribution archives without any errors and without any binary libs in the source archive. However, I couldn't get the output up and running on my Tomcat 6 instance. There seem to be problems regarding the Servlet and/or JSP API. Deleting the servlet-api-2.4.jar from WEB-INF/lib didn't help. Please also note that we're saying to require a Servlet 2.3 container only so far. Regards Florian
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        done in 2.9.0-incubating-7

        Show
        Juan Pablo Santos Rodríguez added a comment - done in 2.9.0-incubating-7
        Hide
        Juan Pablo Santos Rodríguez added a comment -

        Using maven-ant-tasks to download all the required dependencies may not be the cleanest solution for current trunk:

        • we would have to download maven-ant-tasks by other means
        • freshcookies-security jar isn't on central/apache repos, so we would have to download it by other means
        • would have to manage/configure transitive dependencies, which is easy for a Maven build, but not so when doing through maven-ant-tasks

        Following up with the JSPWiki status from July 2012 report, it seems that the easiest way would be to just download the libs from SVN, with a script similar to the Apache POI one, having in $SVN something like:

         $SVN
          + trunk
          + tags
          + branches
          + [...]
          + libs
             > main
             > test
        

        Regarding sonar & cobertura tasks, I would leave them as they are now, in order to avoid uploading LGPL libs to $SVN

        Show
        Juan Pablo Santos Rodríguez added a comment - Using maven-ant-tasks to download all the required dependencies may not be the cleanest solution for current trunk: we would have to download maven-ant-tasks by other means freshcookies-security jar isn't on central/apache repos, so we would have to download it by other means would have to manage/configure transitive dependencies, which is easy for a Maven build, but not so when doing through maven-ant-tasks Following up with the JSPWiki status from July 2012 report , it seems that the easiest way would be to just download the libs from SVN, with a script similar to the Apache POI one, having in $SVN something like: $SVN + trunk + tags + branches + [...] + libs > main > test Regarding sonar & cobertura tasks, I would leave them as they are now, in order to avoid uploading LGPL libs to $SVN

          People

          • Assignee:
            Juan Pablo Santos Rodríguez
            Reporter:
            Juan Pablo Santos Rodríguez
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development