"TODOs".
This is key for us, and soon, as it helps to enable truly repeatable builds.
Thanks for the help,
--Matthew Beermann
to having truly repeatable builds. There are comments in
the code to the effect that this feature is planned, but I can't seem to find
the JIRA issue that tracks it...
--Matthew Beermann
On the documentation site for the WAR plugin
(http://maven.apache.org/plugins/maven-war-plugin/), the "Filtering war
dependencies" link is broken. Which is unfortunate, because that's exactly the
information I need right now. :P
--M
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60023 ]
Matthew Beermann commented on MNG-2049:
---
Except that it _does_. That's the entire point of both the tracebacks I
posted...
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60020 ]
Matthew Beermann commented on MNG-2049:
---
Right... but I think there's still a bug here: a failure (for any reason) to
find a given artifact on one repository should not fai
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_60013 ]
Matthew Beermann commented on MNG-2049:
---
Sorry for the slowness; I finally managed to capture this one in the act. The
artifactIds are snipped out, as the project is proprietary
[ http://jira.codehaus.org/browse/MNG-2110?page=comments#action_59857 ]
Matthew Beermann commented on MNG-2110:
---
Can you dupe this (or at least provide a link) so I can keep an eye on it?
> ArtifactRepositoryLayout isn't ex
[ http://jira.codehaus.org/browse/MNG-2110?page=comments#action_59816 ]
Matthew Beermann commented on MNG-2110:
---
Hm, it won't let me change the name of the issue, but a better summary line
might be: "Only certain components are extensi
License discovery is broken
---
Key: MCLOVER-21
URL: http://jira.codehaus.org/browse/MCLOVER-21
Project: Maven 2.x Clover Plugin
Type: Bug
Versions: 2.0
Reporter: Matthew Beermann
Priority: Critical
Fix For: 2.1
Even
ArtifactRepositoryLayout isn't extensible
-
Key: MNG-2110
URL: http://jira.codehaus.org/browse/MNG-2110
Project: Maven 2
Type: Bug
Components: Artifacts and Repositories
Versions: 2.0.2
Reporter: Ma
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_58129 ]
Matthew Beermann commented on MNG-2049:
---
I realize, but it exists in /my/ private repository. Is the issue here that an
artifact-not-found at any repository on the list is failing
[ http://jira.codehaus.org/browse/MNG-2049?page=comments#action_58127 ]
Matthew Beermann commented on MNG-2049:
---
Nope, it exists - in fact, it was already in my local repository as well.
> Dependencies without POMs cause intermittent failu
Reporter: Matthew Beermann
We have a number of jars in our repository that don't have POMs, e.g.
third-party libraries, etc. Maven happily downloads the jar anyway, and issues
a warning that there's no POM - except, sometimes, it just fails instead. See
the build log below. If I wer
[ http://jira.codehaus.org/browse/CONTINUUM-578?page=comments#action_57706
]
Matthew Beermann commented on CONTINUUM-578:
I filed a bug to that effect a while back and it was marked off as fixed, but
apparently not...
> Continuum doesn&#x
[ http://jira.codehaus.org/browse/MPIR-23?page=comments#action_57683 ]
Matthew Beermann commented on MPIR-23:
--
In the interests of full disclosure, I am doing one slightly strange thing, but
it seems like it ought to work anyway:
I've got a c
Crash when processing system-scoped dependencies
Key: MPIR-23
URL: http://jira.codehaus.org/browse/MPIR-23
Project: Maven 2.x Project Info Reports Plugin
Type: Bug
Versions: 2.0-beta-3
Reporter: Matthew
[ http://jira.codehaus.org/browse/MDEPLOY-22?page=comments#action_56849 ]
Matthew Beermann commented on MDEPLOY-22:
-
Is that a phase or a goal? Either way, it's undocumented AFAICT... if it does
what I'm trying for here, then morph this
[ http://jira.codehaus.org/browse/MDEPLOY-22?page=comments#action_56846 ]
Matthew Beermann commented on MDEPLOY-22:
-
I've got site:site and site:deploy attached to the deploy phase, which seems
like a reasonable sort of thing to do. As suc
distributionManagement/repository shouldn't be required
---
Key: MDEPLOY-22
URL: http://jira.codehaus.org/browse/MDEPLOY-22
Project: Maven 2.x Deploy Plugin
Type: Bug
Versions: 2.1
Reporter: Ma
Exported POM still has dependency version ranges
Key: MNG-2007
URL: http://jira.codehaus.org/browse/MNG-2007
Project: Maven 2
Type: Bug
Components: maven-archiver
Versions: 2.0.2
Reporter: Matthew
Make it possible to pay attention to .cvsrc
Key: MPSCM-74
URL: http://jira.codehaus.org/browse/MPSCM-74
Project: maven-scm-plugin
Type: Bug
Versions: 1.5
Reporter: Matthew Beermann
Fix For: 1.6
There
Add a way to indicate that path == sourcepath
-
Key: MECLIPSE-57
URL: http://jira.codehaus.org/browse/MECLIPSE-57
Project: Maven 2.x Eclipse Plugin
Type: Improvement
Versions: 2.0
Reporter: Matthew Beermann
[ http://jira.codehaus.org/browse/MPCHANGELOG-69?page=comments#action_56240
]
Matthew Beermann commented on MPCHANGELOG-69:
-
Works like a charm. Now if the equivalent bug (MOJO-78) could only get fixed in
Maven 2 as well... ;)
> Change
[ http://jira.codehaus.org/browse/MPCHANGELOG-69?page=comments#action_56212
]
Matthew Beermann commented on MPCHANGELOG-69:
-
Tested and NOT fixed! Unless the "maven.changelog.quoteDate" property needs to
take some value other
[ http://jira.codehaus.org/browse/MSITE-48?page=comments#action_56132 ]
Matthew Beermann commented on MSITE-48:
---
Might be a stupid question, but... if this bug is fixed, where do the skins
reside, exactly? If I enable the snapshots.maven.codehaus.org
Source Repository is confused by certain URLs
-
Key: MPIR-22
URL: http://jira.codehaus.org/browse/MPIR-22
Project: Maven 2.x Project Info Reports Plugin
Type: Bug
Versions: 2.0-beta-3
Reporter: Matthew
[ http://jira.codehaus.org/browse/MNGECLIPSE-22?page=all ]
Matthew Beermann updated MNGECLIPSE-22:
---
Attachment: eclipse30_build_errors.txt
> The Plug-In fails to run under Eclipse 3.0.x and IBM Rational Developer (
[ http://jira.codehaus.org/browse/MNGECLIPSE-22?page=all ]
Matthew Beermann updated MNGECLIPSE-22:
---
Attachment: eclipse30_build_errors.JPG
> The Plug-In fails to run under Eclipse 3.0.x and IBM Rational Developer (
[ http://jira.codehaus.org/browse/MNGECLIPSE-22?page=comments#action_55744
]
Matthew Beermann commented on MNGECLIPSE-22:
Any chance that it could be put into the scope? Heck, I'd even put a bounty on
it if that's what it
[ http://jira.codehaus.org/browse/MCOMPILER-22?page=comments#action_53959 ]
Matthew Beermann commented on MCOMPILER-22:
---
Addendum: I had true attached to the compiler; removing that
seemed to fix the issue. This may be related to a more general
Compilation fails: "The command line is too long."
--
Key: MCOMPILER-22
URL: http://jira.codehaus.org/browse/MCOMPILER-22
Project: Maven 2.x Compiler Plugin
Type: Bug
Reporter: Matthew Beermann
Assigned
[ http://jira.codehaus.org/browse/CONTINUUM-354?page=comments#action_53852
]
Matthew Beermann commented on CONTINUUM-354:
No, CONTINUUM-330 didn't solve this. Here's why:
1. Add a new to the parent project and check in.
2. Rebuild
[ http://jira.codehaus.org/browse/MNG-1800?page=all ]
Matthew Beermann closed MNG-1800:
-
Resolution: Fixed
Fix Version: (was: 2.0.3)
Turns out that this wasn't directly caused by MNG-441 or MNG-1303, but the
resolution of those allow
Continuum should use Server VM
--
Key: CONTINUUM-511
URL: http://jira.codehaus.org/browse/CONTINUUM-511
Project: Continuum
Type: Improvement
Components: Core system
Versions: 1.0.2
Reporter: Matthew Beermann
Priority
[ http://jira.codehaus.org/browse/MNG-1800?page=comments#action_53283 ]
Matthew Beermann commented on MNG-1800:
---
Just to be clear, the mechanism we're utilizing is documented here:
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Se
[ http://jira.codehaus.org/browse/MNG-1795?page=comments#action_53279 ]
Matthew Beermann commented on MNG-1795:
---
Nope, same result.
> eclipse:eclipse still setting .classpath's output to wrong d
[ http://jira.codehaus.org/browse/MNG-1800?page=comments#action_53278 ]
Matthew Beermann commented on MNG-1800:
---
No, it hasn't, at least as of surefire-booter:jar:1.5-20051212.092836-3. Still
able to locate the resources inside a jar but no
[ http://jira.codehaus.org/browse/MNG-1800?page=comments#action_53172 ]
Matthew Beermann commented on MNG-1800:
---
May be related to MNG-1303, since that bug changed the way the
IsolatedClassLoader works...
> surefire:test finds a resource inside a
maven-surefire-plugin
Versions: 2.0
Reporter: Matthew Beermann
Priority: Critical
Fix For: 2.0.1
We're using Java's SPI mechanism to load implementations at runtime. To be
exact, the iface jar looks for a particular file (using
ClassLoader.getResource) when
[ http://jira.codehaus.org/browse/MNG-1795?page=comments#action_53157 ]
Matthew Beermann commented on MNG-1795:
---
No, that's what I'll probably do in production, but if I understood
http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse
lugin
Versions: 2.0
Reporter: Matthew Beermann
Fix For: 2.0.1
When I run:
mvn -Dproject.build.outputDirectory=bin eclipse:eclipse
...the resulting .classpath file still has:
This looks like exactly what MNG-907 was meant to fix, and I think I have that
fix if I have version 2
Notifiers should be optional
Key: CONTINUUM-492
URL: http://jira.codehaus.org/browse/CONTINUUM-492
Project: Continuum
Type: Bug
Components: Core system
Versions: 1.0.1
Reporter: Matthew Beermann
Fix For: 1.0.2
[ http://jira.codehaus.org/browse/CONTINUUM-481?page=comments#action_52434
]
Matthew Beermann commented on CONTINUUM-481:
Well, then, I would put it this way:
When you run "InstallService.bat", Continuum uses the default service sett
[ http://jira.codehaus.org/browse/CONTINUUM-481?page=comments#action_52233
]
Matthew Beermann commented on CONTINUUM-481:
In fact, that command line ("cvs -f -q update -d") is DEFINITELY wrong - if I
enter that manually, CVS fails wit
[ http://jira.codehaus.org/browse/CONTINUUM-481?page=comments#action_52231
]
Matthew Beermann commented on CONTINUUM-481:
Nevermind those log lines; it was just trying to tell me that it didn't need to
update .cvspass. The bug still s
2003 SP1
Reporter: Matthew Beermann
Priority: Critical
Fix For: 1.0.2
Continuum seems to ignore the .cvspass file while building my projects,
resulting in the error: "Empty password used - try 'cvs login' with a real
password". Note that our CVS repository doe
[ http://jira.codehaus.org/browse/MNG-1136?page=comments#action_49027 ]
Matthew Beermann commented on MNG-1136:
---
I have exactly the plugin configuration mentioned above, and I'm trying to
instrument a code that contains an assertion. Nothing
[ http://jira.codehaus.org/browse/MNG-1222?page=comments#action_48739 ]
Matthew Beermann commented on MNG-1222:
---
Okay, I see the comment now - it would be nice if this had actually gone out in
the beta-3 plugin. :S
// the
site:site goal is completely broken
---
Key: MNG-1222
URL: http://jira.codehaus.org/browse/MNG-1222
Project: Maven 2
Type: Bug
Components: maven-site-plugin
Versions: 2.0-beta-3
Reporter: Matthew Beermann
Priority
[ http://jira.codehaus.org/browse/MNG-1136?page=comments#action_48581 ]
Matthew Beermann commented on MNG-1136:
---
...but I can try to make it easy if someone's got a build environment and knows
how the POM works: it's at l
Need a way to poll for new projects
---
Key: CONTINUUM-354
URL: http://jira.codehaus.org/browse/CONTINUUM-354
Project: Continuum
Type: Improvement
Versions: 1.0-beta-1
Reporter: Matthew Beermann
Fix For: 1.0
The
[ http://jira.codehaus.org/browse/MNG-1136?page=comments#action_48449 ]
Matthew Beermann commented on MNG-1136:
---
I'm afraid not, no.
> clover breaks when encountering assert st
[ http://jira.codehaus.org/browse/MNG-1136?page=comments#action_48436 ]
Matthew Beermann commented on MNG-1136:
---
I don't think it's a problem with Clover; rather, the attribute from
the compiler:compile goal isn't getting propa
Reports should be alphabetized
--
Key: MNG-1170
URL: http://jira.codehaus.org/browse/MNG-1170
Project: Maven 2
Type: Improvement
Components: maven-site-plugin
Versions: 2.0-beta-3
Reporter: Matthew Beermann
Priority
-beta-2
Reporter: Matthew Beermann
Priority: Minor
If you have a developer with the attribute "http://foo", on the
project team page this will come out looking like "{http://foo, http://foo}";.
While I'm here, I'm not sure what the column "Actual Ti
[ http://jira.codehaus.org/browse/MNG-1031?page=comments#action_47358 ]
Matthew Beermann commented on MNG-1031:
---
At the risk of being dumb, can you give me an example of how that might work?
Also, is there any way to tell, in general, which attributes
connectionUrl shouldn't always be required
--
Key: SCM-56
URL: http://jira.codehaus.org/browse/SCM-56
Project: Maven SCM
Type: Bug
Components: maven-plugin
Versions: 1.0-alpha-2
Reporter: Matthew Beermann
[ http://jira.codehaus.org/browse/MNG-1031?page=comments#action_47311 ]
Matthew Beermann commented on MNG-1031:
---
The parent POM doesn't live anywhere in CVS, it's just sitting in the local
repository. It's there to mainly to categoriz
[ http://jira.codehaus.org/browse/MNG-1031?page=comments#action_47309 ]
Matthew Beermann commented on MNG-1031:
---
Not my repository, so I'm afraid I probably can't restructure it...
> SCM connection attribute being inherite
: Matthew Beermann
(Not sure of the correct component, but taking a stab at it...)
It appears that the attribute of is being modified as it is
inherited, but not correctly. For example, if my parent project had something
like:
scm:cvs:pserver:[EMAIL PROTECTED]:/projects:
...then the final
Sending wrong parameters to -bottom
---
Key: MNG-1029
URL: http://jira.codehaus.org/browse/MNG-1029
Project: Maven 2
Type: Bug
Components: maven-javadoc-plugin
Versions: 2.0-beta-2
Reporter: Matthew Beermann
Priority
[
http://jira.codehaus.org/browse/MPCRUISECONTROL-35?page=comments#action_44553 ]
Matthew Beermann commented on MPCRUISECONTROL-35:
-
Upon closer inspection, I'm really talking about Cruise Control's
"spamwhilebroken"
Versions: 1.7
Environment: Maven 1.0.2
Reporter: Matthew Beermann
Priority: Minor
Fix For: 1.8
It seems like there ought to be a maven.cruisecontrol.mail.report=always
property, rather than simply a maven.cruisecontrol.mail.reportsucess=always
property. I have often had the
63 matches
Mail list logo
