You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Daniel Pocock <da...@pocock.com.au> on 2014/02/25 10:48:06 UTC
Google Summer of Code - Java opportunity, mentors needed
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.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Google Summer of Code - Java opportunity, mentors needed
Posted by Martin Gainty <mg...@hotmail.com>.
> From: tamas@cservenak.net
> Date: Wed, 26 Feb 2014 12:26:48 +0100
> Subject: Re: Google Summer of Code - Java opportunity, mentors needed
> To: users@maven.apache.org
>
> While Benson is right about -source artifacts (not meant for rebuilding),
> this resembles me to M2E's "Project
>Materialisation", where based on POM of
> the given project (is fetched during dependency resolution), and IF the SCM
> metadata are okay, etc, the project tag is checked out into workspace....
>
MG>In which case we would need a standard way for SCM Metadata / Project Tag checked out into IDE:
MG>Eclipse?
MG>Idea?
MG>NetBeans?
>
MG>Concrete Example I need this nexus-plugin to work:
MG>2014-02-04 0 8:41:18 WARN [pxpool-1-thread-2] admin org.sonatype.scheduling.DefaultScheduledTask - Excein in call method of scheduled task Closing staging repositories: [stagingprofileformartinplugin-1002]
java.lang.IllegalStateException: No rule evaluator configured for type: MartinPluginRuleType
at com.google.common.base.Preconditions.checkState(Preconditions.java:176) ~[guava-14.0.1.jar:na]
at com.sonatype.nexus.staging.internal.rules.DefaultStagingRuleFactory.createStagingRule(DefaultStagingRuleFactory.java:90) ~[na:na]
at com.sonatype.nexus.staging.internal.StagingRulesHelper.evaluateRuleSet(StagingRulesHelper.java:216) ~[na:na]
at com.sonatype.nexus.staging.internal.StagingRulesHelper.evaluateProfileRuleSets(StagingRulesHelper.java:133) ~[na:na]
at com.sonatype.nexus.staging.internal.StagingRulesHelper.evaluate(StagingRulesHelper.java:104) ~[na:na]
at com.sonatype.nexus.staging.internal.task.RepositoryCloseTask$CloseOperation.verifyItem(RepositoryCloseTask.java:90) ~[na:na]
at com.sonatype.nexus.staging.internal.task.RepositoryCloseTask$CloseOperation.verifyItem(RepositoryCloseTask.java:1) ~[na:na]
at com.sonatype.nexus.staging.internal.task.OperationTaskSupport$OperationSupport.verify(OperationTaskSupport.java:295) ~[na:na]
at com.sonatype.nexus.staging.internal.task.OperationTaskSupport.executeOperations(OperationTaskSupport.java:426) ~[na:na]
at com.sonatype.nexus.staging.internal.task.OperationTaskSupport.doCall(OperationTaskSupport.java:416) ~[na:na]
at com.sonatype.nexus.staging.internal.task.TaskSupport.call(TaskSupport.java:38) ~[na:na]
at com.sonatype.nexus.staging.internal.task.StagingTaskSupport.call(StagingTaskSupport.java:134) ~[na:na]
at com.sonatype.nexus.staging.internal.task.StagingBackgroundTask.execute(StagingBackgroundTask.java:68) ~[na:na]
at com.sonatype.nexus.staging.internal.task.NexusTaskSupport.doRun(NexusTaskSupport.java:53) ~[na:na]
at com.sonatype.nexus.staging.internal.task.NexusTaskSupport.doRun(NexusTaskSupport.java:1) ~[na:na]
at org.sonatype.nexus.scheduling.AbstractNexusTask.call(AbstractNexusTask.java:157) ~[nexus-core-2.7.2-03.jar:2.7.2-03]
at org.sonatype.scheduling.DefaultScheduledTask.call(DefaultScheduledTask.java:419) ~[nexus-scheduler-2.7.2-03.jar:2.7.2-03]
at org.sonatype.nexus.threads.MDCAwareCallable.call(MDCAwareCallable.java:45) ~[nexus-core-2.7.2-03.jar:2.7.2-03]
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) ~[shiro-core-1.2.2.jar:1.2.2]
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) ~[shiro-core-1.2.2.jar:1.2.2]
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.FutureTask.run(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) ~[na:1.7.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) ~[na:1.7.0_25]
at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_25]
MG>Q1: Can I get Sonatype source code to debug Nexus?
MG>Q2: Could I use maven-to-idea-plugin to pull source into IDEA ?
MG>Q3: Should I care about -P -D options or is this not appropriate use of Profile/SystemProperty?
MG>I am thinking I will need Maven-4 to solve this problem
>
> On Wed, Feb 26, 2014 at 12:20 PM, Benson Margulies <bi...@gmail.com>wrote:
>
> > 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 <da...@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.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Tamás Cservenák <ta...@cservenak.net>.
While Benson is right about -source artifacts (not meant for rebuilding),
this resembles me to M2E's "Project Materialisation", where based on POM of
the given project (is fetched during dependency resolution), and IF the SCM
metadata are okay, etc, the project tag is checked out into workspace....
On Wed, Feb 26, 2014 at 12:20 PM, Benson Margulies <bi...@gmail.com>wrote:
> 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 <da...@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.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Daniel Pocock <da...@pocock.com.au>.
On 26/02/14 17:17, James Nord (jnord) 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/>
>
> My mistake, sorry.
>
>>> 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 shouldn't prohibit something using what exists now.
>
> One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated.
>
Just to clarify some aspects of this:
- there is no expectation that the project will build 100% of artifacts
that are available in the Central Repository - just being able to build
20% of them would still be helpful
- it is expected that some projects will need manual clues to build -
for example, if some project contains two binary JARs in github, and if
they don't have clues about where to find source, the system will
display a report (including the names of classes in the JARs) and the
user will be able to tell it where to look and then the automated stuff
continues. It will always keep trying to go as far as it can
automatically and then display a list of all things that need manual
help so the user can address them all in a batch.
- I wasn't anticipating a dependency on -source JARs, although the
toolkit that I am proposing may well try to build from them if it has
nothing else (but without any expectation that they will build)
- automatically submitting the packages to Debian is probably out of the
question for now. However, the feedback from such a system would make
it much easier for a Debian user to create packages in their local
repository. It would also make it easier for Debian Developers (or
Ubuntu or Fedora developers) to look at bigger Java projects with
multiple JARs and decide if they are suitable for official uploads to a
distribution. It would do some of the leg work for us (stripping out
binary artifacts and building the re-packaged source tarballs that we
need sometimes) and then we would still put in the finishing touches
manually to make a package that is official.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Daniel Pocock <da...@pocock.com.au>.
On 05/03/14 14:20, Martin Gainty wrote:
>
>
>
>
>> From: waynefay@gmail.com
>> Date: Tue, 4 Mar 2014 22:12:20 -0600
>> Subject: Re: Google Summer of Code - Java opportunity, mentors needed
>> To: users@maven.apache.org
>>
>>> When you call this GSOC, are you looking to sponsor a student within
>>> the Apache Maven project? I don't think that this is viable. If you
>>> have some other sponsoring organization and an intention to manage it
>>> elsewhere, then I wish you luck but I have no standing to object.
>>
>> Benson, scroll back and read the original message, he stated...
>>
> MG>the assumption of a mentor is that someone somewhere will be tasked to train this individual
Unfortunately, that is not a good assumption
The best GSoC applicants are already involved in free software
development, sometimes even doing paid work in an IT department that
overlaps with their GSoC project
In this case, the mentor is not training them, rather, the mentor's
biggest responsibilities are:
a) looking for such good candidates
b) helping them set sensible goals that can be completed within 8-10 weeks
c) reviewing their progress
d) providing resources (e.g. access to build servers)
> MG>and since this is a GSOC Project the assumption is the mentor position will be uncompensated
> MG>The other assumption is that the person being mentored is a student
> MG>Because they have trained for free in the past anyone who is assumed to be tagged with an additional responsibility of MG>training this <PersonWhoNeedsToBeTrained> has a right to raise objections...
> MG>Assuming the mentor will work for free uncompensated to train others is not a safe assumption
This whole "uncompensated" emphasis is very biased
People distribute software "uncompensated". Linux is an example.
You can go and use WhatsApp without paying them anything to send a
message, their company was valued at $16 billion despite the fact they
are "uncompensated" by their users.
Typically, mentors are not getting cash paid by the hour, getting some
kind of value in-kind:
- the mentor has no time or budget to complete some optional piece of
work on their own, like improving their tools, it wouldn't get done
otherwise
- the student is an extra tester for the project and related tools that
are of interest to the mentor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Google Summer of Code - Java opportunity, mentors needed
Posted by Martin Gainty <mg...@hotmail.com>.
> From: waynefay@gmail.com
> Date: Tue, 4 Mar 2014 22:12:20 -0600
> Subject: Re: Google Summer of Code - Java opportunity, mentors needed
> To: users@maven.apache.org
>
> > When you call this GSOC, are you looking to sponsor a student within
> > the Apache Maven project? I don't think that this is viable. If you
> > have some other sponsoring organization and an intention to manage it
> > elsewhere, then I wish you luck but I have no standing to object.
>
> Benson, scroll back and read the original message, he stated...
>
MG>the assumption of a mentor is that someone somewhere will be tasked to train this individual
MG>and since this is a GSOC Project the assumption is the mentor position will be uncompensated
MG>The other assumption is that the person being mentored is a student
MG>Because they have trained for free in the past anyone who is assumed to be tagged with an additional responsibility of MG>training this <PersonWhoNeedsToBeTrained> has a right to raise objections...
MG>Assuming the mentor will work for free uncompensated to train others is not a safe assumption
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Benson Margulies <bi...@gmail.com>.
On Wed, Mar 5, 2014 at 6:12 AM, Wayne Fay <wa...@gmail.com> wrote:
>> When you call this GSOC, are you looking to sponsor a student within
>> the Apache Maven project? I don't think that this is viable. If you
>> have some other sponsoring organization and an intention to manage it
>> elsewhere, then I wish you luck but I have no standing to object.
>
> Benson, scroll back and read the original message, he stated...
OK, apologies.
>
>>> 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
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Wayne Fay <wa...@gmail.com>.
> When you call this GSOC, are you looking to sponsor a student within
> the Apache Maven project? I don't think that this is viable. If you
> have some other sponsoring organization and an intention to manage it
> elsewhere, then I wish you luck but I have no standing to object.
Benson, scroll back and read the original message, he stated...
>> 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
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Benson Margulies <bi...@gmail.com>.
When you call this GSOC, are you looking to sponsor a student within
the Apache Maven project? I don't think that this is viable. If you
have some other sponsoring organization and an intention to manage it
elsewhere, then I wish you luck but I have no standing to object.
On Mon, Mar 3, 2014 at 2:44 PM, Daniel Pocock <da...@pocock.pro> wrote:
> On 27/02/14 02:21, Martin Gainty wrote:
>>
>>
>>
>>> From: jnord@cisco.com
>>> To: users@maven.apache.org
>>> Subject: RE: Google Summer of Code - Java opportunity, mentors needed
>>> Date: Wed, 26 Feb 2014 16:17:29 +0000
>>>
>>>>> 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/>
>>> My mistake, sorry.
>>>
>>>>> 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 shouldn't prohibit something using what exists now.
>>>
>>> One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated.
>> MG>How will the aggrgeator mechanism aggreate for this subset of artifacts
>> MG>Scope?
>> MG>Classifier?
>>
>> MG>With regards to GPLartifacts could'nt we find the necessary violations with Sonatype CLM
>> MG>(No plug for Sonatype intended)
>
>
> I've put up more details of how this project could be broken down into
> discrete tasks:
>
> http://danielpocock.com/automatically-and-recursively-building-java-projects
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Daniel Pocock <da...@pocock.pro>.
On 27/02/14 02:21, Martin Gainty wrote:
>
>
>
>> From: jnord@cisco.com
>> To: users@maven.apache.org
>> Subject: RE: Google Summer of Code - Java opportunity, mentors needed
>> Date: Wed, 26 Feb 2014 16:17:29 +0000
>>
>>>> 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/>
>> My mistake, sorry.
>>
>>>> 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 shouldn't prohibit something using what exists now.
>>
>> One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated.
> MG>How will the aggrgeator mechanism aggreate for this subset of artifacts
> MG>Scope?
> MG>Classifier?
>
> MG>With regards to GPLartifacts could'nt we find the necessary violations with Sonatype CLM
> MG>(No plug for Sonatype intended)
I've put up more details of how this project could be broken down into
discrete tasks:
http://danielpocock.com/automatically-and-recursively-building-java-projects
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Google Summer of Code - Java opportunity, mentors needed
Posted by Martin Gainty <mg...@hotmail.com>.
> From: jnord@cisco.com
> To: users@maven.apache.org
> Subject: RE: Google Summer of Code - Java opportunity, mentors needed
> Date: Wed, 26 Feb 2014 16:17:29 +0000
>
> > > 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/>
>
> My mistake, sorry.
>
> > > 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 shouldn't prohibit something using what exists now.
>
> One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated.
MG>How will the aggrgeator mechanism aggreate for this subset of artifacts
MG>Scope?
MG>Classifier?
MG>With regards to GPLartifacts could'nt we find the necessary violations with Sonatype CLM
MG>(No plug for Sonatype intended)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
RE: Google Summer of Code - Java opportunity, mentors needed
Posted by "James Nord (jnord)" <jn...@cisco.com>.
> > 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/>
My mistake, sorry.
> > 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 shouldn't prohibit something using what exists now.
One commercial company has done something for some subset of artifacts - which may have been entirely human process/mixed or automated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Benson Margulies <bi...@gmail.com>.
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:bimargulies@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 <da...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Google Summer of Code - Java opportunity, mentors needed
Posted by "James Nord (jnord)" <jn...@cisco.com>.
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:bimargulies@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 <da...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Google Summer of Code - Java opportunity, mentors needed
Posted by Benson Margulies <bi...@gmail.com>.
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 <da...@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.2FProjects.2FRecursively_building_Java_dependencies_from_source.Recursively_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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org