Sorry, I went ahead to move it out of sandbox and begin asking
feedback to release it.
-Dan
On Sun, Aug 28, 2011 at 4:06 AM, Anders Hammar wrote:
> Is this a vote or what?
> From the original message I can't really tell if it's a vote of if a
> question addressed to Johann.
>
> /Anders
>
> On Su
Let us please keep on the track of discussing the problem as using Github's git
repo as the main scm for a Mojo project as opposed to using The Codehaus git
repo; the latter being desired for the sake of committer approval.
-
To
Codehaus is not a foundation like Apache or Eclipse, so Copyright © Codehaus
does indeed means nothing ;-)
--
Julien Ponge
http://julien.ponge.info/
On lundi 29 août 2011 at 23:39, Benson Margulies wrote:
> On Mon, Aug 29, 2011 at 5:32 PM, Mark Struberg (mailto:strub...@yahoo.de)> wrote:
> >
On Mon, Aug 29, 2011 at 5:32 PM, Mark Struberg wrote:
> +1
>
> This discussion has also a legal component!
>
> If someone does work and pushes this stuff to the repo on codehaus, then it's
> crystal clear that this is a contribution to codehaus.
> If one just maintains a 'private' fork on github,
+1
This discussion has also a legal component!
If someone does work and pushes this stuff to the repo on codehaus, then it's
crystal clear that this is a contribution to codehaus.
If one just maintains a 'private' fork on github, he could later also cange the
license of his own stuff...
LieGr
On 30/08/2011, at 6:51 AM, Julien Ponge wrote:
>
> Take advantage of Git and GitHub for the ease of collaboration, but retain a
> reference Git repository at Codehaus where only commiters can make pushes
> (possible from a GitHub fork where they already filtered incoming
> contributions). That
I agree 100% Nicolas.
Take advantage of Git and GitHub for the ease of collaboration, but retain a
reference Git repository at Codehaus where only commiters can make pushes
(possible from a GitHub fork where they already filtered incoming
contributions). That sounds like a win-win approach.
2011/8/29 Christopher Hunt
> On 30/08/2011, at 4:09 AM, Jesse McConnell wrote:
>
> > I think the github bit is part of the issue, also I think the release
> > process should be left up to the plugin at this point and mojo's ought
> > to do away with the whole vote, wait a couple of days, release
I'm in favour for the voting (waiting 3 days is no crisis) - and often
people find stuff I've not found yet.
I also see your point about access control.
So I guess a good middle way would be to use git hosted at the Haus.
2011/8/29 Christopher Hunt
> On 30/08/2011, at 4:09 AM, Jesse McConnell w
actually, it's there
already:http://mojo.codehaus.org/development/performing-a-release.html#Preparing_for_the_First_Production_Release
-RobertFrom: rfscho...@codehaus.org
To: dev@mojo.codehaus.org
Date: Mon, 29 Aug 2011 20:21:30 +
Subject: RE: [mojo-dev] JIRA for JSLint Maven Plugin
On 30/08/2011, at 4:09 AM, Jesse McConnell wrote:
> I think the github bit is part of the issue, also I think the release
> process should be left up to the plugin at this point and mojo's ought
> to do away with the whole vote, wait a couple of days, release
> process. It makes sense on maven co
sure, no problem. -RobertFrom: hu...@internode.on.net
Date: Tue, 30 Aug 2011 06:19:37 +1000
To: dev@mojo.codehaus.org
Subject: Re: [mojo-dev] JIRA for JSLint Maven Plugin
Hi Robert,
Can you please update our MOJO documentation to clearly state this and explain
the rationale. I would have thoug
Hi Robert,
Can you please update our MOJO documentation to clearly state this and explain
the rationale. I would have thought that graduation from the sandbox would have
been entirely sufficient.
Kind regards,
Christopher
On 30/08/2011, at 2:58 AM, Robert Scholte wrote:
> After graduation fro
[
https://jira.codehaus.org/browse/MJAXB-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=277296#comment-277296
]
Anders Hammar edited comment on MJAXB-52 at 8/29/11 1:10 PM:
-
This turns
[
https://jira.codehaus.org/browse/MJAXB-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anders Hammar closed MJAXB-52.
--
Resolution: Not A Bug
This turns out not to be a bug, but a side effect of {{clearOutputDir}} being
set to tr
I think the github bit is part of the issue, also I think the release
process should be left up to the plugin at this point and mojo's ought
to do away with the whole vote, wait a couple of days, release
process. It makes sense on maven core but the plugins in mojo are so
diverse it makes little s
To be clear: codehaus also offers git repo hosting. So I see no reason to not
use GIT.
LieGrue,
strub
--- On Mon, 8/29/11, Jesse Farinacci wrote:
> From: Jesse Farinacci
> Subject: Re: [mojo-dev] [DISCUSS] move back github stuff to codehaus
> To: dev@mojo.codehaus.org
> Date: Monday, August 2
Greetings,
On Mon, Aug 29, 2011 at 12:54 PM, Robert Scholte wrote:
> Sure the committers of Sonatype will do their best to maintain it, but I
> agree with Mark: Codehaus would be a better place, either svn or git ;)
I think it's probably a good idea to keep things in one place. Please,
git is ju
I would imagine that the sources are equally hard/easy to find whereever
they reside - as long as the references are correct (documentation, pom scm
etc).
Having said that I'm really pro-git and hope we at least can use codehaus
git.
It's fast - and it's a lot easier to collaborate with push and p
After graduation from the sandbox the plugin will be a pre-released plugin
(beta plugin). Those plugins still use a MOJO component for jira.Only after the
first final release it should have the its own jira project (MJSLINT) -Robert >
From: hu...@internode.on.net
> Date: Mon, 29 Aug 2011 08:51:
It is already hard to find plexus documentation and with the sources outside
codehaus it's even harder to get some grip on it.Sure the committers of
Sonatype will do their best to maintain it, but I agree with Mark: Codehaus
would be a better place, either svn or git ;) -Robert > From:
hu...@i
BanDuplicateClasses fails when there is a dependency of type pom
Key: MOJO-1731
URL: https://jira.codehaus.org/browse/MOJO-1731
Project: Mojo
Issue Type: Bug
Componen
maven-native-api: AbstractCompiler#getObjectFile() produces meaningless error
messages
--
Key: MOJO-1730
URL: https://jira.codehaus.org/browse/MOJO-1730
Project: Mojo
[
https://jira.codehaus.org/browse/MFINDBUGS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=277281#comment-277281
]
Marcin Kuthan commented on MFINDBUGS-146:
-
Any feedback from the plugin developers?
Th
Hi list,
Being the original contributor of the JasperReports, I semi-regularly
get an email asking me about a feature or another (or mostly about
updating the version the underlying lib); unfortunately, I am not
using this plugin at all since several years now, so I'm not in any
position to make a
25 matches
Mail list logo
