It's a pity these two didn't make it in:
https://issues.apache.org/jira/browse/MNG-6261
https://issues.apache.org/jira/browse/MNG-6262
These are true showstoppers for Windows users (like us).
Dawid
On Tue, Oct 17, 2017 at 8:15 PM, Stephen Connolly
wrote:
> This vote, despite being successful,
Scholte wrote:
>>
>>> Vote for maven-javadoc-plugin 3.0.0-M1 has started[1], please verify.
>>>
>>> thanks,
>>> Robert
>>>
>>> [1] http://markmail.org/message/4nssutboqsahx5kb
>>>
>>>
>>> On Thu, 13 Jul 2017 11:04
> IIUC the failing project isn't always failing. This could be an explanation.
I didn't say it isn't always failing -- I said it is failing
deterministically (as in: always) from the same location, but
sometimes isn't failing on the same project when executed from
*another* location.
I know what
Thanks, I'll dig and let you know if I can figure it out. (or not).
Dawid
> https://maven.apache.org/ref/3.5.0/maven-resolver-provider/
> This is the module responsible for resolving parents, dependencies, etc.
>
> https://github.com/apache/maven
> Here it is at github
>
>> Adding -X doesn't real
> Have you double checked file permissions? if it can't read the parent
> pom (maybe not all dirs are +x etc) then it wil have the behavior you
> see
Come on, guys. :) I wouldn't ask if I didn't try it in many multiple
combinations. It is a heisenbug, but the reason for it is not a
trivial mistak
> There must be a difference between the 2 projects.
There is no difference. It's the same repo on the same commit, I
called "git clean -xfd ." prior to executing those maven commands (and
obviously there are no other changes).
> But as long as there's no attachment which reproduces the issue, we
ling project is really required to fix this.
>
> Robert
>
>
> On Thu, 27 Jul 2017 13:41:16 +0200, Dawid Weiss
> wrote:
>
>> Hello,
>>
>> Just wanted to hear if anybody has any idea about MNG-6261 I filed
>> recently -- there is a relatively simple repro attach
Hello,
Just wanted to hear if anybody has any idea about MNG-6261 I filed
recently -- there is a relatively simple repro attached and it fails
with Maven 3.5.0+; I've been wondering if it's a bug or an illegal
abuse of the submodule/parent pom relationship.
Dawid
> So the best I can do is to have a look at the open J9 and M3 issues and
> decide if I should create an early 3.0.0-M1 version.
Not trying to put pressure on you (or anybody else), Robert. (Well,
maybe, but only a mild one. :) Just saying that Maven (and its
plugins) are an important piece of inf
more on the javadoc plugin
>
> Robert
>
>
> On Wed, 12 Jul 2017 09:01:12 +0200, Dawid Weiss
> wrote:
>
>> Oh, yes -- please, please...
>>
>> Dawid
>>
>> On Tue, Jul 11, 2017 at 10:57 PM, Peter Ansell
>> wrote:
>>>
>>> Releas
Oh, yes -- please, please...
Dawid
On Tue, Jul 11, 2017 at 10:57 PM, Peter Ansell wrote:
> Releasing the javadoc plugin with its Java 9 fixes in parallel would also be
> great to have both of them ready to go on the GA date.
>
> Cheers,
>
> Peter
>
>> On 11 Jul
Hello there,
Is there any schedule to release maven-enforcer with Java 1.9
compatibility fixes?
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
> I considered, even, sending email proposing to remove the
> long-deprecated goals from this plugin.
Not a Maven committer, but I'm with Benson on this one. If there is an
opportunity to clean it up, please do it. When I upgrade POMs to new
major versions I'd expect them to fail if I keep using s
> Net result is that `mvn4 test` will work without having to populate the
> remote repo or local cache.
>
> Thoughts?
Oh, yes, yes, yes... bring it in. The intermediate install is so
problematic, especially on multi-threaded environments (think of
integration servers running multiple builds of the
There is also a very cool tool from the Lucene land, written by Uwe Schindler --
https://code.google.com/p/forbidden-apis/
This lets you selectively forbid certain methods from your codebase
(and the default list of forbidden methods has a strong rationale to
be discouraged -- locale-sensitive me
There is no cygwin-specific Java, so why would it be supported?
Dawid
On Mon, Nov 17, 2014 at 6:40 PM, Kristian Rosenvold
wrote:
> I was slightly surprised that this call does not work on cygwin, which
> somehow seems to indicate file attribute support for windows platform
> seems unsupported..
I agree with Anders, no surprise principle. Fail early. I spent a good
while trying to figure out what the heck is happening with this --
http://jira.codehaus.org/browse/MASSEMBLY-724
Dawid
On Thu, Oct 30, 2014 at 1:05 PM, Anders Hammar wrote:
> Wouldn't it make sense to fail the build in case o
Hi Holger,
> I am quite certain the problem has to do with tiered compilation being
> on by default in JDK8 and kicking in/still
Isn't it on by default in JDK7 as well (last I can remember it was
turned on in one of the builds and stayed on).
Dawid
--
> I don't know where I'm going to get that environment.
Everything is still accessible in Oracle Java Archive:
http://www.oracle.com/technetwork/java/archive-139210.html
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apac
> It would be quite simple to have a thread in the forked process
> simply pulsing a heartbeat back to the plugin ?
>
> And if 3 heartbeats are missed, we simply kill it ? (Pardon the pun ;)
Yeah, I sort of have that already but not in a background thread form
(it's a longer story). Anyway, a back
Thanks Martin. My question was in fact not user-based but
developer-based. I'm developing an alternative JUnit runner for
Lucene/Solr builds and we hit lots of exceptional situations. Permgen
errors are kind of hard to deal with because after you hit it there
are very few recovery options (short of
Hi. Just wanted to ping you because I remember we talked about
hardnuts for test runners (like surefire). I've been recently trying
to think of a way to shutdown the forked JVM cleanly on permgen/ OOM
conditions (and signal it back as such to the controlling process).
Seems to be quite hard because
> I'll take a look at that. The only thing new to surefire in this patch
> is really dynamic allocation of tests to forked processes, since all
> the other stuff you mention is already supported.
Well, it's a lot more than just that ;) But I agree most of this stuff
(randomization, thread leak de
> If you have tests like that you end up having to use a new process for each
> test class. That's like having to decide between forkMode once and always
> in the single-threaded configuration. But yes, I've seen such tests as well
> :).
I agree that running a suite-per-jvm is the ultimate isolati
> some of the awesomest stuff I've seen in a long while, I simply have
I implemented such stuff for Apache Lucene/ Solr a while back, it's
been running for quite a while now. It's not technically Maven (it's
an Ant task) but a Maven plugin wrapper for it is also provided and
does an equivalent thi
> (Making your JAR files uncompressed and then the WAR file compressed
> sounds weird to me...?)
This may actually make sense since zipping an uncompressed ZIP file
will be more like tar/gz and will result in better compression
performance (because zip dictionaries are contiguous over multiple
fil
/ on the front of a
> path. See MSHADE-119; comes from
> getClass().getResource("/a/b/c.properties").
> return path.startsWith( pathPattern ) || path.startsWith ( "/"
> + pathPattern );
>
>
>
> On Sat, May 26, 2012 at 2:05 PM, Dawid Weiss wrote:
>
> That log message, however, is nuts. Searching in classpath and then
> logging that file path? I'd file that as a bug in Velocity.
It is definitely an bad code pattern -- should be either
class-relative resource or searched via
classloader, not class + '/' prefix). I see this from time to time
th
Ideally, this should be configurable via plugins because there is
simply no way to predict what people may come up with?
The relevant fragment from velocity is not even consistent -- look:
inputStream =
getClass().getResourceAsStream("/org/apache/velocity/runtime/defaults/velocity.properties");
> 4) svn remove all files in the metadata now absent from the tree, add
> all new files.
Ah... this would be so easy with git --
git add -A .
Dawid
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional comma
That piece of code was implemented for ANT and only later ported into
a Maven plugin/ mojo. I have no doubt that taking the code directly
won't work because of architectural differences between the projects
and like most people I too have too much work and too little time so
delving into surefire's
> We don't have the two-way comms channel between the plugin and the fork in
> surefire which means it's all precalculated.
Yes, I know.
> There are certainly benefits/drawbacks
> to both approaches. My personal use-case involves extremely long-running
> tests and of
> extreme variation in run-t
> Based on data from pervious runs, this setting optimizes the runorder
> of the tests to minimize total run-time.
This is a digression, but I think may be inspirational.
Kristian's description matches how I implemented per-jvm balancing in
our JUnit4 runner initially and I have a suggestion on h
Hi there,
I've been eyeballing various bits and snippets of Maven for a few
hours but I can't see any pattern of right usage for resolving
transitive dependencies of an artifact at runtime (from a plugin). I
would like to require Maven 3, so I'm interested in Maven 3's
infrastructure for basically
34 matches
Mail list logo
