On 09/05/13 17:21, Manfred Moser wrote: > Correct. The other thing you want to ensure is your acquisition of the > jar. With Nexus (and other repo managers probably) you can connect to the > https secured version of Central and enforce checksum verification so you > can be sure that any component you get into the repo manager is the same > as upstream. Authenticity of the binary is just one element in the big picture though. The requirement I have involves various factors, some of which appear to be addressed by CLM.
- some plugin that is essential to the build process is only available in binary format. The developer has put a time restriction on the binary (e.g. it stops working in 2014) as they plan to start charging money for it in future, but no user is aware of this restriction until it's too late. - a user wants to run their own on-site code analysis tool, and as the quality of the tool improves, they want to re-run it over all their open source code from time to time as well - a user stresses a particular part of the code that has never been used in anger before, and they need to profile and optimize that code with some tools that require an original source tree As I see it, CLM may provide the foundation for addressing these concerns (e.g. by making sure that all components provide sources), but the most prudent users still potentially need a convenient way to repeat the build(s) locally on demand in a clean, offline environment. Does Sonatype offer a public CLM demo of some multi-component open source project, e.g. to show how CLM reports on Eclipse and perhaps some application server like Apache ServiceMix? The other thing that caught my attention is the Maven SCM capability, and the <scm/> element in pom.xml - is this only used for making tags after a build? Or does any tool use this information to recursively check-out and build dependency projects? In Stephen's earlier reply, he commented on the difficulty of recognizing embedded code (e.g. class files or JARs). I don't think this is as bad as it sounds though: a quick check of the signature of a file is enough to determine if it is a PNG or a JAR or something unknown. A recursive scan of sources would probably classify each of those artifacts for a different action. e.g. *.png could be whitelisted, while source repositories that keep binary copies of some build tools would generate an alert for manual attention. > This avoid the problem of building from source as you suggest since this > is very often extremely difficult (just as the Debian folks or other Linux > distros that try to rebuild everything from sources.. its a HUGE task). I am one of those Debian folks and I do provide all my own packages in a manner that enables people to repeat the build, add patches, etc in a very uniform manner - although bringing Maven-based projects into Debian wasn't the reason for my query in this instance. > Sonatype CLM includes integration with Nexus, Eclipse IDE and > Jenkins/Hudson as well as a backend server to define rules and more. > > manfred > > PS: Disclaimer I work with Sonatype on their documentation .. > > >> Well, I know that Sonatype has a product they have been pretty aggressive >> with called CLM. >> >> CLM shows both vulnerabilities and license threats -- including undefined >> licenses... Perhaps that is what you need? >> >> >> Thanks, >> >> Roy Lyons >> >> >> >> >> >> On 5/9/13 4:15 AM, "Daniel Pocock" <dan...@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? >>> b) stop if any source JAR contains binary artifacts or if a >>> dependency/plugin source is not available? >>> 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? >>> >>> 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, >>> >>> Daniel >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
