Hey Emmanuel, I suppose that is partly my fault. I've been trying to tackle the low hanging fruit first which when put together will become the project. My emails are probably a little lower level than they should be. And I don't think I've done a good job describing the why or inputs and outputs either. Let's see if I can rectify that.
Have you seen Daniel's blog post [1] which motivates the idea of the project? It can basically be summarized to identifying free software. The project aids this process by checking all the dependencies where it could be easy to hide, forget, not know, etc. that a project is "free". The project makes this assumption by being able to build the dependencies from their source which can either be from the scm information in an artifacts metadata or attempt to be reconstructed by the -sources.jar which most projects in maven-central have. This could mostly be achieved without actually building the projects, but there is another purpose of the project. Daniel found that one such avenue of getting artifacts onto central involves just uploading a signed jar [1] which gives rise of the possibility of non-free software getting into central. By building the dependencies we show that a project has no such non-free parts. The tool is being implemented as a maven plugin. So, you should be able to run a command such as mvn dependency-builder-maven-plugin:build-dependencies -Dartifact=junit:junit:4.11 and have the tool build junit 4.11 as well as hamcrest-core (a dependency of junit) from their source repositories. It will also ensure that junit will be able to be built using the hamcrest-core jar that we built as opposed to the one in central. The output of the plugin will consist of 3 things: a report what was built, where, how, etc., a folder containing all the artifacts that were built (in maven repository format) and a handful of git repositories for tracking the source that was built. Initially, the plugin will die out if there are dependencies which it needs but hasn't yet built, i.e. building junit, but you didn't build hamcrest yet, but I am hoping to support a fully synchronous workflow if time permits. Since the output maven repository and checkout directory will be configurable, it will be easy to chain together multiple executions with different artifacts. When using the plugin in a CI environment such as Jenkins, you could, for example, create builds per artifact and use the report to create new builds of projects you have yet to track. Obviously this goes beyond the plugin, but shouldn't be too difficult to configure using post build steps. There will be some projects which will not be as simple as the example given above in which case there will be a few more configuration options to set, but the outcome should be the same. My vision involves either pom configuration or a few flat file databases, but a bit more thought needs to be put into it There are also a few nice to haves which may be implemented, time permitting, which includes building a local maven project as opposed to one which exists first in central (or your local repo) and deploying artifacts into a remote repository (nexus, webdav, etc.) through wagon as opposed to just a local folder. It is not expected that this tool spits out deb archives of java libraries, but it can certainly be used to aid in the process of creating a deb archive. I know I've left a few details to be filled in, but hopefully I've answered at least part of your question. Cheers, Andrew [1] http://danielpocock.com/automatically-and-recursively-building-java-projects On Tue, Jun 10, 2014 at 3:42 PM, Emmanuel Bourg <ebo...@apache.org> wrote: > Hi Andrew, > > I'm reading your mails but I have a hard time understanding what you are > trying to achieve and how this could help the packaging of Java > applications. Assuming your tool is complete, do you have some examples > showing how it would be used? > > Emmanuel Bourg > > > -- > 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/539789c9.3090...@apache.org > -- 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/cags-l4ulxm4n_btoyhypfp5og9a0ryvmj8d2qfjnjacv307...@mail.gmail.com
