+1
Op Sun, 03 May 2015 21:48:41 +0200 schreef Baptiste Mathus
bmat...@batmat.net:
Hi all,
As a followup to previous threads, I guess it's time for us to try and
move
on.
Indeed, the announcement says services should be shut down the 17 May.
So, to go forward, I'd like to ask Codehaus
Hi,
I don't think we have a real choice here. Once the Codehaus domain is gone
including its infra then there are no mailinglists anymore.
The vote should be about the move to X and how to register it for Markmail
and Nabble.
Robert
Op Mon, 04 May 2015 15:36:52 +0200 schreef Baptiste
option. Would you prefer to have a vote for that and
reconsider where we go for the MLs?
2015-05-04 19:41 GMT+02:00 Robert Scholte codeh...@sourcegrounds.com:
Hi,
I don't think we have a real choice here. Once the Codehaus domain is
gone
including its infra then there are no mailinglists
Looking good, very good.
Robert
Op Mon, 04 May 2015 22:16:32 +0200 schreef Baptiste Mathus
bmat...@batmat.net:
I just drafted that for informing about the ML terminations:
https://github.com/mojohaus/mojohaus.github.io/wiki/Termination-mail
WDYT?
2015-05-04 21:49 GMT+02:00 Robert Scholte
.
- Announcements List : same as user list. I don't see us keeping it;
WDYT? Do you agree?
2015-05-04 20:38 GMT+02:00 Robert Scholte codeh...@sourcegrounds.com:
If the google group is fully up and running, then I don't see any reason
for voting.
You could do a (pre-)announcement saying this ML
Paul Hammant(cc) did a Jira export for QDox[1]
IMHO that's complete enough.
If we agree on such approach, Paul can probably help us or give the
instructions how he did it.
thanks,
Robert
[1] http://paul-hammant.github.io/Old_Qdox_Issues/
Op Thu, 09 Apr 2015 17:14:52 +0200 schreef Baptiste
Title: Message Title
Robert Scholte closed an issue as Fixed
Hi,
Don't expect http://jira.codehaus.org/browse/HAUS-2412 to be fixed, we're
moving to https://github.com/mojohaus
See the mailinglist for Codehaus EOL.
Robert
Op Wed, 08 Apr 2015 23:32:35 +0200 schreef Jörg Hohwiller
jo...@j-hohwiller.de:
Hi there,
I refactored the
+1 for MojoHaus
Op Wed, 11 Mar 2015 12:06:34 +0100 schreef Brett Okken
brett.okken...@gmail.com:
+1 for MojoHaus
On Mar 11, 2015 4:35 AM, Stephen Connolly
stephen.alan.conno...@gmail.com
wrote:
On 11 March 2015 at 07:54, Hervé BOUTEMY herve.bout...@free.fr wrote:
then we have a few
+1
Op Mon, 02 Mar 2015 08:51:58 +0100 schreef Baptiste Mathus
bapti...@codehaus.org:
Well, since this didn't seem to trigger counter opinions I'm starting a
formal vote.
That vote is to deprecate the shitty-maven-plugin, and move it to the
mojo's graveyard.
[ ] +1 : deprecate it
[ ] 0 :
IMHO the Apache Maven team should focus on Maven Core, (java)-build
lifecycle plugins, plugin-development tools, transport (SCM, Wagon) and
project-health tools.
There are probably a couple of Codehaus-Mojo plugins which might be
interesting to move Apache Maven (assuming legal issues will
+1
Op Wed, 25 Feb 2015 18:14:00 +0100 schreef Stephane Nicoll
stephane.nic...@gmail.com:
Hi,
This release brings full Java8 compatibility thanks to MANIMALSNIFFER-51
We solved 4 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12070version=20742
There are still 20
Hi Jörg,
I think your adjustment of rev. 20330 to the
optional-elements-modeMinimum/verify.groovy is incorrect.
This project results in a jar so there's no reason to keep
dependencyManagement here: all dependencies should be resolved.
What I'm missing is a project *using* this bom. I seem
Maven, we might want to
call it dependable-pom.
WDYT?
Robert
Op Sat, 14 Feb 2015 12:17:45 +0100 schreef Robert Scholte
codeh...@sourcegrounds.com:
Hi Jörg,
I think your adjustment of rev. 20330 to the
optional-elements-modeMinimum/verify.groovy is incorrect.
This project results
Op Tue, 10 Feb 2015 14:26:57 +0100 schreef Anders Hammar
and...@hammar.net:
I would recommend that we migrate to the following requirement for all
our
plugins:
1. Minimum Maven version 3.0.4 (i.e. drop support for Maven 2.x)
As discussed (and concluded) somewhere else, we should go
Hi Lennart,
Why 3.0.4? This version has a security issue[1] fixed in 3.0.5 (it is
actually the only fix in 3.0.5).
And it is probably easier to say the plugin is Maven3 compatible, which
implies at least Maven 3.0.
Is there a specific interface change in 3.0.4 you depend on?
thanks,
Robert
soonish.
:)
2015-02-07 10:55 GMT+01:00 Robert Scholte codeh...@sourcegrounds.com:
From a user/community perspective I would go for 3.0 as a minimum.
Testing with a wide range of versions would be good.
So the minimum (3.0) and the latest (3.2.5 if available on Bamboo) would
already cover
...@gmail.com:
Hello there,
I took the version defined/used by the Codehaus Bamboo servers for ITs.
I can easily pick another version for more sensible reasons.
Which 3.0.x version is the better one to use?
(I suppose I should adjust the bamboo jobs as well, right?)
2015-02-07 10:29 GMT+01:00 Robert
Op Sun, 18 Jan 2015 00:01:16 +0100 schreef Jörg Hohwiller
jo...@j-hohwiller.de:
Hi there,
I would like to open a discussion about the design of
flatten-maven-plugin.
Important issue is http://jira.codehaus.org/browse/MOJO-2041
Therefore I already applied the old code back onto trunk and
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte closed an issue as Duplicate
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte created an issue
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte created an issue
Title: Message Title
Robert Scholte assigned an issue to Robert Scholte
Title: Message Title
Robert Scholte created an issue
to finally pull out beta3. Before that I would like to know
if there are any concerns (esp. according to MOJO-2042).
Regards
Jörg
Am 21.10.2014 19:40, schrieb Robert Scholte:
I think reverting is the best option right now.
Robert
Op Mon, 20 Oct 2014 22:53:33 +0200 schreef Jörg Hohwiller
jo...@j
and the current
beta2 has bugs that prevents core usage of flatten-maven-plugin in some
cases what is rather bad.
Unfortunately SVN is not very strong on feature branches and merging. I
am spoiled by git and other more agile infrastructure now...
Regards
Jörg
Am 19.10.2014 22:34, schrieb Robert Scholte
:18, schrieb Robert Scholte:
Hi Jörg,
I don't think this is correct. The whole idea is that:
- pom projects should stay as they are
- non-pom files should be flattened, meaning mainly resolving
dependencies.
so parent, modules, properties and reporting are already included for
the first, and should
Title: Message Title
Robert Scholte commented on an issue
Hi Jörg,
I don't think this is correct. The whole idea is that:
- pom projects should stay as they are
- non-pom files should be flattened, meaning mainly resolving dependencies.
so parent, modules, properties and reporting are already included for the
first, and should *never* be added to
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte closed an issue as Not A Bug
Title: Message Title
Robert Scholte closed an issue as Not A Bug
() )
{
return true;
}
}
}
return false;
}
Any ideas what makes the difference? Different maven version using
different super POM with central URL pointing to repo1.maven.org?
Thanks
Jörg
Am 28.09.2014 21:58, schrieb Robert Scholte:
Hi,
FYI
Hi,
I still consider Maven as a language independent build management tool.
In case of the enforceBytecodeVersion I think we should add an API so it
can be implemented for other packaging types as well.
Shouldn't be too hard to do so, just needs to be done.
@Stephen, which other rules do you
+1
Robert
Op Sat, 20 Sep 2014 09:48:49 +0200 schreef Baptiste Mathus
bapti...@codehaus.org:
Hi,
I'd like to release version 1.0-beta-3 of the extra-enforcer-rules
project.
That project provides additional rules for the Apache Maven's Enforcer
Plugin.
We solved 3 issues:
Current trunk runs fine on my system:
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
14:51:28+0100)
Maven home: D:\apache-maven-3.0.5\bin\..
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_55\jre
Default locale: nl_NL,
Just quoting the ajdoc-ref[1]
ajdoc currently requires the tools.jar from J2SE 1.3 to be on the
classpath. Normally the scripts set this up, assuming that your JAVA_HOME
variable points to an appropriate installation of Java. You may need to
provide this jar when using a different version
under 3 above.
2014-09-04 21:07 GMT+02:00 Robert Scholte
codeh...@sourcegrounds.com
:
Op Tue, 02 Sep 2014 23:44:10 +0200 schreef Lennart Jörelid
lennart.jore...@gmail.com:
I just noted, but adding a Max JDK version doesn't seem to make
any
sense
in this case.
The AspectJ compiler
- to make the transition to JDK 9 painless.
2014-09-08 19:29 GMT+02:00 Robert Scholte codeh...@sourcegrounds.com:
This is an interesting case, because the compile-time JDK is less then
the
runtime JDK (1.5 and 1.6 in same order). Normally it's the other way
around.
However, to be able to run
effectively be the same as setting a *maximum* JDK version.
2014-09-02 23:30 GMT+02:00 Robert Scholte codeh...@sourcegrounds.com:
Hi,
I've added the enforceBytecodeVersion rule to see which jar(s) are
causing
problems.
It seems that aspectjtools can't run with JDK5.
As long
Hi,
read http://www.codehaus.org/customs/licenses.html
The advice is to use ASL2, although MIT is permitted.
I want to hear the facts why they say MIT would be better.
Robert
Op Wed, 03 Sep 2014 21:40:48 +0200 schreef Dan Tran dant...@gmail.com:
OK, They are not my plugins, they belong to
Hi,
If you compare the differences between Apaches PMC and teammembers, then
the difference between a Codehaus despot and teammember is much smaller.
Teammembers already have a lot of rights for the infrastructure[1],
there's no such thing as binding votes. Main difference between a despot
Maybe the difference between String and GString[1]
equals should always work
Robert
[1] http://groovy.codehaus.org/Strings+and+GString
Op Thu, 04 Sep 2014 21:59:54 +0200 schreef Jörg Hohwiller
jo...@j-hohwiller.de:
Hi there,
I am not a groovy expert and need some help.
An IT of
Hi,
I've fixed the unittest, next step is to fix the integration tests.
I've added a JDK8 task to the integration tests, so now it will be tested
with the minimum (JDK5) and maximum, both with Maven-2.2.1.
There are only linux bambooo-agents available right now. According to
JIRA[1] there
, preferably with toolchains to manage
the JDK versions. Not sure if it's worth it to implement, though.
For me this is a valid reason to change the required JDK, I'll leave it up
to you.
Robert
Op Tue, 02 Sep 2014 23:00:26 +0200 schreef Robert Scholte
codeh...@sourcegrounds.com:
Hi
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte edited a comment on an issue
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte edited a comment on an issue
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte updated an issue
Title: Message Title
Robert Scholte updated an issue
Title: Message Title
Robert Scholte updated an issue
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte created an issue
Op Fri, 25 Jul 2014 17:16:17 +0200 schreef glecla...@codehaus.org:
Revision:
19892
Author:
gleclaire
Date:
2014-07-25 10:16:17 -0500 (Fri, 25 Jul 2014)
Log Message
findbugs-maven-plugin 3.0.0 release
Modified Paths
site/src/site/apt/plugins.apt
Diff
Modified:
Shouldn't it be 2.5.5 instead of 3.0.0?
Robert
Op Fri, 25 Jul 2014 17:16:17 +0200 schreef glecla...@codehaus.org:
Revision:
19892
Author:
gleclaire
Date:
2014-07-25 10:16:17 -0500 (Fri, 25 Jul 2014)
Log Message
findbugs-maven-plugin 3.0.0 release
Modified Paths
settings.xml for non-localhost users
Enjoy,
The Mojo team.
Robert Scholte
-
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
+1
Op Fri, 04 Jul 2014 18:06:52 +0200 schreef Robert Scholte
codeh...@sourcegrounds.com:
Hi,
I'd like to release version 1.0-beta-2 of the Mock Repository Manager
The Mock Repository Manager suite of projects are used to provide mock
or lightweight Maven Repository Managers for use
The vote has passed with the following result:
+1 : Karl Heinz Marbaise, Robert Scholte
0 :
-1 :
I'll proceed with the release process.
thanks,
Robert
Op Fri, 04 Jul 2014 18:06:52 +0200 schreef Robert Scholte
codeh...@sourcegrounds.com:
Hi,
I'd like to release version 1.0-beta-2
Hi,
I'd like to release version 1.0-beta-2 of the Mock Repository Manager
The Mock Repository Manager suite of projects are used to provide mock or
lightweight Maven Repository Managers for use during integration testing
of Maven plugins.
We solved 4 issues:
projects at work as well ( we adopt maven code style
and
svn).
import-codehaus-certificate is very helpful, try to read the
instructions
from Codehaus and import manually is a pain IMO
Thanks
-Dan
On Mon, Jun 30, 2014 at 2:32 PM, Robert Scholte
codeh...@sourcegrounds.com wrote:
Hi Dan,
I
that to rename 'prepare-environment' back to
'import-codehaus-certificate' ( rather then removing it) and call it
alpha,
to let ppl know it it very specify MOJO at codehaus development.
Thanks
-Dan
On Sun, Jun 29, 2014 at 12:25 PM, Robert Scholte
codeh...@sourcegrounds.com
wrote
should change
it
back to 'import-codehaus-certificates.
Thoughts?
Thanks
-Dan
On Sat, Jun 28, 2014 at 3:08 AM, Robert Scholte
codeh...@sourcegrounds.com
wrote:
I agree with Baptiste here.
I'm also wondering if this project should be pushed to Maven central,
since it's first of all
other project can use it as
well including my internal plugin development. BTW, I have a really need
for this.
What would it take todo so? should we push it as alpha while waiting for
more concrete decision?
-D
On Sun, Jun 29, 2014 at 2:33 AM, Robert Scholte
codeh...@sourcegrounds.com
I agree with Baptiste here.
I'm also wondering if this project should be pushed to Maven central,
since it's first of all a codehaus mojo specific plugin.
so -1
Robert
Op Sat, 28 Jun 2014 00:19:47 +0200 schreef Baptiste Mathus
bapti...@codehaus.org:
I'm not personally worried,
Hi Dan,
just a thought: how about changing the goals to:
* prepare-environment or prepare-system
* prepare-eclipse
* prepare-project
this way it's possible to do additional tasks without creating new goals,
since these tasks should all be done when preparing X.
Based on
It's not mine, it's Lennarts.
This happens when you generate your keys multiple times. For instance, if
you reinstall your machine are have a new one. These keys will then be
merged. That happened to me about 3 times, so mines a bit longer than the
average one.
It shouldn't be an issue,
IIRC to be compatible with Maven 2.0.6
I think I did this together with Mark.
I'm pretty sure you'll discover it ones you remove it.
Robert
Op Mon, 23 Jun 2014 20:30:08 +0200 schreef Karl Heinz Marbaise
khmarba...@gmx.de:
Hi,
just a question concerning the SQL Maven Plugin...
can someone
+1 for the m-dependency-p
Op Mon, 23 Jun 2014 01:08:09 +0200 schreef Stephen Connolly
stephen.alan.conno...@gmail.com:
Ancestors are dependencies, you cannot build a project without its
parent... You just don't reference them in a dependencies section is all!
I think it actually would suit
Hi all,
40% of the current open issues are related to QDox-attributes and QDox-XML.
QDOX-20[1]: Migrate qdox-attributes and qdox-xml to maven 2
QDOX-21[2]: Upload website for qdox-xml and qdox-attributes
They're open for about 5 years, so to me it looks like there's not enough
interest for it to
ignore, wrong list...
Op Sat, 21 Jun 2014 22:28:05 +0200 schreef Robert Scholte
codeh...@sourcegrounds.com:
Hi all,
40% of the current open issues are related to QDox-attributes and
QDox-XML.
QDOX-20[1]: Migrate qdox-attributes and qdox-xml to maven 2
QDOX-21[2]: Upload website for qdox
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte commented on an issue
Try https://bamboo-ci.codehaus.org/userlogin!default.action
Robert
Op Fri, 30 May 2014 23:52:39 +0200 schreef Dan Tran dant...@gmail.com:
I am not able to login into it.
Can someone confirm?
-D
-- Forwarded message --
From: Codehaus Bamboo bamboo-ser...@codehaus.org
Date:
Op Thu, 29 May 2014 22:54:17 +0200 schreef Jörg Hohwiller
jo...@j-hohwiller.de:
Hi,
Hi Jörg,
Hi Robert,
I very much appreciate your support and contribution.
However, your in the middle of the discussion commit caused me some
SVN conflict and merge trouble.
I did my best to resolve but
Try using https instead of http
Robert
Op Tue, 27 May 2014 16:26:13 +0200 schreef Julien HENRY henr...@yahoo.fr:
The problem with Nexus is now fixed. I'm now stopped at step:
Update the plugins.apt document to reflect the new release. Redeploy the
mojo site by executing mvn site-deploy and
/maven-how-to-merging-plugin-configuration-in-complex-projects/
Op Sun, 25 May 2014 23:27:35 +0200 schreef Jörg Hohwiller
jo...@j-hohwiller.de:
Am 24.05.2014 12:03, schrieb Robert Scholte:
Hi,
Hi Robert,
seems like I missed a mail.
no worries...
What I don't understand is why you want
(pomDescriptor) so future Maven
features could help with some magic I can not see yet?
Best regards
Jörg
Am 06.05.2014 20:49, schrieb Robert Scholte:
Ideally what we want is some sort of xslt, however that's probably
too heavy and too complex.
Instead you could think of something like (when written
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte created an issue
Title: Message Title
Robert Scholte closed an issue as Fixed
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte created an issue
Title: Message Title
Robert Scholte assigned an issue to Robert Scholte
These are your options
- Ask Arnaud, Stephen, Brett or Ben directly
or
- try to contact supp...@codehaus.org
or
- create a jira issue for the HAUS project
thanks,
Robert
Op Wed, 14 May 2014 17:45:40 +0200 schreef Dan Tran dant...@gmail.com:
Hello MOJO team
How do I go about getting this?
Title: Message Title
Robert Scholte commented on an issue
Title: Message Title
Robert Scholte updated an issue
Title: Message Title
Robert Scholte closed an issue as Won't Fix
Dan,
https://jira.codehaus.org/browse/HAUS-2379 has the wrong title, which
might result in an unwanted Jira key for the project
Robert
Op Thu, 15 May 2014 21:12:16 +0200 schreef Dan Tran dant...@gmail.com:
Thanks Robert
-Dan
On Thu, May 15, 2014 at 11:57 AM, Robert Scholte
codeh
1 - 100 of 1522 matches
Mail list logo