You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by James William Dumay <ja...@atlassian.com> on 2008/05/09 05:01:45 UTC
Donation of Maven plugins to the Maven Project.
Hey guys,
Atlassian would like to donate two plugins to the Maven project:
* maven-wagon-plugin (formerly maven-upload-plugin) - Allows you to
upload and download resources during the build lifecycle and list remote
resources.
* maven-licenses-plugin - This plugin lists, downloads and packages
license files for your projects transitive dependencies. Useful for
creating assemblies that contain licenses.
Both plugins are licensed under the Apache 2 license and have received
recent attention of the mailing list which has prompted the idea of
donation.
We are happy to change the names of these plugins if there is anyone has
better suggestions for their names.
You can find both plugins on our svn:
https://svn.atlassian.com/svn/public/atlassian/maven-plugins/
I'm sorting out the legal now with Atlassian. So, how can we get the
ball rolling? :)
Thanks,
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by James William Dumay <ja...@atlassian.com>.
>>
> I didn't even see the commit until after my first reply (for some
> reason it appeared in my mailbox late), and I've had no discussion
> with James about this that you haven't seen. I was kind of surprised
> too, and I think it was just a miscommunication.
>
I would like to apologise for the miscommunication - I will see that
this is correctly sorted out.
James>>
> I didn't even see the commit until after my first reply (for some
> reason it appeared in my mailbox late), and I've had no discussion
> with James about this that you haven't seen. I was kind of surprised
> too, and I think it was just a miscommunication.
>
I would like to apologise for the miscommunication - I will see that
this is correctly sorted out.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Brett Porter <br...@apache.org>.
On 10/05/2008, at 12:28 AM, Jason van Zyl wrote:
>>
>> The difference was that the GIT provider was discussed and
>> contributed via JIRA, like all other contributions. The other
>> provider appeared, on trunk, completely unannounced. It's clearly a
>> double standard to then turn around and say things like "Since when
>> did accepting new bodies of code be decided between two people."
>
> My point was not that you two decided to insert the code but that I
> objected and that didn't seem to matter at all. That was my point.
Your opinion does matter, and I'm still trying to sensibly discuss the
reasons why they might make sense. Let's look for James to start those
threads, if he hasn't been completely off-put from contributing at all
by now.
> What honestly bothers me is a company openly bitching in a
> sensationalistic fashion, and then wants to donate code again in a
> somewhat sensationalistic manner seems rather odd to me. Especially
> given the other options and five minutes after I provide an
> alternative which is the path we've been going down James just
> blasts the code in anyway appearing to be in a cone of silence with
> you.
I didn't even see the commit until after my first reply (for some
reason it appeared in my mailbox late), and I've had no discussion
with James about this that you haven't seen. I was kind of surprised
too, and I think it was just a miscommunication.
> And further to my point, because you guys initially didn't want to
> take the suggestion is that the sandbox is for Apache committers and
> James said in IRC that he didn't write that Wagon plugin. So I went
> and took a look at the code and it looks written primarily by one
> Sherali Karamov who has no CLA on file and he's not in the Atlassian
> CCLA. So again just looks a little rushed as you've insisted on this
> being the case for everything I've done lately but didn't check in
> this particular case. So what's the story here? Why is James
> checking in someone else's code as that's not the intent of the
> sandbox as far as we setup the parameters. I personally really don't
> like what just happened.
Yes, he has more paperwork to do, a point I made in this thread and on
IRC. Rather than let there be any confusion, I just removed it from SVN.
Personally, I don't care either way if the work continues, it's not my
itch. But I want to encourage contributions that make sense.
Just take a deep breath, enjoy the weekend, and let's revisit it later.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Jason van Zyl <ja...@maven.org>.
On 9-May-08, at 7:28 AM, Jason van Zyl wrote:
>
> On 9-May-08, at 2:41 AM, Brett Porter wrote:
>
>>
>> On 09/05/2008, at 6:03 PM, Jason van Zyl wrote:
>>
>>>>>
>>>>> Ah, hold on there. 1) Since when did accepting new bodies of
>>>>> code be decided between two people.
>>>>
>>>> It shouldn't be, and IMO this discussion should continue and get
>>>> some more opinions (as I said "if there is support here"). After
>>>> that, the sandbox is the best starting point and if anything goes
>>>> in that is more than James' own work, then the IP clearance
>>>> papers should of course be filled in too.
>>>>
>>>> But one standard for everyone, please. You checked in a more
>>>> significant contribution without discussion *at all* just a few
>>>> days ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
>>>
>>> I'm a committer and Ivan did not get access to our repository, and
>>> it was no different then the GIT provider.
>>
>> The difference was that the GIT provider was discussed and
>> contributed via JIRA, like all other contributions. The other
>> provider appeared, on trunk, completely unannounced. It's clearly a
>> double standard to then turn around and say things like "Since when
>> did accepting new bodies of code be decided between two people."
>
> My point was not that you two decided to insert the code but that I
> objected and that didn't seem to matter at all. That was my point.
>
And further to my point, because you guys initially didn't want to
take the suggestion is that the sandbox is for Apache committers and
James said in IRC that he didn't write that Wagon plugin. So I went
and took a look at the code and it looks written primarily by one
Sherali Karamov who has no CLA on file and he's not in the Atlassian
CCLA. So again just looks a little rushed as you've insisted on this
being the case for everything I've done lately but didn't check in
this particular case. So what's the story here? Why is James checking
in someone else's code as that's not the intent of the sandbox as far
as we setup the parameters. I personally really don't like what just
happened.
> What honestly bothers me is a company openly bitching in a
> sensationalistic fashion, and then wants to donate code again in a
> somewhat sensationalistic manner seems rather odd to me. Especially
> given the other options and five minutes after I provide an
> alternative which is the path we've been going down James just
> blasts the code in anyway appearing to be in a cone of silence with
> you.
>
> In the case of the last two things I have committed that aren't mine
> the SCM provider and much of Oleg's work I know what the outcome
> would be because the code is not duplicated, the code is good and if
> anyone actually objected I would oblige as I did with the CLA for
> Oleg's code which you asked for, and then following the same path
> for the SCM contribution getting the CCLA before hand.
>
>>
>>
>> But to be absolutely clear, I think the Accurev contribution is
>> great in the log run, and I'm glad to see Ivan on the lists
>> supporting it. I certainly have no complaint with them. Let's move
>> on.
>>
>>> Whereas the difference is access to our repository for what is
>>> honestly a duplication of much code that exists, and far less then
>>> something like an SCM provider. There is a stark difference
>>> because I don't freely hand out access. There are alternatives for
>>> plugins, especially given our model is fully distributed, and we
>>> already have a ton of orphaned plugins.
>>>
>>> What I checked in was written by the only people in the world with
>>> clear authority to write that SCM provider. Whereas these plugins
>>> largely duplicate what exists. So I think there is a stark
>>> difference.
>>
>> Firstly, no access has been handed out that wasn't already present.
>> If you now have a problem with the sandbox openness we instituted
>> as a group, please raise that separately.
>>
>> I wasn't debating the relative merits of the two contributions. As
>> far as I'm concerned, the discussion is ongoing - as I said, the
>> wagon plugin as is needs some work to be suitable for Wagon, if at
>> all. I don't want to maintain something that is only duplication
>> either. The license plugin in particular needs to take a look at
>> ways to interact with the existing techs rather than being a new
>> thing (there is also IANAL at Mojo that I just saw), but I think
>> better license handling is worth pursuing if James has ideas.
>>
>> Let's just continue that discussion, as two separate threads for
>> each thing.
>>
>> Thanks,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
> -- Buddha
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.
-- Jakob Burckhardt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Jason van Zyl <ja...@maven.org>.
On 9-May-08, at 2:41 AM, Brett Porter wrote:
>
> On 09/05/2008, at 6:03 PM, Jason van Zyl wrote:
>
>>>>
>>>> Ah, hold on there. 1) Since when did accepting new bodies of code
>>>> be decided between two people.
>>>
>>> It shouldn't be, and IMO this discussion should continue and get
>>> some more opinions (as I said "if there is support here"). After
>>> that, the sandbox is the best starting point and if anything goes
>>> in that is more than James' own work, then the IP clearance papers
>>> should of course be filled in too.
>>>
>>> But one standard for everyone, please. You checked in a more
>>> significant contribution without discussion *at all* just a few
>>> days ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
>>
>> I'm a committer and Ivan did not get access to our repository, and
>> it was no different then the GIT provider.
>
> The difference was that the GIT provider was discussed and
> contributed via JIRA, like all other contributions. The other
> provider appeared, on trunk, completely unannounced. It's clearly a
> double standard to then turn around and say things like "Since when
> did accepting new bodies of code be decided between two people."
My point was not that you two decided to insert the code but that I
objected and that didn't seem to matter at all. That was my point.
What honestly bothers me is a company openly bitching in a
sensationalistic fashion, and then wants to donate code again in a
somewhat sensationalistic manner seems rather odd to me. Especially
given the other options and five minutes after I provide an
alternative which is the path we've been going down James just blasts
the code in anyway appearing to be in a cone of silence with you.
In the case of the last two things I have committed that aren't mine
the SCM provider and much of Oleg's work I know what the outcome would
be because the code is not duplicated, the code is good and if anyone
actually objected I would oblige as I did with the CLA for Oleg's code
which you asked for, and then following the same path for the SCM
contribution getting the CCLA before hand.
>
>
> But to be absolutely clear, I think the Accurev contribution is
> great in the log run, and I'm glad to see Ivan on the lists
> supporting it. I certainly have no complaint with them. Let's move on.
>
>> Whereas the difference is access to our repository for what is
>> honestly a duplication of much code that exists, and far less then
>> something like an SCM provider. There is a stark difference because
>> I don't freely hand out access. There are alternatives for plugins,
>> especially given our model is fully distributed, and we already
>> have a ton of orphaned plugins.
>>
>> What I checked in was written by the only people in the world with
>> clear authority to write that SCM provider. Whereas these plugins
>> largely duplicate what exists. So I think there is a stark
>> difference.
>
> Firstly, no access has been handed out that wasn't already present.
> If you now have a problem with the sandbox openness we instituted as
> a group, please raise that separately.
>
> I wasn't debating the relative merits of the two contributions. As
> far as I'm concerned, the discussion is ongoing - as I said, the
> wagon plugin as is needs some work to be suitable for Wagon, if at
> all. I don't want to maintain something that is only duplication
> either. The license plugin in particular needs to take a look at
> ways to interact with the existing techs rather than being a new
> thing (there is also IANAL at Mojo that I just saw), but I think
> better license handling is worth pursuing if James has ideas.
>
> Let's just continue that discussion, as two separate threads for
> each thing.
>
> Thanks,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.
-- Buddha
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Brett Porter <br...@apache.org>.
On 09/05/2008, at 6:03 PM, Jason van Zyl wrote:
>>>
>>> Ah, hold on there. 1) Since when did accepting new bodies of code
>>> be decided between two people.
>>
>> It shouldn't be, and IMO this discussion should continue and get
>> some more opinions (as I said "if there is support here"). After
>> that, the sandbox is the best starting point and if anything goes
>> in that is more than James' own work, then the IP clearance papers
>> should of course be filled in too.
>>
>> But one standard for everyone, please. You checked in a more
>> significant contribution without discussion *at all* just a few
>> days ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
>
> I'm a committer and Ivan did not get access to our repository, and
> it was no different then the GIT provider.
The difference was that the GIT provider was discussed and contributed
via JIRA, like all other contributions. The other provider appeared,
on trunk, completely unannounced. It's clearly a double standard to
then turn around and say things like "Since when did accepting new
bodies of code be decided between two people."
But to be absolutely clear, I think the Accurev contribution is great
in the log run, and I'm glad to see Ivan on the lists supporting it. I
certainly have no complaint with them. Let's move on.
> Whereas the difference is access to our repository for what is
> honestly a duplication of much code that exists, and far less then
> something like an SCM provider. There is a stark difference because
> I don't freely hand out access. There are alternatives for plugins,
> especially given our model is fully distributed, and we already have
> a ton of orphaned plugins.
>
> What I checked in was written by the only people in the world with
> clear authority to write that SCM provider. Whereas these plugins
> largely duplicate what exists. So I think there is a stark difference.
Firstly, no access has been handed out that wasn't already present. If
you now have a problem with the sandbox openness we instituted as a
group, please raise that separately.
I wasn't debating the relative merits of the two contributions. As far
as I'm concerned, the discussion is ongoing - as I said, the wagon
plugin as is needs some work to be suitable for Wagon, if at all. I
don't want to maintain something that is only duplication either. The
license plugin in particular needs to take a look at ways to interact
with the existing techs rather than being a new thing (there is also
IANAL at Mojo that I just saw), but I think better license handling is
worth pursuing if James has ideas.
Let's just continue that discussion, as two separate threads for each
thing.
Thanks,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Jason van Zyl <ja...@maven.org>.
On 8-May-08, at 11:00 PM, Brett Porter wrote:
>
> On 09/05/2008, at 3:06 PM, Jason van Zyl wrote:
>
>>>
>>>> How does this differ from the remote-resources plugin? Could it be
>>>> combined with that?
>>>
>>> Remote resources plugin simply bundles resources together as a
>>> different
>>> artifact to allow other builds to depend on the same set of
>>> resources.
>>>
>>
>> It's grabs the transitive set of projects and takes the
>> organization name out. Adding something like:
>>
>> handleProject( MavenProject ) { do whatever you like; }
>>
>> To generalize it would be nice instead of duplicating the logic in
>> another plugin.
>
> +1
>
>>>
>>>> I would suggest as a starting point you can put them in the Maven
>>>> sandbox (or branch the remote resources plugin there and
>>>> incorporate),
>>>> if there is support for it here, since all Apache committers have
>>>> access there.
>>>
>>> Awesome, Ill prepare and put both of these plugins into sandbox now.
>>>
>>
>> Ah, hold on there. 1) Since when did accepting new bodies of code
>> be decided between two people.
>
> It shouldn't be, and IMO this discussion should continue and get
> some more opinions (as I said "if there is support here"). After
> that, the sandbox is the best starting point and if anything goes in
> that is more than James' own work, then the IP clearance papers
> should of course be filled in too.
>
> But one standard for everyone, please. You checked in a more
> significant contribution without discussion *at all* just a few days
> ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
I'm a committer and Ivan did not get access to our repository, and it
was no different then the GIT provider. Whereas the difference is
access to our repository for what is honestly a duplication of much
code that exists, and far less then something like an SCM provider.
There is a stark difference because I don't freely hand out access.
There are alternatives for plugins, especially given our model is
fully distributed, and we already have a ton of orphaned plugins.
What I checked in was written by the only people in the world with
clear authority to write that SCM provider. Whereas these plugins
largely duplicate what exists. So I think there is a stark difference.
>
>
>
>> For one I disagree it's appropriate to even bring them here, and 2)
>> new bodies of code need to go through the incubator which is why I
>> suggested Mojo which gives the default search behavior (which is a
>> good thing) and generally less cumbersome.
>
> I think combining of the license functionality with the remote
> resources plugin (or basing them both on a common ground) is worth
> having here. Good support for tracking and recording licenses is
> something I value as a part of this project.
>
> As for the wagon plugin... if it is closely related to the wagon
> releases and adds value I think it's of value in Wagon, especially
> if it can actually incorporate the couple of other ones floating
> around already. If it's just going to be more for us to maintain
> without value then it's better off somewhere else. I trust James to
> make the call on which to attempt, fully aware of the work that's
> involved in doing so. The sandbox is open to all Apache committers
> to play around with, obviously then doing the work to get it into a
> release is another matter.
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Felix Knecht <fe...@apache.org>.
Jason van Zyl schrieb:
>
> On 9-May-08, at 10:57 PM, Felix Knecht wrote:
>
>>
>>> But one standard for everyone, please. You checked in a more
>>> significant contribution without discussion *at all* just a few days
>>> ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
>>
>> Apart from the discussion why and who has committed it I feel a bit
>> strange as committer having signed a CLA and then seeing in every
>> header a copyright like
>>
>> /*
>> * Copyright 2008 AccuRev Inc.
>> *
>>
>> Just my 2 cents
>>
>
> What are you talking about?
Paragraph 2. at http://www.apache.org/licenses/cla-corporate.txt
"Grant of Copyright License...."
In most files (i.g. *.java) there's a copyright notice in the header above the license text saying that the copyright is
at AccuRev Inc.
So IMO the copyright is not granted to the Foundation but is still at AccuRev which is in contradiction to paragraph 2.
mentioned above.
IMO when committing stuff for others the committer is in charge for keeping legal stuff as well.
Maybe my understanding of the CLA policy is wrong because of my poor english knowledge. I apologize if so and say sorry.
Felix
>
> That was me and I always commit as submitted, which everyone should do,
> for tracking purposes. It's easy to change but it's more important that
> the state of the original contribution be captured.
>
>> Felix
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> Selfish deeds are the shortest path to self destruction.
>
> -- The Seven Samuari, Akira Kirosawa
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Jason van Zyl <ja...@maven.org>.
On 9-May-08, at 10:57 PM, Felix Knecht wrote:
>
>> But one standard for everyone, please. You checked in a more
>> significant contribution without discussion *at all* just a few
>> days ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
>
> Apart from the discussion why and who has committed it I feel a bit
> strange as committer having signed a CLA and then seeing in every
> header a copyright like
>
> /*
> * Copyright 2008 AccuRev Inc.
> *
>
> Just my 2 cents
>
What are you talking about?
That was me and I always commit as submitted, which everyone should
do, for tracking purposes. It's easy to change but it's more important
that the state of the original contribution be captured.
> Felix
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Selfish deeds are the shortest path to self destruction.
-- The Seven Samuari, Akira Kirosawa
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Felix Knecht <fe...@apache.org>.
> But one standard for everyone, please. You checked in a more significant
> contribution without discussion *at all* just a few days ago
> (http://svn.apache.org/viewvc?view=rev&revision=653572).
Apart from the discussion why and who has committed it I feel a bit strange as committer having signed a CLA and then
seeing in every header a copyright like
/*
* Copyright 2008 AccuRev Inc.
*
Just my 2 cents
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Brett Porter <br...@apache.org>.
On 09/05/2008, at 3:06 PM, Jason van Zyl wrote:
>>
>>> How does this differ from the remote-resources plugin? Could it be
>>> combined with that?
>>
>> Remote resources plugin simply bundles resources together as a
>> different
>> artifact to allow other builds to depend on the same set of
>> resources.
>>
>
> It's grabs the transitive set of projects and takes the organization
> name out. Adding something like:
>
> handleProject( MavenProject ) { do whatever you like; }
>
> To generalize it would be nice instead of duplicating the logic in
> another plugin.
+1
>>
>>> I would suggest as a starting point you can put them in the Maven
>>> sandbox (or branch the remote resources plugin there and
>>> incorporate),
>>> if there is support for it here, since all Apache committers have
>>> access there.
>>
>> Awesome, Ill prepare and put both of these plugins into sandbox now.
>>
>
> Ah, hold on there. 1) Since when did accepting new bodies of code be
> decided between two people.
It shouldn't be, and IMO this discussion should continue and get some
more opinions (as I said "if there is support here"). After that, the
sandbox is the best starting point and if anything goes in that is
more than James' own work, then the IP clearance papers should of
course be filled in too.
But one standard for everyone, please. You checked in a more
significant contribution without discussion *at all* just a few days
ago (http://svn.apache.org/viewvc?view=rev&revision=653572).
> For one I disagree it's appropriate to even bring them here, and 2)
> new bodies of code need to go through the incubator which is why I
> suggested Mojo which gives the default search behavior (which is a
> good thing) and generally less cumbersome.
I think combining of the license functionality with the remote
resources plugin (or basing them both on a common ground) is worth
having here. Good support for tracking and recording licenses is
something I value as a part of this project.
As for the wagon plugin... if it is closely related to the wagon
releases and adds value I think it's of value in Wagon, especially if
it can actually incorporate the couple of other ones floating around
already. If it's just going to be more for us to maintain without
value then it's better off somewhere else. I trust James to make the
call on which to attempt, fully aware of the work that's involved in
doing so. The sandbox is open to all Apache committers to play around
with, obviously then doing the work to get it into a release is
another matter.
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Jason van Zyl <ja...@maven.org>.
On 8-May-08, at 9:23 PM, James William Dumay wrote:
> Brett,
>
>> So this is resource based, instead of artifact based? If so, I think
>> it makes sense as an addition to the wagon project.
>
> That's correct and I agree that it would make a good addition to
> Wagon.
>
>> How does this differ from the remote-resources plugin? Could it be
>> combined with that?
>
> Remote resources plugin simply bundles resources together as a
> different
> artifact to allow other builds to depend on the same set of resources.
>
It's grabs the transitive set of projects and takes the organization
name out. Adding something like:
handleProject( MavenProject ) { do whatever you like; }
To generalize it would be nice instead of duplicating the logic in
another plugin.
> The licenses plugin on the other hand uses the license information
> specified in the pom to find, list, download and deploy licenses.
>
> The deploy goal is something that needs a little more thought. At the
> moment it allows you to download licenses found in a POM and deploy
> them
> as a classified "license" artifact to a specified repository for
> archiving.
>
> So I would say they are different enough not to warrant merging.
>
>> I would suggest as a starting point you can put them in the Maven
>> sandbox (or branch the remote resources plugin there and
>> incorporate),
>> if there is support for it here, since all Apache committers have
>> access there.
>
> Awesome, Ill prepare and put both of these plugins into sandbox now.
>
Ah, hold on there. 1) Since when did accepting new bodies of code be
decided between two people. For one I disagree it's appropriate to
even bring them here, and 2) new bodies of code need to go through the
incubator which is why I suggested Mojo which gives the default search
behavior (which is a good thing) and generally less cumbersome.
> Thanks
> James
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by James William Dumay <ja...@atlassian.com>.
Brett,
> So this is resource based, instead of artifact based? If so, I think
> it makes sense as an addition to the wagon project.
That's correct and I agree that it would make a good addition to Wagon.
> How does this differ from the remote-resources plugin? Could it be
> combined with that?
Remote resources plugin simply bundles resources together as a different
artifact to allow other builds to depend on the same set of resources.
The licenses plugin on the other hand uses the license information
specified in the pom to find, list, download and deploy licenses.
The deploy goal is something that needs a little more thought. At the
moment it allows you to download licenses found in a POM and deploy them
as a classified "license" artifact to a specified repository for
archiving.
So I would say they are different enough not to warrant merging.
> I would suggest as a starting point you can put them in the Maven
> sandbox (or branch the remote resources plugin there and incorporate),
> if there is support for it here, since all Apache committers have
> access there.
Awesome, Ill prepare and put both of these plugins into sandbox now.
Thanks
James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Brett Porter <br...@apache.org>.
On 09/05/2008, at 1:01 PM, James William Dumay wrote:
> Hey guys,
>
> Atlassian would like to donate two plugins to the Maven project:
>
> * maven-wagon-plugin (formerly maven-upload-plugin) - Allows you to
> upload and download resources during the build lifecycle and list
> remote
> resources.
So this is resource based, instead of artifact based? If so, I think
it makes sense as an addition to the wagon project.
>
>
> * maven-licenses-plugin - This plugin lists, downloads and packages
> license files for your projects transitive dependencies. Useful for
> creating assemblies that contain licenses.
How does this differ from the remote-resources plugin? Could it be
combined with that?
>
> I'm sorting out the legal now with Atlassian. So, how can we get the
> ball rolling? :)
I would suggest as a starting point you can put them in the Maven
sandbox (or branch the remote resources plugin there and incorporate),
if there is support for it here, since all Apache committers have
access there.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Donation of Maven plugins to the Maven Project.
Posted by Jason van Zyl <ja...@maven.org>.
On 8-May-08, at 8:01 PM, James William Dumay wrote:
> Hey guys,
>
> Atlassian would like to donate two plugins to the Maven project:
>
> * maven-wagon-plugin (formerly maven-upload-plugin) - Allows you to
> upload and download resources during the build lifecycle and list
> remote
> resources.
>
There is already a maven-wagon-plugin at mojo, and that would really
be more appropriate there. It's not really a core plugin and we've
been consciously trying to keep things distributed and shed all but
our core plugins. At any rate, one of these already exists at Mojo.
> * maven-licenses-plugin - This plugin lists, downloads and packages
> license files for your projects transitive dependencies. Useful for
> creating assemblies that contain licenses.
>
Dan Kulp can speak more to this but there is logic in the remote-
resources-plugin to walk the transitive dependencies and grab the
organization name, but easily changed to do anything really. What's in
there is actually quite powerful and should be reused.
> Both plugins are licensed under the Apache 2 license and have received
> recent attention of the mailing list which has prompted the idea of
> donation.
>
> We are happy to change the names of these plugins if there is anyone
> has
> better suggestions for their names.
>
> You can find both plugins on our svn:
> https://svn.atlassian.com/svn/public/atlassian/maven-plugins/
>
> I'm sorting out the legal now with Atlassian. So, how can we get the
> ball rolling? :)
>
I honestly see us going in the other direction of shedding more
plugins from Apache. Mojo still gives plugins that are immensely
useful being in default groupIds that are searched and it's far easier
to set people up there. You can get access in 5 minutes.
> Thanks,
> James
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org