Nowhere in that was the sources jar mentioned - yet you seemed to have jumped directly to a solution and then said can’t be done. There is a critical need for this inside businesses as well as Debian (how do we know that "org.foobar:baz:1.2.3:jar" is MIT as it claims and doesn’t contain some GPL Code. This would not to be to rebuild everything (alla JBoss of old) - but to validate that what is being used is infact what we think it is. This reasons for this are (not limited to) 1) make sure the code is not tainted and its licence is what it purports to be. 2) should the licence allow and the need arise you can have a reasonable chance of getting to that source and being able to patch it.
The end system could use the POM as a starting point to identify a project and source (not -sources.jar but svn/git repo...), and as such could contribute this to a database, that can be augmented/checked by a human and consumed by other tools. Right now for example if you looked at some artifacts on Central you would find stuff without any sources, or any indication from the POM. Whilst the automatic tooling would not help here - the fact that this would likely need a lookup in a db means at least someone could then record that GAV X is (or appears to be from) from source repo Y at version Z. /James > -----Original Message----- > From: Benson Margulies [mailto:[email protected]] > Sent: 26 February 2014 13:20 > To: Maven Users List > Subject: Re: Google Summer of Code - Java opportunity, mentors needed > > I don't believe that this is a viable scheme. > > Maven source artifacts are not generally buildable, but are aimed at IDEs for > debugging visibility. You can't trust the SVM info, and you don't know what - > P/-D options were used to make the binary. We would need a new train of > metadata. This will only lead to more of the horrible pattern of distro people > mis-building Maven and Maven artifacts, leading to confused users and bug > reports when they expect these things to work right. Maven was not > designed to facilitate the Debian pattern. If someone wants to move in that > direction, they should join the dev community, watch for work on Maven 4, > and advocate (and volunteer to code) solutions to provide the right > metadata to do this. Thowing an inexperienced student into trying to do this > with Maven 3 in a summer is a recipe for failure. > > On Tue, Feb 25, 2014 at 4:48 AM, Daniel Pocock <[email protected]> > wrote: > > > > > > Hi, > > > > I recently published an idea for discovering the source code of Java > > projects (e.g. by exploring meta data from pom.xml) and trying to > > automatically and recursively build dependencies (including plugins) > > from source > > > > > https://wiki.debian.org/SummerOfCode2014/Projects#SummerOfCode2014. > 2FP > > > rojects.2FRecursively_building_Java_dependencies_from_source.Recursive > > ly_building_Java_dependencies_from_source > > > > This would satisfy various objectives, for example: > > > > - automated construction of Debian/Ubuntu/RPM packages > > - ensuring that non-free components don't creep into the dependency > > tree of projects that aim to be published under a free license > > - ensuring that 100% of dependency code can be passed through code > > quality/security scanning tools (this is a common requirement for > > larger corporations when evaluating whether to use a free software > > project) > > > > I have some plans for how this project could be broken down into > > achievable tasks for a GSoC student but to go ahead it would need at > > least one additional mentor, mainly because Google has accepted the > > Ganglia organisation this year and I am one of the admins for Ganglia. > > The project has been proposed under Debian (mainly as a way of > > enabling the creation of more Debian packages) but it could also be > > completed under another organisation. Please feel free to email me > > privately if you may be interested. > > > > Regards, > > > > Daniel > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
