Hi all, Andrew, congratulations on your selection for GSoC and welcome to Debian and the pkg-java group.
Some parts of the project are Java-specific (e.g. the Maven plugin) while other parts of the project are not specific to Java (e.g. stripping non-free binary artifacts from source tarballs to make what we call a "repackaged upstream source"). For those types of things that are not Java specific, you are more than welcome to discuss on the debian-devel mailing list as you will find other people are interested in the same problem. High-level strategy for this project (and all the GSoC projects) - I find the most successful approach is to break the project into discrete modules that are useful on their own and that can be completed in 1-3 weeks each. If a student's plan includes 6 modules and he completes 3 successfully and they are useful and I feel the student made a good effort then I can let that student pass. If a plan involves one mega-module and it is not finished by the deadline (11 August) and I can't see if the code is useful for anybody it may be harder for me to pass that student. What I'd like to see next is to create a separate wiki page about each potential module and link to them from the main wiki plan. For example, create a wiki page for each of these ideas: a) a module for reconstructing a buildable source tree from -source.jar files. It should: - find all versions of all source JARs and all related POM files in public mvn distribution sites - create a Git repository and put each version of the sources in the repo and commit them on top of each other (e.g. if it finds source JARs for all of versions 1.0, 1.1 and 1.2 then it should commit them all) - create any missing pom.xml files and commit these on a different branch - try to run mvn b) a module for cloning some public Git repository and creating a "free" branch where all the non-free artifacts are deleted - this module should also create some machine-readable log file about what it removed from each tag (another module will read those logs) - how does it interact with uscan? see recent discussions on debian-devel c) a Maven plugin that does the stuff discussed below (see my comments inline) d) other modules.... In our private email discussions you have demonstrated a good understand of the potential issues involved (e.g. comparing the binary JAR class lists against the published source JARs) so please include that type of detail in the wiki page for (a) The wikis will also be useful for other people to understand and contribute to this work On 25/04/14 19:05, Andrew Schurman wrote: > Greeting fellow Java hackers, > > It's that time of year again when students ease up on their studies and > help contribute to the open source community through the Google Summer > of Code. I've been selected this year to build project which could be > used to help build a java projects dependencies (and their > dependencies). The plan is to build a maven plugin to both determine the > dependencies and try to build them up taking into account different Just one comment on the scope of the maven plugin: the plugin will not be building the dependencies synchronously itself. Rather, if dependencies are not available the plugin will a) put the list of missing dependencies into some queue or table b) fail the build, with a status code that indicates it failed because of dependencies (to help us distinguish this from other types of build failure) We would then have some high level system that reads from the queue/table and creates Jenkins configs for each new dependency. > build systems/source control/etc [1]. Doing so can both confirm that a > project is truly open source and reaffirm that it is still possible to > recreate a useful binary (from scratch) which could have been created > years ago. One additional use case that may be useful for open source > projects is the ability to test a source release, if it included > multiple projects not built with a single command. > > If your project has some arcane build ritual, I encourage you to let me > know so I can take them into consideration. You maybe be able to get a list of all pkg-java projects here: http://qa.debian.org/developer.php?login=pkg-java-maintain...@lists.alioth.debian.org and try to scan them for clues about the problems we encounter with existing packages, the things that are removed in the dfsg tarballs, etc. Regards, Daniel -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/535cd559.5000...@pocock.com.au
