Re: [GSoC] Status Reoprt: Java Project Dependency Builder
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 <ebourg@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-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] 539789C9.3090507@apache.org">https://lists.debian.org/[🔎] 539789C9.3090507@apache.org
>
Reply to: