Thanks, Benjamin. Got it working ...
Regards,
- Torben
Benjamin Bentmann wrote:
[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.release:maven-release-manager] was not found.
org.apache.maven.release
maven-release-manager
On 5-Apr-08, at 3:13 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
You don't need a 72 hour vote, I would try it in a branch first
and then
get people to look at it.
Just wondering: If I would fill in JIRAs for each affected plugin to
request
a) adding an encoding parameter if not a
Jason van Zyl wrote:
You don't need a 72 hour vote, I would try it in a branch first and then
get people to look at it.
Just wondering: If I would fill in JIRAs for each affected plugin to request
a) adding an encoding parameter if not already existent
b) making this parameter default to Latin
Everything seems to pass, and I'll huck the whole lot under hudson and
commit the git provider.
On 5-Apr-08, at 2:44 PM, Eugene Kuleshov wrote:
struberg wrote:
For the really 'edgy' guys out there: I've fixed the
maven-scm-provider-git to also work with
git-1.5.4.
$> git-clone http://ns1.
struberg wrote:
>
> For the really 'edgy' guys out there: I've fixed the
> maven-scm-provider-git to also work with
> git-1.5.4.
>
> $> git-clone http://ns1.backwork.net/git/maven-scm-providers-git.git
> as usual...
>
> Please provide feedback, so we can move this to codehaus if it's mature
>
On 5-Apr-08, at 12:21 PM, Benjamin Bentmann wrote:
Could we make the AbstractMojo class more usefull by providing some
commonly-used support methods ?
+1 on the general idea to avoid copy&paste, -1 on the proposal to
share code via AbstractMojo.
For some reason, AbstractMojo is part of the
I would use composition instead of inheritance and create helper
components for those things. Pushing all the helper methods, when in
most cases hardly any of them will be used, is not a good design.
We definitely need helps for making classloaders (take the one from
jetty run), working wit
Could we make the AbstractMojo class more usefull by providing some
commonly-used support methods ?
+1 on the general idea to avoid copy&paste, -1 on the proposal to share code
via AbstractMojo.
For some reason, AbstractMojo is part of the uber JAR and as such updates to
it would be bound to
Hello,
Plugin developer only require to implement the Mojo interface, but in most
(all ?) the case they extend AbstractMojo.
Having myself created or contributed multiple plugins, I had to solve the
same issues many time, using an copy/paste.
Could we make the AbstractMojo class more usefull by
Le samedi 05 avril 2008, nicolas de loof a écrit :
> +1
>
> Is there any overlap with the tool chain proposal ?
as I understand the tool chain proposal, no overlap at all
the tool chain is here to let a central place to configure tools on every
developer environment (like where is javac 1.5)
sour
You don't need a 72 hour vote, I would try it in a branch first and
then get people to look at it.
It's a good idea, just don't do it on trunk directly so that we have
the before and after to compare.
On 5-Apr-08, at 10:20 AM, Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list abou
On Sat, Apr 5, 2008 at 7:20 PM, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
[...]
> The full proposal is here:
>
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Non-binding +1
Regards,
Tomek
-
+1
Benjamin
Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by
each
and every plugin,
2. a default value set to ISO-8859-1 (inst
+1
Is there any overlap with the tool chain proposal ?
Nico
2008/4/5, Hervé BOUTEMY <[EMAIL PROTECTED]>:
>
> Hi,
>
> Since the discussion on the list about Maven and encoding 2 weeks ago,
> Benjamin and I worked on a proposal to have:
> 1. a central point of configuration of sources encoding,
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by each
and every plugin,
2. a default value set to ISO-8859-1 (instead of platform encoding) to have
build
Hi there,
I'm trying to fix the bug MRELEASE-128. In order to test my
modifications I'd like to run my modified version of the
maven-release-manager of course.
However, there seems to be a problem with the dependency resolution.
While running "mvn release:prepare" on a test project I get the
[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.release:maven-release-manager] was not found.
org.apache.maven.release
maven-release-manager
1.0-alpha-5-TSG
true
or
Hi there,
I'm trying to fix the bug MRELEASE-128. In order to test my
modifications I'd like to run my modified version of the
maven-release-manager of course.
However, there seems to be a problem with the dependency resolution.
While running "mvn release:prepare" on a test project I get the
The Maven team is pleased to announce the release of the Maven Eclipse
Plugin, version 2.5.1
This plugin is used to generate Eclipse IDE files (*.classpath,
*.wtpmodules and the .settings folder) for use with a project.
http://maven.apache.org/plugins/maven-eclipse-plugin/
You can run mvn -up to
19 matches
Mail list logo
