I should start by saying that I haven't followed the entire thread on this
subject, so if something I say here has been beat to death elsewhere just
write me off as a lurker and go on...
I have started specifying versions for all lifecycle plugins in my "company
POM" with the hopes that would
-
all the reports show 0 coverage.
Ralph
Bob Allison wrote:
Sounds like the well-known Cobertura 2.1 problem. Try explicitly
specifying version 2.0 of the plugin and see if that fixes it.
- Original Message - From: "drekka"
<[EMAIL PROTECTED]>
To:
Sent: Wednesday, Fe
Sounds like the well-known Cobertura 2.1 problem. Try explicitly specifying
version 2.0 of the plugin and see if that fixes it.
- Original Message -
From: "drekka" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 07, 2007 1:13 AM
Subject: Lifecycle issues with Cobertura plugin and c
The RPM plugin I wrote in Codehaus uses a subdirectory of
"${basedir}/target" as the place where everything to be packaged is
assembled. This should mean that the _BUILD_ of an RPM can run in parallel
with another _BUILD_.
It is always going to be bad form to try to do multiple _INSTALL_ acti
ween the original project
creator and the spec writer.
Cheers,
- Ole
--- Bob Allison <[EMAIL PROTECTED]> wrote:
You might take a look at the RPM plugin in the Mojo
sandbox...
- Original Message -
From: "Ole Ersoy" <[EMAIL PROTECTED]>
To: "Maven Developers Li
You might take a look at the RPM plugin in the Mojo sandbox...
- Original Message -
From: "Ole Ersoy" <[EMAIL PROTECTED]>
To: "Maven Developers List"
Sent: Sunday, December 24, 2006 4:38 PM
Subject: Request for Summary element in POM
Hi,
I'm in the process of releasing an RPM Spec
I have only been half following this thread so please excuse me if what I
say is OT or repeats what someone else said.
As the author of the RPM plugin, I think I can safely say that we could
easily build RPMs of each Maven release (containing the same content as the
tarball) that installs by d
[ http://jira.codehaus.org/browse/MNG-2039?page=comments#action_57866 ]
Bob Allison commented on MNG-2039:
--
The NetBeans-Freeform plugin is currently in the Mojo sandbox. I believe you
need to build it from source.
> Fails to install netbeans-freef
[ http://jira.codehaus.org/browse/MCOMPILER-13?page=comments#action_55628 ]
Bob Allison commented on MCOMPILER-13:
--
I should probably add that the mock object sources are in a different source
tree than the implementation sources, as opposed to merely
[ http://jira.codehaus.org/browse/MCOMPILER-13?page=comments#action_55627 ]
Bob Allison commented on MCOMPILER-13:
--
If we use a profile to change the sourceDirectory, how do I do the following in
a single build (since this has to run from the reactor
Improve methods to define the scope and packaging of dependencies
-
Key: MNG-1732
URL: http://jira.codehaus.org/browse/MNG-1732
Project: Maven 2
Type: Improvement
Versions: 2.0
Reporter: Bob
Reporter: Bob Allison
It looks like we have some problems with the contents of manifests in jar files.
According to Sun's documentation
(http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic
formatting rules which are not always being enforced:
1) All text mu
[ http://jira.codehaus.org/browse/MNG-1445?page=all ]
Bob Allison updated MNG-1445:
-
Attachment: MNG-1445-testcase.zip
The attached test case contains two projects:
-- testplugin creates a simple plugin
-- test references the plugin
To replicate the
NPE thrown when parsing bad plugin jar
--
Key: MNG-1445
URL: http://jira.codehaus.org/browse/MNG-1445
Project: Maven 2
Type: Bug
Versions: 2.0
Environment: Java 1.5.0 on Linux
Reporter: Bob Allison
Due to a
[ http://jira.codehaus.org/browse/MNG-1174?page=comments#action_48421 ]
Bob Allison commented on MNG-1174:
--
Holding off is not a problem.
I had started to try to build this as a separate plugin that leveraged off of
the compiler plugin code. Although I
[ http://jira.codehaus.org/browse/MNG-1174?page=all ]
Bob Allison updated MNG-1174:
-
Attachment: pom.xml
The build section from a POM which shows how to use the new mojos
> New Mojos for compiler and jar plugins to allow alternate j
[ http://jira.codehaus.org/browse/MNG-1174?page=all ]
Bob Allison updated MNG-1174:
-
Attachment: AltJarMojo.java
AltJarMojo is identical to JarMojo except:
-- Goal changed to "altjar"
-- Parameter "outputDirectory" renamed to &quo
[ http://jira.codehaus.org/browse/MNG-1174?page=all ]
Bob Allison updated MNG-1174:
-
Attachment: AltCompilerMojo.java
The AltCompilerMojo is identical to CompilerMojo except:
-- Goal changed to "altcompile"
-- A parameter "suffix" ad
: Linux using JDK 1.5.0_01
Reporter: Bob Allison
Fix For: 2.0-beta-4
Add mojos so that mock objects and other affiliated source roots can be
compiled and packaged in the same project
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
[ http://jira.codehaus.org/browse/MNG-1041?page=comments#action_47677 ]
Bob Allison commented on MNG-1041:
--
I don't think I can use this for my mocks, and here's why:
I have proj-a and proj-b, both of which have unit tests in src/test. Proj-b
[ http://jira.codehaus.org/browse/MNG-1045?page=comments#action_47477 ]
Bob Allison commented on MNG-1045:
--
Not being up-to-speed on all the details of the DAG process, this may not be
possible, but...
How about this approach: Do not automatically add
release
Reporter: Bob Allison
My Maven 2 project tree consists of a parent directory with a pom.xml and a set
of child projects in subdirectories of the parent directory. In the parent
project, I am using a pair of properties to define the build version as follows:
3.0
-SNAPSHOT
[ http://jira.codehaus.org/browse/MNG-690?page=all ]
Bob Allison updated MNG-690:
Attachment: MNG-690.diff
Based the previous file starting at the wrong directory. This one should be
correct.
> Make text in appear the same size as the rest of the t
[ http://jira.codehaus.org/browse/MNG-794?page=comments#action_46981 ]
Bob Allison commented on MNG-794:
-
Retried this with beta-1 and it appears to be working now. Probably fixed
while fixing other deployment issues.
> Deploy fails with
[ http://jira.codehaus.org/browse/MNG-690?page=all ]
Bob Allison updated MNG-690:
Attachment: MNG-690.diff
This patch updates the current maven-theme.css to correct this problem.
> Make text in appear the same size as the rest of the t
Allow goals such as "clean:clean" to be specified as "clean"
Key: MNG-971
URL: http://jira.codehaus.org/browse/MNG-971
Project: Maven 2
Type: Improvement
Versions: 2.0-beta-1
R
[ http://jira.codehaus.org/browse/MNG-875?page=comments#action_46512 ]
Bob Allison commented on MNG-875:
-
Took out all of my mirrors from settings.xml; the same it tests still fail.
Must be related to the release process.
> Duplicate repository
[ http://jira.codehaus.org/browse/MNG-875?page=comments#action_46495 ]
Bob Allison commented on MNG-875:
-
OK. I backed out the changes of this patch and tried to build m2 with
"snapshots" mirrored from "http://snapshots.maven.codehaus.o
[ http://jira.codehaus.org/browse/MPJCOVERAGE-33?page=comments#action_46493
]
Bob Allison commented on MPJCOVERAGE-33:
So searching the source for "metod" won't find the typo?
> XmlPullParserException
> --
[ http://jira.codehaus.org/browse/MPJCOVERAGE-33?page=comments#action_46490
]
Bob Allison commented on MPJCOVERAGE-33:
To me, this looks like a typo in the XML. In the stanza for class
"com.ai.utils.rule.RuleBean" the tag is closed
[ http://jira.codehaus.org/browse/MNG-875?page=comments#action_46487 ]
Bob Allison commented on MNG-875:
-
Does that mean that the m2 POMs no longer reference
snapshots... and
snapshots as diffrent URLs?
That is what the patch fixes.
> Duplic
Javadoc fails to include libraries
--
Key: MNG-891
URL: http://jira.codehaus.org/browse/MNG-891
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Environment: SVN revision 280814 on Linux using JRockit 1.4.2
Reporter: Bob
-1
Reporter: Bob Allison
Priority: Minor
Attachments: fix-repos-id.patch
Within the Maven 2 codebase, two different development repositories are given
the "snapshots" ID. Because the repositories are at different web addresses,
it is impossible to specify a mirror which sati
: SVN revision 279038 on Linux
Reporter: Bob Allison
Attachments: CheckstyleReport.diff
After updating from revision 278582, the checkstyle plugin fails with the
following:
Caused by: org.apache.maven.reporting.MavenReportException: Invalid
configuration file format: sun
at
[ http://jira.codehaus.org/browse/MNG-139?page=comments#action_45474 ]
Bob Allison commented on MNG-139:
-
One place where problems can occur is using a mirror for codehaus while
building m2. In the m2 top-level plugin, there is a repository named
Deploy fails with NPE
-
Key: MNG-794
URL: http://jira.codehaus.org/browse/MNG-794
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Environment: SVN revision 240249 on Linux
Reporter: Bob Allison
Trying to deploy a project (I have tried
JavadocReport throws NPE
Key: MNG-779
URL: http://jira.codehaus.org/browse/MNG-779
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Environment: SVN revision 239419 on Linux
Reporter: Bob Allison
Running site:site on a project
[ http://jira.codehaus.org/browse/MNG-754?page=comments#action_44953 ]
Bob Allison commented on MNG-754:
-
I ended up having to rebuild my repository (both my local repository and the
one I deploy to). Now, I cannot duplicate the problem. My guess is that
[ http://jira.codehaus.org/browse/MNG-755?page=comments#action_44949 ]
Bob Allison commented on MNG-755:
-
I wasn't sure if this was one bug or two. I did not know if the NPE was a
result of using the "Default Maven Project" or something di
[ http://jira.codehaus.org/browse/MNG-755?page=comments#action_44747 ]
Bob Allison commented on MNG-755:
-
It looks like "m2 -fn" exhibits the same behavior.
> Running "m2 -fae" does
Running "m2 -fae" does not use POM or reactor
-
Key: MNG-755
URL: http://jira.codehaus.org/browse/MNG-755
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Environment: SVN revision 233464 on Linux
Rep
[ http://jira.codehaus.org/browse/MNG-754?page=comments#action_44743 ]
Bob Allison commented on MNG-754:
-
I have to take back something I said. It turns out that the problem does not
go away with a POM for the app server's library jar. At least,
[ http://jira.codehaus.org/browse/MNG-754?page=comments#action_44741 ]
Bob Allison commented on MNG-754:
-
Looking at the artifact that it is complaining about, it is one that depends on
a jar which I copied from my app server's library and placed i
[ http://jira.codehaus.org/browse/MNG-754?page=all ]
Bob Allison updated MNG-754:
Attachment: ActiveProjectArtifact.diff
With this patch, the exception reads:
Caused by: java.lang.IllegalArgumentException: Can't find a valid Maven project
in the repos
Exception thrown building site
--
Key: MNG-754
URL: http://jira.codehaus.org/browse/MNG-754
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Environment: SVN revision 233464 on Linux
Reporter: Bob Allison
Starting a new project
: Improvement
Versions: 2.0-beta-1
Reporter: Bob Allison
Priority: Minor
In our Maven 1.0.2 build environment, we went to the trouble of building a
replica of the ibiblio repository on a local machine because we would have
builds hang for minutes if ibiblio decided to hiccup while the build was
[ http://jira.codehaus.org/browse/MNG-747?page=comments#action_44679 ]
Bob Allison commented on MNG-747:
-
Updated my SVN tree and tried things again. Works fine.
> Javadoc classpath does not match compiler classp
ET)
Reporter: Bob Allison
Project A depends on library X with scope "provided".
Project B depends on project A with scope "provided" but also uses library X.
When compiling project B, there is no need to declare the dependency on library
X. Trying to build the JavaDoc
[ http://jira.codehaus.org/browse/MNG-745?page=comments#action_44640 ]
Bob Allison commented on MNG-745:
-
I'm not worried about the build ID being part of the artifact, I was looking at
the file xx-SNAPSHOT.version.txt that is placed in the repos
[ http://jira.codehaus.org/browse/MNG-745?page=comments#action_44598 ]
Bob Allison commented on MNG-745:
-
Correction on the above: In the repository, the file is
log4j-3.0-20050816.233900-8-artifactClassifier.artifactType
I am also noticing that the
Environment: Working from SVN revision 233074
Project defined with jar
Reporter: Bob Allison
When the source jar is deployed to the repository (both as a release and as a
snapshot), the jar file is named wrong. The jar that is built is named
log4j-3.0-SNAPSHOT-sources.jar (as expected) but when it is
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44595 ]
Bob Allison commented on MNG-734:
-
Well, that description does explain why when I simplified my POM for testing I
started geting the exception for both snapshots and releases. Adding
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44572 ]
Bob Allison commented on MNG-734:
-
I renamed "deploymentRepository" to "ploymentRepository" so that it comes after
"localRepository" during processing.
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44562 ]
Bob Allison commented on MNG-734:
-
After putting a few System.out.println in the plexus code, I have traced the
cause of the exception back a little.
When the deploy plugin is loaded
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44416 ]
Bob Allison commented on MNG-734:
-
I have simplified my POM to the following:
4.0.0
qaccess
log4j
jar
3.0-SNAPSHOT
Q.Access log4j Interface
log4j
log4j
[ http://jira.codehaus.org/browse/MNG-734?page=comments#action_44415 ]
Bob Allison commented on MNG-734:
-
Exception is thrown because
org.apache.maven.artifact.repository.ArtifactRepository is an interface.
To try to see what is happening, I added a
Reporter: Bob Allison
Setting up a project to deploy a snapshot. From comments of others, I have a
bad POM in one of my dependencies (haven't tracked that down yet).
When I set the project's version to "3.0", the jar is deployed properly.
When I set the project's version
-plugins
Versions: 2.0-beta-1
Reporter: Bob Allison
Priority: Minor
I have a tool I am using to generate UML diagrams for the project I am working
on. This tool is capable of generating a web site with all of the diagrams and
text, organized in a set of directories based on the way
[ http://jira.codehaus.org/browse/MNG-695?page=comments#action_43857 ]
Bob Allison commented on MNG-695:
-
I made the following changes to ScmReport.java to eliminate the problem:
In method renderDeveloperAccessSection, added the following at the top of the
en-plugins
Versions: 2.0-beta-1
Reporter: Bob Allison
(This was working yesterday. This morning I updated my SVN tree to 227227 and
this started happening.)
I am not currently using SCM features of Maven, so I do not have a developer
connection defined. In v1.0.2, I have always had an em
Reporting stanza is not inherited from parent
-
Key: MNG-693
URL: http://jira.codehaus.org/browse/MNG-693
Project: Maven 2
Type: Bug
Versions: 2.0-beta-1
Reporter: Bob Allison
Priority: Minor
I have a multi
: 2.0-alpha-3
Reporter: Bob Allison
Priority: Minor
As currently defined, text in a paragraph that is enclosed in ...
will appear much smaller. This has been true since v1.0.2 or earlier.
Adding the following four lines to "maven-theme.css" will fix the problem (I
would sugg
62 matches
Mail list logo