On Wed, Feb 26, 2014 at 9:16 AM, James Nord (jnord) <jn...@cisco.com> wrote: > 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.
No, I discussed the two paths from the POM: -sources and <scm/> > > 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. Which is a fine reason to contribute it Maven 4 where the POM could contain the necessary metadata to enable it. > 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:bimargul...@gmail.com] >> 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 <dan...@pocock.com.au> >> 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: 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
