maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Source code verification/compliance with Maven?
Date Thu, 09 May 2013 09:44:56 GMT
On 9 May 2013 10:15, Daniel Pocock <daniel@pocock.com.au> wrote:

>
> Hi,
>
> There is a lot of confusion about the distinction between software that
> is free (like malware in app stores) and software that is really free
> with open source code.
>
> Several people have asked me how they can be sure that a Maven build
> (including all downloaded plugins) only uses genuine open source
> software, and that the binary downloads are identical to the source
> releases.  There are many users that want to build projects from source
> code in clean, non-networked environments.
>
> How can somebody tell Maven to
> a) recursively download source JARs for all plugins and dependencies
> (and their build plugins) and compile them one by one?
>

1. source jars are not designed to be compilable into the build artifact,
they are designed to be a resource for IDEs to allow debugging and code
inspection.

Did you know that Apache does not actually release binaries?

Apache only releases source bundles. So for Maven the actual release bits
are the Source.zip and Source.tar.gz bundles. e.g.

http://repo1.maven.org/maven2/org/apache/maven/apache-maven/3.0.5/apache-maven-3.0.5-src.zip

The binary builds of those things are only a convenience that we provide
for users. But our actual release votes are on the -src.zip or the tag in
SCM

2. There is no guarantee that an artifact in a Maven repository was put
there by Maven. There are multiple toolchains that now publish to Maven
repositories, so how is Maven to know how to build those artifacts, there
may only be a stub pom that lists their transitive dependencies.

3. Maven Shade Plugin means that the -source.jar may not produce the same
classes as in the .jar as there may have been package renaming and
transitive dependency escalating

There is more, but these 3 points should convince you that a) is an
unrealistic goal... it is a noble goal though ;-)

b) stop if any source JAR contains binary artifacts or if a
> dependency/plugin source is not available?
>

You could write an enforce rule that validates this... it would need
exceptions for certain file types and how exactly do you determine what is
a binary file anyway? what about a i18n resource bundle with UTF-16
encoding... that will be non-ASCII... or UTF-8 without a BOM and with
mostly asian characters... how do you differentiate that? or what about
image resources / photos, etc


> c) put all downloaded source in some kind of tree where it can be tarred
> up, copied onto a DVD and then built by a machine that is offline?
>

See a) above


>
> I'm aware of the command "mvn dependency:sources", but this only appears
> to fetch the sources on a best effort basis and doesn't appear to
> compile them.
>
> Regards,
>
>
HTH

-Stephen


> Daniel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message