Wendy told me in the past that the sync is every day, so be patient :)
Hm, out of curiosity: How is this sync realized? The pages of the Javadoc
Plugin now print 2008-04-12 as last published so I assume the sync
happened. However, the obsolete page [0] is still online. Will the sync ever
delete
Brian E. Fox wrote:
I saw leave it as it is because that is the normal scenario and the one
users are most likely to have. This way we see and fix the same things
they will need.
+1. The reactor was meant for exactly those aggregating builds. The usual
way to disable recursive builds is the
Sebastien ARBOGAST wrote:
I would like to find a natural solution to share confirguration
files between two modules. [...]
For now, the only solution I've found is to duplicate those files in
src/main/resources for each module.
Brian suggested that I could put those files in a third module to
Amir Eliaz wrote:
So the problem really is a wrong dependency in maven-pmd-plugin-2.3.pom,
which is the latest for this plugin.
The dependency in general is not wrong, it's just inappropriate for users
that would like to use newer rules.
The SVN head has just been updated to use 4.2.1 (see
Hi,
I wanted to deploy a new 2.4-snapshot of the PMD Plugin but failed because
the existing metadata files are not group-writable. Can somebody help and
fix the file permissions?
Benjamin
-
To unsubscribe, e-mail: [EMAIL
Hervé Boutemy wrote:
copy the files to new ones and remove old ones
Doh, I could have known: WAGON-19, MDEPLOY-28
I just did it on pmd plugin 2.4-SNAPSHOT: you can deploy the snapshot now
Thanks Hervé, deployment worked fine.
Benjamin
Author: hboutemy
Date: Sat Apr 19 05:27:46 2008
New Revision: 649803
URL: http://svn.apache.org/viewvc?rev=649803view=rev
Log:
lock down versions of common reporting plugins for site reproducibility
Modified:
maven/pom/trunk/maven/pom.xml
I'm +1 for the idea, but unfortunately it's
Author: hboutemy
Date: Sun Apr 20 13:37:25 2008
New Revision: 649973
URL: http://svn.apache.org/viewvc?rev=649973view=rev
Log:
[MPIR-80] added Java requirements to the Dependency Report
Submitted by: Niall Pemberton
Reviewed by: Hervé Boutemy
Modified:
Now that there are two real eclipse plugins for maven, I have to wonder
how much use this plugin will continue to get and if it's worth such a
major overhaul?
A possible reason to use the maven-eclipse-plugin:
It's not as invasive as Q4E or M2Eclipse. You can invoke it once on your own
Author: olamy
Date: Fri Apr 18 14:10:33 2008
New Revision: 649690
URL: http://svn.apache.org/viewvc?rev=649690view=rev
Log:
[MINVOKER-22] Add feature to install plugin to a local repository.
Submitted by Paul Gier
Modified:
Hi,
this thread is somehow extending the discussion about Where to create JIRA
issues for Maven documentation? [0] and seeks to clarify the intended
target JIRA project for new issues, especially those projects listed in the
category Maven Admin.
For example, the recent issue MNG-3551 is about
Jason van Zyl wrote:
I don't think evangelism is the right name
I agree, from a user's perspective the name might be a little cryptic. The
name of the other project Maven Repository Maintenance sounds more
descriptive.
So that uses can edit and add FAQ entries
Do you refer to the wiki
Jason van Zyl wrote:
When should users go to the JIRA project and when to the wiki?
Those should be collapsed too and just put in the wiki.
OK, I just edited the project description to redirect people over to
Confluence. Can we disable the creation of new issues for MNGFAQ?
Benjamin
Hervé Boutemy wrote.
the proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Recently, we have received two comments from users on the wiki that are
against the proposed default encoding of Latin-1 but would rather like it to
stay as is, i.e.
Brian E. Fox wrote:
Who exactly is asking for this change?
Basically only me, in an attempt to guarantee reproducible builds by
eliminating a dependency on an environmental property.
Is there an issue with a huge number of votes attached to it?
To my knowledge, no. We have MNG-2216 that
Solved, the dependency was inherited transitively by maven-artifact-2.0.9.
You should never rely on transitive dependencies if you directly use its
classes/methods in your code but always declare them directly. The goal
dependency:analyze
can help you a big deal in ensuring all your
Brian E. Fox wrote:
I'd say based on the various points brought up by the users that platform
encoding as the default makes the most sense.
Yes, that's the majority's sense. I counted roughly but so far the ratio of
votes is about 3:1 for keeping platform encoding as default vs. Latin-1,
Brian E. Fox wrote:
Is a warning really needed? Perhaps just an INFO that says using platform
default encoding: [value]. Again going under the theory that someone that
needs to worry about the encoding will be looking for it, shoving a
warning in everyone's face that doesn't care isn't a great
Jason van Zyl wrote:
and as such warning is most appropriate
rather than simply info. I could be talked into accepting an info that
has build not fully reproducible etc text in it, but this is
splitting hairs.
It can in no way effect what currently happens even if it's not 100%
Dennis Lundberg wrote:
As long as there is an easy way for users to get rid of the warning, which
seems to be the case here.
Yes, simply setting the POM property ${project.build.sourceEncoding} to some
value, either XYZ or if users really want ${file.encoding}, will disable the
warning.
Hervé BOUTEMY wrote:
Kenney started a proposal
http://docs.codehaus.org/display/MAVEN/Versioning
with a implementation of a comparator.
The JBoss Product Versioning [0] suggests the following additional
well-known qualifiers:
- CR
- FINAL
Benjamin
[0]
Jörg Schaible wrote:
Maybe a new scope
+1 on that instead of some time-consuming ASM post analysis and POM
rewriting.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
Wayne Fay wrote:
How is CR different from RC?
I don't meant to say they are different, it's only another well-known
qualifier, aliasing one from the existing list.
I think I'd pick one and forget about the other.
Is an option, we only need to make sure to clearly explain people that
Nicolas De Loof wrote:
I don't think we have plan yet to release maven 2.1, so I think it would
be a valid to require java 1.5 as minimal runtime.
+1 for Maven 2.1, -1 for Maven 2.0.10 (doesn't feel right to bump minimum
requirements in a maintenance branch).
Once we have the toolchains
Hi,
The help goal that gets generated by the Maven Plugin Tools 2.4 contains
various internal utility methods (e.g. toLines()) that do some pretty
printing of long descriptions at execution time of the help goal.
Any reason why we couldn't do all this line breaking and indentation stuff
Vincent Siveton wrote:
IIRC the main reason to have toLines() in the generated class is to
control the ouput, ie getting user configuration like max buffer or
indentation and providing the specific output.
You mean to support something like this:
mvn foo:help -Dindent=4 -Dmax=120
Do I
Vincent Siveton wrote:
Actually, end users could control the output with -Ddetail parameter,
so why not the formatting ?
Well, alright.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Brett Porter wrote:
In doxia-like fashion, this prevents being able to use a new wagon with
existing versions of Maven, because they use code in AbstractWagon (which
is hidden by Maven via provider-api).
If I don't misunderstand things, the same problems could arise some day for
the
Paul Gier wrote:
3. There was a suggestion to allow the use of ! to disable a profile.
So the command line would look like: mvn -P!myProfile
Unless some severe drawback is reported, +1 on this because ! is quite
natural among programmers for negation and also matches the existing syntax
for
Daniel Kulp wrote:
Can I ask if you have anything else you think is needed before doing a
release?
I just closed MPMD-64 which was the only unresolved issue scheduled for 2.4.
If nobody else wants to stuff things into the next release, I believe that's
it.
If you think it's ready, I'd
Olivier Lamy wrote:
2008/5/17 Vincent Siveton [EMAIL PROTECTED]:
Hi Olivier,
2008/5/17, Olivier Lamy [EMAIL PROTECTED]:
Hi,
It's just to save fingers :-).
-Dmaven.test.skip=true means 22 chars
-DskipTests means 11 chars.
laziness ;)
Yes (I'm a latin french guy ;-) )
Daniel Kulp wrote:
I'll proceed with getting the artifacts released.
I noticed the JARs are on central since May 27. However
- there seems be no release announcement on the mail lists
- the version 2.4 is not marked as released in JIRA
- the plugin's site is still about 2.3
Just wondering
Hervé BOUTEMY wrote:
http://docs.codehaus.org/display/MAVEN/Reporting+Encoding+Configuration
+1
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
I can't fight the feeling that something about the spam filter has
changed. While trying to subscribe to wagon-dev, my confirmation mail was
rejected as being spam:
- Transcript of session follows -
... while talking to mx1.us.apache.org.:
DATA
552 spam score (5.4) exceeded
+0200 (CEST)
Message-ID: [EMAIL PROTECTED]
From: Benjamin Bentmann [EMAIL PROTECTED]
To: Maven Developers List dev@maven.apache.org
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Subject: Re: Spam Rating of Mails
Date: Sat, 7 Jun 2008 17:16:00 +0200
MIME-Version: 1.0
Content-Type: text/plain
Dennis Lundberg wrote:
The problem comes when the user specifies a stagingDirectory. The
parameter is of type File and will be created relative to the currently
running project. This has to change so that it is relative to the top most
project of the reactor. Unfortunately I haven't been
Brian Fox wrote:
Try filling out the subject and put something in the body.
I followed Wendy's advice and contacted infra:
https://issues.apache.org/jira/browse/INFRA-1640
So far it seems the major spam penalty arises from my updated user-agent.
Benjamin
--
View this message in context:
Vincent Siveton schrieb:
I propose to improve [1] to add a code style for our pom files.
+1 for some convention (which is documented as such).
I see the following in this order.
Considering other POMs like parent POMs and Mojo, your proposal should
finally cover all POM elements (e.g.
Dennis Lundberg schrieb:
I want to separate Maven Projects, as they are called in the
menu of the main site, from breadcrumbs that tells you where on the site
you currently are.
+1, moving the Maven Projects out of the breadcrumbs scales better
with increasing project number.
My current
Jesse McConnell wrote:
pom:reformat would be pretty nice
+1, cool idea. Might we worth to distinguish the use cases reorder and
reformat, i.e. separate indentation stuff from element ordering.
BTW, Paul had once started a Pom Plugin [0], maybe there is something to
reuse/merge.
Paul Gier wrote:
Anyway, I definitely like the idea of a pom plugin to do pom:reformat
or pom:reorder and maybe I can add a parameter about sorting the
dependencies.
Instead of a parameter, I believe sorting the dependencies should be a
distinct mojo. Otherwise, how to handle the use case
Vincent Siveton wrote:
FYI I created MNG-3634 and you could see the result here:
http://people.apache.org/~vsiveton/MNG-3634/maven-2.0.x/site/maven.html
Comments are welcome!
I prefer your initial suggestion, which might be looking like that after
incorporating the other elements:
Dennis Lundberg wrote:
http://people.apache.org/~dennisl/inherited-menu-2.png
Feedback still wanted: negative or positive.
Looks nice ;-)
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Vincent Siveton wrote:
IMHO devs should be after licenses, since they describe more a project
than a build.
[...]
same reasoning for ML.
[...]
I propose to put dependencyManagement before dependencies to improve
the readingness.
All fine with me. Also taking into account Paul Benedict's
Brett Porter wrote:
I also find a few things weird about the order. IMO,
- dependencies and repositories should be together
- dependencies and dependencyManagement should be together
- build should be after dependencies, etc
- profiles should be after everything else.
Seems like our latest
Paul Gier wrote:
I was imagining this used during the
development cycle, so that any changes it causes would go through some
cycles of testing.
Maybe the first test could be performed by the POM Plugin itself, i.e.
have it calculate the transitive deps before the POM change and
afterwards
Vincent Siveton wrote:
http://svn.apache.org/repos/asf/maven/site/trunk/src/site/apt/developers/conventions
code.apt
* Documentation: Document public interfaces well, i.e. all
non-trivial public and protected functions should include Javadoc that
indicates what it does.
I would like to
Vincent Siveton wrote:
So, I am in favour to use unicode to all resources bundles. What others think?
To repeat my argument from MSITE-287: I believe using ASCII only with
Unicode escapes is simply the most robust choice for an international
dev community. For instance, somebody who
Dennis Lundberg commented on JXR-65:
What command did you issue?
How does your configuration (POM) look?
What versions of the relevant plugins are you using?
Just a thought, not sure if this is feasible with JIRA: To prevent bug
reports with insufficient
Igor Fedorenko wrote:
We've discussed this subject on m2e dev list a lot recently
Just to give the pointer:
http://docs.codehaus.org/display/M2ECLIPSE/Separate+Eclipse+and+Maven+output+folders
Benjamin
-
To unsubscribe,
Jason van Zyl wrote:
import hidden.org.codehaus.plexus...
Side note:
The Checkstyle rule IllegalImport [0] could help to ban this.
Benjamin
[0] http://checkstyle.sourceforge.net/config_imports.html#IllegalImport
-
To
Henri Gomez wrote:
Could be a good idea to send on this list, a list of up to date
plugins
Alternatively, just browse:
- http://maven.apache.org/plugins/index.html
- http://mojo.codehaus.org/plugins.html
Benjamin
-
To
Jason van Zyl schrieb:
I think before you start cataloging these you need to get someone else
to validate it.
Dennis reported the same issue, that already makes two of us ;-)
Regarding validation of another issue: Can somebody please try to build
maven-core (or run the bootstrap from the
Jason van Zyl wrote:
Results :
Tests in error:
testitMNG3380(org.apache.maven.integrationtests.MavenITmng3380ManagedRelocatedTransdepsTest)
Tests run: 166, Failures: 0, Errors: 1, Skipped: 0
Confirmed on Xubuntu 8.04 with Sun JDK 1.6.0_06
Benjamin
Hi,
if possible, I suggest to update Maven 2.1 to use the latest version of
Classworlds instead of 1.2-alpha-12. The recent Hudson package is still
failing for an encoding like UTF-16, among others due to PLX-367 which
prevents Maven from booting.
In this context: Brian has once setup some
Jason van Zyl wrote:
If you want to make the change locally and validate with the Hudson
bundle I'm fine with the change. Go for it.
Committed to trunk, the local Hudson didn't show any difference (i.e.
only the two already known ITs were failing). But know it's at least
possible to run
Benjamin Bentmann wrote:
Sonatype's Hudson instance just started re-building
... and happily failed at running the ITs. The bottom line of the build
Exception in thread main java.lang.NoClassDefFoundError:
/home/j2ee-hudson/apache-maven-2/1-SNAPSHOT/boot/plexus-classworlds-1/2-alpha-13/jar
Jason van Zyl wrote:
The build just produced on the CI machine doesn't duplicate the files anymore.
Yep, back to normal. Is there a reason why the job maven-2.1.x-ITs
over at Sonatype invokes Maven in the directory
/home/j2ee-hudson/.hudson/jobs/maven-2.1.x-ITs/workspace
instead of
Mark Hobson wrote:
Has anyone managed to achieve this or would this be a new feature?
I tried to realize something like this for integration testing with the
Invoker Plugin. Its invoker:install goal introduced with the release of
version 1.2 aims at staging not only the artifact under test
Brett Porter wrote:
Any idea what is wrong in 1.1+?
I did some major changes in the relocator component for MSHADE-28 which
according to the plugin's release history is quite the only change that
might be related. Maybe I managed to get something wrong in there. Will try
to reproduce the issue
John Casey wrote:
For what it's worth, this works fine in 1.2-SNAPSHOT
Are you sure? I have identified a regression in 1.1 over 1.0.1 that
really seems to arise from my changes in SimpleRelocator. I.e. I
boostrapped Maven 2.0.x once with Shade 1.0.1 (passed ITs) and once with
1.1 (failed
Vincent Siveton wrote:
What are the minimalist things that we need to check for a good Maven release?
[...]
Any others ideas?
Cross-compiling against the intended minimum JDK to catch accidental
usage of newer types/methods.
Checking for properly declared dependencies with the help of
Jason van Zyl wrote:
Author: jvanzyl
Date: Thu Jul 17 13:48:21 2008
New Revision: 677718
URL: http://svn.apache.org/viewvc?rev=677718view=rev
Log:
MSHADE-39: add a resource transformer that takes care of MANIFEST.MF files
Jason van Zyl wrote:
Ok, I have a new portable bundle.
Maybe you find this Windows batch file a useful addition:
@echo off
set dir=%~dp0
if %dir:~-1% == \ set dir=%dir:~0,-1%
set HUDSON_HOME=%dir%\runtime
if not exist %HUDSON_HOME% (
java -jar
Jason van Zyl wrote:
I replaced all the scripting with Velocity templating for all the jobs that are
created.
Another suggestion: In ExodusCli.java:45 replace
hudsonHome = System.getProperty(user.dir);
with
hudsonHome = new File(System.getProperty(user.dir),
runtime).getPath();
This
Jason van Zyl wrote:
I replaced all the scripting with Velocity templating
ExodusCli.java:70
w = new FileWriter(job);
Using
w = WriterFactory.newXmlWriter(job);
from plexus-utils instead would ensure proper output encoding for the
config.xml and improve platform independence of the
Jason van Zyl wrote:
Ok, I have a new portable bundle.
To get rid of the requirement on cygwin: You could use the Os class from
plexus-utils to detect Windows and set a flag in the Velocity context
for the templates. Using this flag, the templates could be tweaked to
use batch files
Brian E. Fox wrote:
What dependency on cygwin?
I am referring to this error while trying to build maven-2.1.x-IT-support:
[workspace] $ sh -xe snip\Temp\hudson39040.sh
The system cannot find the file specified
FATAL: Command execution failed
java.io.IOException: Cannot run program sh (in
Jason van Zyl wrote:
You've got the wrong bundle it appears. The new one:
-rw-r--r-- 1 jvanzyl jvanzyl 2441718 17 Jul 14:19 haven-1.0.jar
-rw-r--r--@ 1 jvanzyl jvanzyl 19810714 17 Jul 13:55 hudson.war
-rw-r--r-- 1 jvanzyl jvanzyl 119 17 Jul 15:37 start.bat
-rwxr-xr-x@ 1 jvanzyl
Jason van Zyl wrote:
There's a new bundle up there now.
OK, now I get:
440 create.sh
2.441.718 haven-1.0.jar
119 hudson.bat
142 hudson.sh
19.810.714 hudson.war
142 start.sh
DIR templates
Also, the
Mark Hobson wrote:
http://maven.apache.org/developers/mojo-api-specification.html
Under requiresDependencyResolution, If this annotation is present but
no scope is specified, the scope defaults to runtime.
What the Mojo API specification is meant to say is that the mere notation of
Hi,
during some debugging (Maven 2.0.9), I struggled with the expression
${settings.runtimeInfo.file}
returning null (instead of the path to the user settings file). Further
tracking led me to MavenCli.buildSettings() which calls
settings.setRuntimeInfo( createRuntimeInfo( commandLine,
Swindells, Thomas wrote:
What type should my variable var be in order to get at the xml?
A CDATA section [0] should allow you to pass the data through into an
ordinary string parameter:
configuration
var![CDATA[textxml attr=fooany xmlTag/xml]]/var
/configuration
Benjamin
[0]
Hi Oliver,
Author: olamy
Date: Sat Jul 26 12:13:48 2008
New Revision: 680030
URL: http://svn.apache.org/viewvc?rev=680030view=rev
Log:
[MCHANGES-118] AnnouncementMojo can only load velocity templates from
src/main/resources
+
+// MCHANGES-118 adding the user.dir path
+
Brett Porter wrote:
thanks - beat me to it :)
;-)
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Vincent Siveton wrote:
I tried to fix the IT since Hudson was unhappy. I specified svn
properties for UTF-16 file.
Vincent, I reverted part of your changes: In principle, the encoding of
the Java sources (input) and the HTML pages (output) is independent.
Also, the IT doesn't compile the
Vincent Siveton wrote:
Unfortunately, Huson is always unhappy...
Yep, but this time it left us some nice debug infos [0]: The generated
options file specifies -charset 'ISO-8859-1' but misses
docencoding. This is an indication that the IT build is using an
outdated version of the plugin
Brian Fox wrote:
The separate builds are using separate local repos. Everything should be
built and deployed to nexus so that should have the latest
Hm, not sure I understand you correctly. The log file of the first IT
build [0] reads
[INFO] snapshot
Brian E. Fox wrote:
The URL
http://localhost:8081/content/groups/public
is the Nexus facade for central, isn't it?
This is a logical grouping of all the repos on there, including the
snapshot repo that everything is deployed to.
OK, thanks!
Benjamin
Arnaud HERITIER wrote:
(but it can be create by copy from the one I
just added : https://ci.sonatype.org/job/maven-eclipse-plugin-trunk/).
Just a suggestion: We have Java 1.4 as the minimum requirement for all
the plugins, don't we? Then how about using a JDK 1.4 to run their ITs
to make
Hi,
while having a look at the recent failure during build #181 of
maven-shared, I noticed that the modules after the failing one were not
build at all (Build failed before it gets to this module).
Since the modules of maven-shared are not that tightly coupled, might it
be sensible to
nicolas de loof wrote:
I went into an issue with the release plugin :
java.lang.NoSuchMethodError: createArg
at
org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:79)
Just in case you didn't already find out yourself: The problem was that
Arnaud HERITIER wrote:
We have also always one executor frozen for 1 day :
maven-ant-plugin-trunkhttps://ci.sonatype.org/job/maven-ant-plugin-trunk/
Seems like the other build processor has also gone mad with
maven-2.0.10-RC :( Hudson is totally blocked and has already seven new
IT builds
Brian E. Fox wrote:
Fixed now, never seen that happen before so I'll keep an eye out.
Thanks! Can you also have a look at
https://ci.sonatype.org/job/maven-2.0.10-RC/2/console
I assume the job needs to be reconfigured to use Java 1.5 or each build
will deadlock again.
Benjamin
John Casey wrote:
To me, all of this points to a dire need to separate dependency metadata
from the POM that all of these derivative artifacts shares.
I could imagine this would also ease long-term interoperability of
different Maven versions with the repository. Imagine the day when the
Dennis Lundberg wrote:
Also, we need to add some IDE tricks to avoid these errors.
Yes, these errors were caught by IDEA.
Eclipse has likewise options to check javadocs (Window Preferences
Java Compiler Javadoc).
Benjamin
Arnaud HERITIER wrote:
What are the errors in javadoc tests ?
MJAVADOC-210, the plugin was searching for tools.jar which isn't found
on Mac, so the unit test to check the auto-detection of taglets failed.
I'm building it successfuly on Mac OS X.
Strange. How about the ITs, do they fail
Hi,
does the Nexus instance serving our Hudson have a certain latency with
regard to catching up with central? I am wondering since CI failed [0]
on maven-invoker which I updated to use the just released
plexus-utils:1.5.6 [1]
Benjamin
[0]
Tamás Cservenák wrote:
Central is _not_ proxied by Nexus, but is rsynced from repo1.maven.org
to repository.sonatype.org, and it is served from there by Nexus as
hosted repo. The problem is probably our rsync process (not [yet]
fired, or something).
Not that this solves your failed build, just
Brian E. Fox wrote:
Yep, I checked the crontab, it's actually running at 12:05 (CST) daily. I'll
still add the proxy.
OK, waiting a day (at most) isn't a major issue, not much things are
that urgent that a commit can't wait, you only need to know. But if
Hudson gets a real-time proxy to
Brian E. Fox wrote:
Yep, I checked the crontab, it's actually running at 12:05 (CST) daily. I'll
still add the proxy.
Yep, it's all set now. The intent was to minimize traffic over to central since
we had the mirror, but we can do both and it won't hurt anything.
Hm, is the proxy setup
Hi Vincent,
We solved around 30 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14120styleName=TextprojectId=11138
The handling of the charset parameter I proposed to Hervé in
MJAVADOC-206 gives rise to misbehavior. Imagine the following plugin
configuration:
Hi Wendy,
Olivier, would you be able to make the change you describe below on
the deploy plugin trunk?
The small change is to switch back to using the Install Plugin to
stage the artifact under test into the IT repo. I hope Oliver doesn't
mind that I went for this ;-)
Or can you explain
Dennis Lundberg wrote:
Is there something that's stopping us from releasing Maven Invoker 2.0.9
and Maven Invoker Plugin 1.2.1?
Not that I know of. I know Oliver had similar plans, so you two should
probably sync.
Benjamin
Vincent Siveton wrote:
So by default, we have now:
- encoding = ${project.build.sourceEncoding}
- docencoding = ${project.reporting.outputEncoding}
- charset = null
And if charset == null, charset = docencoding
Yes, as per MJAVADOC-182 and MJAVADOC-206, i.e. setting docencoding is
usually
Vincent Siveton wrote:
Nope. The code passed the encoding parameter *only* if it was not empty.
You're right, I forgot that the Maven JVM might be running with a
different default encoding than the system default that would be picked
by javadoc if encoding wasn't specified.
Yes but I
Wendy Smoak wrote:
Strangely, the integration test for MDEPLOY-45 is now failing for me,
complaining that it can't find maven-deploy-plugin 2.4-SNAPSHOT
[...]
I'd swear it worked initially, then
failed when I tried to release, and now it's failing just with 'mvn
install'.
So, I assume your
Hervé BOUTEMY wrote:
from a user point of view, why not: it will require more code from us to mimic
this, but the logic seems ok for me
You're right, the logic itself is not that bad. My remaining concern is
the minimal POM where we don't have a fixed source encoding, causing
Jason van Zyl wrote:
What about the default system encoding?
It would be part of the show for approach b). The effective encoding
would be determined by this chain:
report encoding - source encoding - system encoding
i.e. if report output encoding is not specified, fallback to source
Hi Dennis,
In light of MINVOKER-43, is it wise to specify Invoker Plugin 1.2 (which
suffers from that issue) in the parent?
Looking at the change log [0], Invoker Plugin 1.2 it not completely bad,
IMHO. MINVOKER-43 is limited to the invoker:install goal,
invoker:run should work better than
101 - 200 of 1109 matches
Mail list logo
