.
That's all kind of hacking. I would really appreciate some tweaks to the
testing harness that allows debugging using IDEs out-of-the-box.
Benjamin Bentmann
--
View this message in context:
http://www.nabble.com/Execution-of-a-AbstractMojoTestCase-test-from-within-Eclipse-tf4034442s177.html#a13433155
Benjamin Bentmann wrote:
I would really appreciate some tweaks to the testing harness that allows
debugging using IDEs out-of-the-box.
Well, it seems I just should have better studied the AbstractMojoTestCase:
Besides lookupMojo(), it offers configureMojo(). The later one gets the mojo
Benjamin Bentmann wrote:
The later one gets the mojo from the caller and hence needs no lookup from
the Plexus container.
A warning:
Not looking up the mojo from the container seems to have a drawback:
Injection of components into mojo fields annotated with @component is
disabled
by MNG-3118 and its
relatives/duplicates.
Benjamin Bentmann
--
View this message in context:
http://www.nabble.com/moving-forward-with-2.0.8-tf4796513s177.html#a13783818
Sent from the Maven Developers mailing list archive at Nabble.com
Benjamin Bentmann wrote:
... as requested by MNG-3118
MNG-2365 is a duplicate and could be closed as well. I attached a unit test
to this issue that checks the test class path ordering.
I would also like to point out trivial issues (documentation) that would
require less than an hour
source just to get a snapshot with a long awaited bugfix.
Furthermore, a shorter release cycle will produce more release artifacts,
giving users more possibilities to hack their POM if they find the latest
release not usuable.
Benjamin Bentmann
--
View this message in context:
http
Vincent Siveton wrote:
Could someone with rights activate the Wiki Renderer for Jira MNG project?
Here's another voice calling for this, and if it helps: P L E A S E !
;-)
Benjamin Bentmann
--
View this message in context:
http://www.nabble.com/Wiki-Renderer-for-MNG
it and vote.
Benjamin Bentmann
--
View this message in context:
http://www.nabble.com/clean-doesn%27t-process-additionalFileSets-consistently-tp14724042s177p14752001.html
Sent from the Maven Developers mailing list archive at Nabble.com
=xy,en
where xy denotes some other language supported by the plugin. Specifying
xy as the first locale will have the Maven Site Plugin change the JVM's
default locale to xy which in turn causes the lookup for en to fail as
outlined above.
Thanks for your attention,
Benjamin Bentmann
[0] http
elements for the different kinds
of source files, e.g. one for Java source files, one for resources, one for
scripts etc.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
ΣΣ.equalsIgnoreCase(σσ)
is true (because the lower case form of ΣΣ is σς).
Regards,
Benjamin Bentmann
[0]
http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase()
[1] http://cafe.elharo.com/blogroll/turkish/
[2]
http://java.sun.com/javase/6/docs/api/java/lang/Character.html
Please put it on the user proposal page on the wiki so we don't lose it.
Done:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Ciao!
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL
.
The problem is the length of the path, its exceeds 256 charactes. While the
Windows API can principally handle longer paths [0], applications need to
take special steps to get this behaviour. Your SVN client most likely does
not do this.
Benjamin Bentmann
[0]
http://msdn2.microsoft.com
or releases and Maven could detect this just
by looking at the project version.
Therefore I would like to ask whether a new profile activator like
nonSnapshot
to realize the above mentioned condition would be a wishworthy feature or is
generally not useful.
Regards,
Benjamin Bentmann
configuration properly. Once
that's setup, debug Maven as above described and when it comes to forking
the Surefire JVM, switch back to Eclipse and start the second launch
configuration to get both processes ready for a nice debug session.
Hope that helps,
Benjamin Bentmann
[0] http://maven.apache.org
is not on the good site. What do you think?
Regards,
Benjamin Bentmann
[0]
http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
If
you want unit tests, use JUnit, if you want function/integration tests, use
TestNG by punishing those that employ TestNG for the simple use-case. I am
neither a JUnit nor TestNG fanatic but I can't follow your XOR-like argument
here.
Benjamin Bentmann
--
View this message in context:
http
the expression by doubling the $. I just
verified this with Maven 2.0.8. If not already done, this subtle difference
might be worth an unit/integration test.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED
if the Maven Site Plugin did not previously set the
output directory (see also [0]).
Regards,
Benjamin Bentmann
[0] http://jira.codehaus.org/browse/MNG-3369
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
;'' :
Attempt to access property on undefined variable or class name
i.e. the Beanshell interpreter sees the literal expression instead of null.
Now, what is the right behavior or is this an intended change for Maven 2.1?
Thanks in advance,
Benjamin Bentmann
implementation of the execute() method that allowed report mojos
out-of-the-box to run standalone. Now, it just throws an exception and
people start to copy around code from other plugins. Am I missing a point
or is there something going wrong here?
Regards,
Benjamin Bentmann
it cannot become a
mysterious black-box. Of course it is tempting to develop new features or
fix bugs but where will one end if the documentation is never written?
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED
an in-depth understanding of
Maven's guts?
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
why do subclasses of AbstractMavenReport have to implement the abstract
methods getProject() and getSiteRenderer()? I couldn't find any callers of
these methods so what is their purpose?
Regards,
Benjamin Bentmann
to the super POM, this issue
should be fixed.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
the build here.
What I have found difficult is determining whether things *have* all
been locked down or whether something has been missed.
You could run
mvn clean deploy site-deploy -U
and grep for checking for updates in the log output.
Regards,
Benjamin Bentmann
.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
and rely on a public/documentated
command line switch.
Regards,
Benjamin Bentmann
[0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4127994
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
give a good example ;-)
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
. I think that's something plugin authors can do on their own.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I think another rule would be more appropriate.
Sounds reasonable, two different POM elements, two different rules. To make
things complete a third rule would be RequireSkinVersion.
Benjamin
-
To unsubscribe, e-mail:
I faced a problem that sounds like your
description.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
emitting to the XML. Of course, this would
require a decoding on the other side and also some additions to the XML
format (i.e. different attribute to hold the encoded string or additional
attribute to flag some other attribute/element as being encoded).
Regards,
Benjamin Bentmann
Please have a look at MSITE-279 before.
Sure! Could you send us a new patch on maven-doxia-tools?
Updated patch for MSITE-279.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
string? As for me, the answer is
No.
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
could easily
copy the code from AbstractSiteMojo but I thought it might be worth to ask
whether codeToLocale() could be a candidate to move into the new SiteTool
such that the code can be shared?
Regards,
Benjamin Bentmann
behavior back but ended again in some discussion:
- http://jira.codehaus.org/browse/SUREFIRE-446
-
http://www.nabble.com/testng%2C-surefire%2C-and-forkMode%3Dalways-to15323782.html
Regards,
Benjamin Bentmann
-
To unsubscribe, e-mail
) that does not filter locales
Approach b) would be my favorite. You could use this as a base for a
refactored getAvailableLocales() that simply filters the return value of the
other method.
Benjamin Bentmann
P.S.: DefaultSiteTool.java:937 should be site-tool instead of
site-plugin
I moved codeToLocale() to public.
Thanks Vincent!
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I want to see maven-plugin-plugin release before releasing
maven-plugins-parent. We did several major changes since the last
release (around 1 year) and only one issue is left.
Then please schedule MPLUGIN-73 for this release, too.
Benjamin Bentmann
maven-plugins (parent):
maven-site-plugin version should be 2.0-beta-6
It is already specified as 2.0-beta-6 in maven-parent.
maven-plugins overwrites this spec with 2.0-beta-5.
Benjamin Bentmann
-
To unsubscribe, e-mail
@requiresDependencyCollection
that does not retrieve JARs but only their metadata. The metadata could then
be retrieved from the reactor projects instead of a repository so I believe
this could at least help all those plugins that just do artifact metadata
analysis.
Regards,
Benjamin Bentmann
This is a good idea, can you add it to the atypical plugin use cases
page John put on docs.codehaus.org?
Left a comment at
http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases
that points to this thread.
Benjamin
I'd like to propose giving commit access to Paul Gier.
+1, I already wondered why this had not happened earlier ;-)
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
I would like to advertize the usage of java.util.LinkedHashMap and
java.util.LinkedHashSet. Unlike their close relatives HashMap and HashSet,
the former two collection classes offer a deterministic iteration order of
their elements by keeping the insertion order.
In general, clients will be
I'd like to know how many people are using ${plugin.artifacts} in
their plugins.
One here, basically for a use-case similar to MANTRUN-41 on some in-house
plugin.
This would mean that all of a sudden things like maven-plugin-api and
maven-project will start appearing in the result of $
Another question: How would the special don't-append-marker behave in
context of multiple parent POMs? I'm not fully familar with the project
builder but wouldn't the following sequence apply:
- grandfather POM defines url/##
- parent POM inherits url/## and fixes it to url/
- child POM inherits
* maven-plugin-tools-api-2.2
According to JIRA, the maven-plugin-tools-api-2.2 was released 2006-12-29:
http://jira.codehaus.org/browse/MPLUGIN/component/13118?selected=com.atlassian.jira.plugin.system.project:component-changelog-panel
Cleaning up JIRA to get in sync with the POMs and the
Will MPLUGIN and plugin tools have different release cycles?
Well, they already had: There is maven-plugin-plugin 2.1, 2.2 and 2.3 in
central but only maven-plugin-tools-api/maven-plugin-tools-java 2.1.
Benjamin
-
To
I think
for now we should move the testing-harness back out of the tools and
then create a new plugin-testing structure. There's not a good reason to
mix runtime plugin tools and things only used to test the plugins.
+1
Benjamin
Why does the configuration option require a bump in version?
The primary place for configurations regarding the build is the POM. A
new option means a change to the POM schema, a new schema means to bump the
version.
it is a perfect fit for 2.0.x as well.
Besides, you proposed to break the
I'm not having any luck staging the Javadoc plugin for a 2.4 release
I just added a patch for MJAVADOC-162 which was originally planned for this
release. If it's not too late, it would be cool to see it applied.
Benjamin
--
View this message in context:
I think I've been misunderstood. I am referring to the configuration
element that can contain whatever is necessary for configuration.
Oh, I see, but...
If the site is generated through a plugin, then by all means, configure
the plugin.
... this issue is about site deployment, not site
files without
the XmlStreamWriter, be sure to ensure the encoding used for the output
writer matches the encoding specified by the XML declaration being written.
Otherwise later parsing the output might fail.
Regards,
Benjamin Bentmann
[0] http://docs.codehaus.org/display/MAVENUSER/XML+encoding
[MJAVADOC-154] - Bump to plexus-utils:1.4.6
Hm, this task is linked to an issue about a defect in BourneShell. Another
BourneShell defect has been fixed in PLXUTILS-54 for plexus-utils:1.4.9.
Maybe worth to update once again to latest version?
Also, maven-javadoc-plugin:2.4 is known to ignore
Hi,
I have a small question about the following code snippet from a mojo that
requires the expert knowledge of the community:
/**
* @parameter expression=${list}
*/
List someList;
Is there any means in Maven/Plexus to actually populate this parameter from
the CLI? To my knowledge, only
Hi,
I noticed that Maven is using junit:3.8.1 quite everywhere for its tests
although a later maintenance release of the 3.x line exists with
junit:3.8.2. Is there a known issue with 3.8.2 that makes one stick to
3.8.1?
Benjamin
There's no need for maven-plugin-plugin in this pom. It is already in the
plugin parent pom.
If it doesn't cause any harm I believe it's still good to have for the sake
of better safe than sorry. Especially for those plugins that seem not to
inherit from maven-plugins:
- maven-release-plugin
Hi,
Puzzled by the situation, that some files have their svn:keywords set to
Author Date Id Revision
while others use
Author Date Id Revision
I did some googling and discovered that the first syntax is not valid.
The svn-eol-style.txt for the site is already updated [0], please do the
same
However, I do not understand why you say that MNG-3402 is dependent on a
doxia release? The aim of MNG-3402 is exactly to make maven independent of
the doxia version.
As Brett already said in JIRA, this might not work. For instance, the
DefaultPluginManager in maven-core depends on MavenReport
Hi,
today I learned that plexus-utils is not fully shaded in the core (MNG-2898,
r522313). While I can understand the requirement to share Xpp3Dom and the
Xml* APIs, I wonder why the MX* implementation classes cannot be shaded.
These aren't part of any public method signatures shared with
Hi,
the recent release of maven-eclipse-plugin:2.5 brought up
http://jira.codehaus.org/browse/MECLIPSE-404
which is caused by (windows) users specifying drive-relative paths to their
local repos.
Further progress on this issue would require some clarification:
Is Maven supposed to support
To get the latest version of maven-source-plugin into our toolchain and
use the recently release maven-plugin-plugin 2.4, I'd
like to release the plugins parent r638340 as version 11.
You could consider to lock down clean-plugin and resources-plugin, too.
Benjamin
Hi,
There are still several code spots in Maven that rely on the platform's
default encoding when processing text files which does support build
reproducibility. It could help developers to detect such defects if the CI
machines were configured to run Maven with
does this mean maven actually never worked fro japanese or chinese
developers?
It depends: As long as one sticks to US-ASCII when editing source files and
uses a platform encoding that has US-ASCII as a subset (UTF-8, Latin-X,
...), you won't notice Maven's misbehavior. Also, using Non-ASCII
Hi,
It seems there are currently two places in JIRA to fill in issues regarding
documentation:
- the components Documentation: * in project MNG and
- the project MNGSITE
Is this situation by design, i.e. are the projects/components intended for
different purposes/audiences, or could we move
But if we do so on a whole CI server, I fear the havoc will be bigger than
expected
I surely did not mean to do this immediately for the main CI builds. Given
Maven's current state, it's some future goal. Maybe we could setup a
secondary CI build job for this, such that people working on the
I can setup an alternate build for Maven.
Cool, thanks Brian.
What java options do I need to set to change the encoding?
Setting the system property file.encoding should do:
-Dfile.encoding=UTF-16
either via MAVEN_OPTS or directly on the java command line.
Benjamin
But whatever I don't care as long as it's easy and _obvious_.
Adding a description to the JIRA project MNG, that provides a hyperlink to
MNGSITE and some hinting words might further help to direct users to the
right place.
It took me over a minute to find the right project (and I knew that it
I found that one of my dependencies bundles some source in the jar... the
compiler plugin compiles it and it ends up in my artifact. Has anyone see
this before?
This could be unrelated to the plugin but be a general issue with javac. If
you read its tech docs [0], you notice that it reads
There is one feature in this patch I don't like: you hardcoded a default
encoding to ISO-8859-1 instead of no default value (which means platform
encoding).
Indeed, I also suggested using a fixed default value for other plugins:
- MCOMPILER-63
- MJAVADOC-165
- MRESOURCES-57
I simply chose
What about just unifying the expressions that refer to encoding in
plugins?
As an intermediate solution until Maven 2.1 provides an extended POM, this
seems like a good approach.
javadoc-plugin has ${encoding}
compiler-plugin has ${maven.compiler.encoding}
resources-plugin has no expression
If I don't miss an aspect, we could narrow the exclusions for the shade
plugin to
org.codehaus.plexus.util.xml.pull.Xml*
to allow plugins to benefit from updates to the MXParser and MXSerializer
independently of Maven.
What do you think?
No thoughts on this?
Benjamin
core plugins to be modified:
I moved this list over to the wiki article [0] in Confluence, think it's
easier to maintain there instead of being splattered through this mailing
thread.
This in place, plugin parameters could be written like
/**
* @parameter expression=${encoding}
*
Otherwise, plugins should by convention agree to handle a null value for
the encoding parameter to denote some fixed encoding. This way,
upgrading
Maven will not affect the default encoding behavior.
The convention has to be shared between every plugin and the super POM. I
dislike the pure
Author: hboutemy
Date: Sun Mar 30 05:03:00 2008
New Revision: 642720
URL: http://svn.apache.org/viewvc?rev=642720view=rev
Log:
fixed encoding when writing interpolated POM file
Modified:
maven/plugins/trunk/maven-invoker-plugin/src/main/java/org/apache/maven/plugin/invoker/InvokerMojo.java
-
[INFO] The PluginDescriptor for the plugin Plugin
[org.apache.maven.release:maven-release-manager] was not found.
build
plugins
plugin
groupIdorg.apache.maven.release/groupId
artifactIdmaven-release-manager/artifactId
+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
Could we make the AbstractMojo class more usefull by providing some
commonly-used support methods ?
+1 on the general idea to avoid copypaste, -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
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
in the example above.
Code targetting JRE 1.4+ should easily avoid these problems by using
new File( new URI( url.toString() ) )
when converting a URL to a filesystem path and
file.toURI().toURL()
when converting back.
Regards,
Benjamin Bentmann
[0] http://www.faqs.org/rfcs/rfc2396.html
[1
new File( new URI( url.toString() ) )
Correction:
JRE 1.4 is happily returning invalid/unescaped URLs from
ClassLoader.getResource(), making the above suggestion fail with a
URISyntaxException.
The new suggestion is to use FileUtils.toFile(URL) [0] from Commons IO. A
similar methods
Please clarify the proposal. When you say source files, you mean things
like Java files not POM files?
Yes, source file is meant to refer to a plain text file that does not have
an encoding declaration or similar like XML. XML is fine, it's ugly to parse
but provides the user with means to
I'd like to know if this could also be achieved via toolchains.
As Hervé already tried to explain, these two proposals have not too much in
common. To my understanding, the toolchain proposal aims at providing a
facade on a user's development kit (native tools, boot class path, etc.)
such that
I wonder if it's worth posting these as a series under the developers
section of the Maven site?
Vincent and I had already put parts of this stuff onto [0] in a section
named Some Pitfalls, together with a link to this mail thread. But I
agree, having all of this in a nicely formatted APT doc
Paul Benedict wrote:
My only concern is that the encoding kind of assumes one kind of source
file.
We are well aware that different kind of text files may use different
encodings. A simple example is using UTF-8 for Java source files and Latin-1
for properties files.
However, the primary goal
Jason van Zyl wrote:
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
I'm not really sure what you meant to say. JChardet is a library that
performs a best *guess* on file encoding by peeking at a byte stream. We
don't want to base our
Hervé Boutemy wrote:
this one is more tricky, even if the change in pom.xml is a simple
addition of
an element... Don't really know how to handle this without breaking things
for Maven 2.0 when an artifact with this addition is deployed to a
repository.
Handling POM additions is a more general
Jason van Zyl wrote:
If it's right most of the time, and it saves the user from having to know
or worry about it then yes I would use it.
Could you elaborate this a little more. Say we start easy and have a build
with just about 100 Java source files. Do you suggest to peek at each of
them
Martin von Gagern wrote:
if a newcomer like me is allowed to vote.
The more people participate in a discussion, the more likely is the result
to match public consensus rather than individual's preferences.
Suppose you have a huge source tree, mostly english ASCII, but somewhere
in there
Jason van Zyl wrote:
Possibly, but you're guessing.
Guessing about how much it will be slower, yes, guessing that it will be
slower, no. Additional work, additional time. Wouldn't you agree? Then the
question becomes, is it worth to take this overhead, or how much benefit do
you expect from
Jason van Zyl wrote:
What happens when the encoding is different then what is stated? Same
problem really, in how to deal with the actual versus declared.
If the declared encoding does not match the actual one, I simply call this
an user error. Either he explicitly set the wrong value or
IMHO, the best hint for a user choose his encoding when the default
ISO-8859-1
isn't a good valuie for him, is displaying platform encoding (in mvn -v
output for example): it's easy, reliable, and corresponds to the value he
would have got before the change
+1, just created MNG-3509 for this.
Taking this together, one might argue to have UTF-8 the default, not
ISO-8859-1.
In general, I completely agree with your preference to Unicode and fail-fast
behavior. If I had been involved when the Maven story started, I would have
proposed UTF-8 as the default value, no doubt.
As for today,
Make sure you consider the case where you have people developing the same
code base all over the world, and the possible reasoning of falling back
to platform default encoding. Consider the team spread across the US,
Russia, and China and what do they do normally?
This international spread
I see your point. Worth another vote? Or should this switch be postponed
to 2.1, trading consistency in minor version upgrades for a longer time
for these Latin1 defaults to be established?
[...]
So while I agree that a change in default either now or in the future is
ugly, it is not taboo, and I
Hi,
The guide Plugin Documentation Standard [0] linked to a page from the
Javadoc Plugin which was published back in 2006 [1]. Do we have means to
purge the output directory for the site on the web server to get rid of
those relics?
Benjamin
[0]
What is the purpose of having a modules element for our plugins? It's
not like we want to build all plugins in one go, is it?
Hudson used to do this if I remember correctly (the plugin ITs seem to have
been removed recently).
Benjamin
You could do it. Just go to people.apache.org and delete old files in
/www/maven.apache.org
Thanks, good to know. I just kicked the whole maven-javadoc-plugin dir and
redeployed the site from the 2.4 tag.
Ideally, deleting a directory should become a Wagon feature some day such
that manual
1 - 100 of 1109 matches
Mail list logo
