[jira] Created: (MCLOVER-72) Configurable to have inline lifecycle aswell as forked lifecycle
Configurable to have inline lifecycle aswell as forked lifecycle Key: MCLOVER-72 URL: http://jira.codehaus.org/browse/MCLOVER-72 Project: Maven 2.x Clover Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Andrea Popplewell Request from a customer (TN#: 105209) Extract: it would be a big bonus with the 2.x maven plugin if it somehow did not require a forked lifecycle. It's so cumbersome to run the build twice that my team no longer does it, and we just allow coverage (and threshold checks) to happen on the server. I know the forked lifecycle is for safety's sake, more than anything else; Perhaps forking can be the default, but it becomes configurable to do inline as well. Then, devs can run inline, and the server can be run forked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-218) Check if properties contains SNAPSHOT
[ http://jira.codehaus.org/browse/MRELEASE-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MRELEASE-218: - Fix Version/s: (was: 2.0-beta-5) 2.0-beta-6 > Check if properties contains SNAPSHOT > - > > Key: MRELEASE-218 > URL: http://jira.codehaus.org/browse/MRELEASE-218 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Emmanuel Venisse > Fix For: 2.0-beta-6 > > > Actually, if a property contains a SNAPSHOT verion but it isn't used in > dependencies definitions because it's used elsewhere (for example, resources > filtering), the pom is released with this SNAPSHOT value -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-175) Svn commit fails due to large number of poms on windows
[ http://jira.codehaus.org/browse/MRELEASE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MRELEASE-175: - Fix Version/s: (was: 2.0-beta-5) 2.0-beta-6 > Svn commit fails due to large number of poms on windows > --- > > Key: MRELEASE-175 > URL: http://jira.codehaus.org/browse/MRELEASE-175 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-4 > Environment: windows >Reporter: Dan Tran >Assignee: Emmanuel Venisse > Fix For: 2.0-beta-6 > > > I have so many projects under one source tree that release:prepare fails when > trying to commit the > changed pom files ( ie svn command is too long) > Can we just issue "svn commit" ? This problem hits all scm types on windows > platform -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-185) Regardless of what profile is used for releasing the release information in the metadata needs to be updated
[ http://jira.codehaus.org/browse/MRELEASE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MRELEASE-185: - Fix Version/s: (was: 2.0-beta-5) 2.0-beta-6 > Regardless of what profile is used for releasing the release information in > the metadata needs to be updated > > > Key: MRELEASE-185 > URL: http://jira.codehaus.org/browse/MRELEASE-185 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.0-beta-6 > > > Right now with the release profile buried in the Super POM you have to make > sure that you configure the deploy plugin to update the release info. A user > would probably assume that any profile used would also be accompanied by the > release information being updated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-163) Dependencies in build.plugins section of pom do not have thier versions updated.
[ http://jira.codehaus.org/browse/MRELEASE-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MRELEASE-163: - Fix Version/s: (was: 2.0-beta-5) 2.0-beta-6 > Dependencies in build.plugins section of pom do not have thier versions > updated. > > > Key: MRELEASE-163 > URL: http://jira.codehaus.org/browse/MRELEASE-163 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-4 > Environment: Linux/Maven v2.0.4 >Reporter: Baron Reznik > Fix For: 2.0-beta-6 > > > Inside my parent pom of a multimodule project, I have something that looks > like: > > > > org.apache.maven.plugins > maven-checkstyle-plugin > > > mygroupId > build-resources > 1.0-SNAPSHOT > > ... > The snapshot dependencies inside the section are not resolved and > updated on release as other dependencies elsewhere in the pom are. In my > specific case, I am using the maven-checkstyle-plugin with a dependency that > includes a custom checkstyle checker xml file inside an artifact. So, I would > expect that on release, the snapshot dependency would be resolved and updated > like all others. If more information is needed to replicate, please let me > know. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPWAR-65) Problems with maven.war.property.expansion
[ http://jira.codehaus.org/browse/MPWAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94672 ] Stephane Nicoll commented on MPWAR-65: -- For the first part it's not that easy since the filter is applied to the whole copy operation. We might need two copy operation then. > Problems with maven.war.property.expansion > -- > > Key: MPWAR-65 > URL: http://jira.codehaus.org/browse/MPWAR-65 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: Caleb Lyness >Assignee: Stephane Nicoll > Fix For: 1.6.3 > > > When you use the maven.war.property.expansion=true, all resources in your > webapps folder are all modified. This is fine, but some binary files (for > example image) are broken in the process. I would propose that 2 variable are > added, apon which the filter set can be further specified. > maven.war.property.expansion.includes > maven.war.property.expansion.excludes > In this way specific files may have the expansion applied to them or avoid > any meddling. > Also, note that the special treatment of web.xml conflicts with the > maven.war.property.expansion. > The web.xml is copied and filtered during the main copy step (including > expansion). Then later > it is copied again, without expansion, overwritting the original file. This > can be worked around by > setting maven.war.webxml=nonexistentfile or by having > maven.war.webxml.overwrite=false > The expansion code should be added to the second stage as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPWAR-68) corrupt images after copy
[ http://jira.codehaus.org/browse/MPWAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94673 ] Stephane Nicoll commented on MPWAR-68: -- filter="on" is not the only problem. If you activate property expansion, you're stuck if you have binary files to copy. We can customize the filter property, not sure that this will solve the problem at all. (Still thinking) > corrupt images after copy > - > > Key: MPWAR-68 > URL: http://jira.codehaus.org/browse/MPWAR-68 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: G.J. Sterenborg >Assignee: Stephane Nicoll > Fix For: 1.6.3 > > Attachments: descending.gif, descending.gif, descending.gif > > > maven-1.1-beta-3 seems to corrupt images during a . > I'll attach two samples: > - corrupt-copy (2284 bytes) > - original (843 bytes) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-292) Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in memory clientspec names
[ http://jira.codehaus.org/browse/SCM-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94674 ] Raphael PETIT commented on SCM-292: --- Currently, each client spec has - a root with the unique number at the end - a view defined by one line Maybe, it can be changed to a unique client spec - a root (global definition) - a view defined by several line the unique number at the end So things seems to be manageable without continnum concept in the scm... > Replace DEFAULT_CLIENTSPEC_PROPERTY system property by a map to store in > memory clientspec names > > > Key: SCM-292 > URL: http://jira.codehaus.org/browse/SCM-292 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-perforce >Affects Versions: 1.0-beta-4 >Reporter: Emmanuel Venisse >Assignee: Patrick Schneider >Priority: Critical > Fix For: 1.0 > > > With a Map instead of a system property, we'll can support more that one > clientspec in the jvm. It's necessary for Continuum because it access to more > than one project in Perforce. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTTASKS-18) filesetId does not contain all dependencies when artifact was not yet locally installed
[ http://jira.codehaus.org/browse/MANTTASKS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-18: --- Attachment: MANTTASKS-18.tar.gz MANTTASKS-18.diff Here is a patch which does the same trick than the current patch, but a testcase is added to reproduce the problem > filesetId does not contain all dependencies when artifact was not yet locally > installed > --- > > Key: MANTTASKS-18 > URL: http://jira.codehaus.org/browse/MANTTASKS-18 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Environment: java version "1.4.2_04", Linux 2.6.11.12, Apache Ant > version 1.6.5 >Reporter: Ingo Weichsel > Attachments: MANTTASKS-18.diff, MANTTASKS-18.tar.gz, patch.txt > > > In the artifact:dependencies task the filesetId is only correctly set, when > the artifact was installed locally before running ant. > After deletion of the local repository the dependant artifacts will be > downloaded to the local repository, but only one of two dependant files will > be included in the ant fileset. The classpath is set correctly. > After running "mvn install" locally for the "as-base-launcher" maven project, > ant computes the correct filesetId. > The ant-project depends on the artifact "as-base-launcher" which itselfs > depends only on classworlds. Snippets from ant buildfiles, poms and ant > output follows: > From the ant buildfile: > > > > pathId="as-launcher.classpath" verbose="true"> > > > > > > > > > > > > > > > > > The referenced POM defining the ant dependencies: > > 4.0.0 > actis > ant-as-base > 1.0-SNAPSHOT > > > actis > as-base-launcher > 1.0-SNAPSHOT > > > > > actisRepository > actisRepository > http://company.com:/repository/ > > > > Output of the ant run: > launcherJAR: > actis:ant-as-base:jar:1.0-SNAPSHOT (selected) > actis:as-base-launcher:jar:1.0-SNAPSHOT (selected) > classworlds:classworlds:jar:1.1-alpha-1 (selected) > [echo] CLASSPATH: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar:/home/iwe/.m2/repository/actis/as-base-launcher/1.0-20051103.102305-8/as-base-launcher-1.0-20051103.102305-8.jar > [echo] FILESET: > /home/iwe/.m2/repository/classworlds/classworlds/1.1-alpha-1/classworlds-1.1-alpha-1.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-66) When run standalone, project metadata is missing
When run standalone, project metadata is missing Key: MPIR-66 URL: http://jira.codehaus.org/browse/MPIR-66 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Thomas Leonard Attachments: project-info.patch When run directly with "mvn project-info-reports:dependencies", the copyright field is blank. When run as part of 'mvn site', the field is filled in correctly from the pom.xml. The attached patch seems to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-20) Variables are not replaced into installed pom file
[
http://jira.codehaus.org/browse/MINSTALL-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94680
]
Stephane Nicoll commented on MINSTALL-20:
-
not sure it's related to the install plugin. This sounds like a bad practice to
me.
> Variables are not replaced into installed pom file
> --
>
> Key: MINSTALL-20
> URL: http://jira.codehaus.org/browse/MINSTALL-20
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MINSTALL-38) Install plugin behaves incorrectly in grandchildren projects that has packaging != jar
[ http://jira.codehaus.org/browse/MINSTALL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MINSTALL-38. --- Assignee: Stephane Nicoll Resolution: Duplicate It's indeed a reactor issue. See the related link for more information. > Install plugin behaves incorrectly in grandchildren projects that has > packaging != jar > -- > > Key: MINSTALL-38 > URL: http://jira.codehaus.org/browse/MINSTALL-38 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Niclas Hedhman >Assignee: Stephane Nicoll >Priority: Critical > > Case in hand; https://scm.ops4j.org/repos/ops4j/projects/pax/ > Pax contains a handful of subprojects, which in turn contains subprojects and > they are often of a custom packaging "bundle" or "osgi-bundle". > When building for instance from pax/logging as the root, things work as > expected and we get the following info; > [INFO] [install:install] > [INFO] Installing > /home/niclas/dev/ops4j/projects/pax/logging/api/target/api-0.9.5-SNAPSHOT.jar > to > /home/niclas/.m2/repository/org/ops4j/pax/logging/api/0.9.5-SNAPSHOT/api-0.9.5-SNAPSHOT.jar > But when building one level higher up, we get the following message; > [INFO] [install:install] > [INFO] Installing > /home/niclas/dev/ops4j/projects/pax/logging/api/target/api-0.9.5-SNAPSHOT.jar > to > /home/niclas/.m2/repository/org/ops4j/pax/logging/api/0.9.5-SNAPSHOT/api-0.9.5-SNAPSHOT.bundle > Note that when building the grandchild project, the file extension is equal > to the argument, but if building a child project, it is the jar > file we construct. > This problem appeared not too long ago, and may not be the problem of the > Install Plugin after all, and instead is somewhere in the inheritence > mechanism that got screwed up. Whatever, the problem is huge as we have this > in much larger commercial projects, where it is not feasible to build project > by project, and the Continuous Integration setup must be populated with > hundreds of projects instead of 3. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINSTALL-18) Bad algorithm to decide if the main artifact is to be installed or not
[
http://jira.codehaus.org/browse/MINSTALL-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MINSTALL-18:
Fix Version/s: 2.2
> Bad algorithm to decide if the main artifact is to be installed or not
> --
>
> Key: MINSTALL-18
> URL: http://jira.codehaus.org/browse/MINSTALL-18
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Vincent Massol
> Fix For: 2.2
>
>
> Here' s what's in InstallMojo's execute method:
> {code}
> // Here, we have a temporary solution to MINSTALL-3
> (isDirectory() is true if it went through compile
> // but not package). We are designing in a proper solution
> for Maven 2.1
> if ( file != null && !file.isDirectory() )
> {
> installer.install( file, artifact, localRepository );
> }
> else if ( !attachedArtifacts.isEmpty() )
> {
> getLog().info( "No primary artifact to install,
> installing attached artifacts instead." );
> }
> {code}
> This fails if we're building a JAR with no sources but with an attached
> artifact and only the attached artifact is created (this is the case when
> using the clover plugin). In that case, the install mojo tries to install the
> main artifact which doesn't exist).
> The error is in "!file.isDirectory". In the case of a jar with no sources,
> this directory will not have been created...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MNG-2971) Variables are not replaced into installed pom file
[
http://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll moved MINSTALL-20 to MNG-2971:
--
Affects Version/s: (was: 2.0)
Complexity: Intermediate
Key: MNG-2971 (was: MINSTALL-20)
Project: Maven 2 (was: Maven 2.x Install Plugin)
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: http://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2
> Issue Type: Bug
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MINSTALL-33) mvn install:install-file should create appropriate entries so that dependencies with version ranges will use installed file.
[ http://jira.codehaus.org/browse/MINSTALL-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MINSTALL-33: Testcase included: (was: yes) > mvn install:install-file should create appropriate entries so that > dependencies with version ranges will use installed file. > > > Key: MINSTALL-33 > URL: http://jira.codehaus.org/browse/MINSTALL-33 > Project: Maven 2.x Install Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: all >Reporter: Patrick Moore > > when using install:install-file it should cooperate with the code that > handles versions that don't have an explicit version, but specify a version > range. For example, if I install hibernate-3.2.0rc4, and my pom.xml has the > hibernate dependency specified as: > > hibernate > hibernate > [3.2.0rc4,) > > maven will complain that it cannot find the hibernate version 3.2.0rc4. > However if the dependency is specified as : > > hibernate > hibernate > 3.2.0rc4 > > then the project builds successfully. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1261) Error with state handling (keeping username and password / cookie state)
[ http://jira.codehaus.org/browse/CONTINUUM-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94682 ] Kristoffer Moum commented on CONTINUUM-1261: Actually, I feel I should decorate the description somewhat. By accident, I noticed that the cookie handling seems to work in IE6. Firefox is my preferred choice and the cookie handling seems to be broken when using Firefox (2.0.0.3). > Error with state handling (keeping username and password / cookie state) > > > Key: CONTINUUM-1261 > URL: http://jira.codehaus.org/browse/CONTINUUM-1261 > Project: Continuum > Issue Type: Bug > Environment: Windows XP with Jetty, no proxy currently in front. >Reporter: Kristoffer Moum > > It is really nice with the "remember me" feature, but there is something > wrong with the cookie handling. If the http session times out, then I still > have to retype my username and password for Continuum. This behaviour is > always reproducible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2642) maven-archetype-webapp does not produce Standard Directory Layout
[ http://jira.codehaus.org/browse/MNG-2642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94683 ] Milos Kleint commented on MNG-2642: --- having standard folders like src/main/java and src/test/java always generated would help in the IDE integration as well, see: http://www.netbeans.org/issues/show_bug.cgi?id=97170 http://www.netbeans.org/issues/show_bug.cgi?id=96266 (not saying it should not be fixed on the IDE support's side primarily) > maven-archetype-webapp does not produce Standard Directory Layout > - > > Key: MNG-2642 > URL: http://jira.codehaus.org/browse/MNG-2642 > Project: Maven 2 > Issue Type: Bug > Components: Design, Patterns & Best Practices >Reporter: Steven Libonati > > The following command does not produce the standard directory layout as > defined here . > http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html. > $ mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app > -DarchetypeArtifactId=maven-archetype-webapp > If this is the standard directory layout, why should maven-archetype-webapp > not conform? > The Standard Directory Layout is as useful in a webapp as the default : -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-265) profiles are not taken into account
profiles are not taken into account
---
Key: MECLIPSE-265
URL: http://jira.codehaus.org/browse/MECLIPSE-265
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.3
Environment: Linux
Reporter: Matthijs Wensveen
Profiles described in pom.xml are not taken into account when eclipse:eclipse
runs. I have a profile in pom.xml like this:
profile-default
true
myproject
target
This sets the properties ${finalName} and ${build.directory}. Later in pom.xml:
${finalName}
${build.directory}
This enables me to create different artifacts for different profiles. But when
I run eclipse:eclipse it puts the mvn-eclipse-cache.properties in a directory
named "${build.directory}". So apparently it doesn't take my default profile
into account.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-323) Managed repo in archiva cannot be accessed thru direct webdav url even with valid credentials (Archiva deployed in Tomcat)
[ http://jira.codehaus.org/browse/MRM-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94685 ] Arnaud Heritier commented on MRM-323: - ok, Joakim, Thanks for your investigation. I'll try it also on the trunk (or future branch). One remark, however, load-on-startup must be an integer >= 0. > Managed repo in archiva cannot be accessed thru direct webdav url even with > valid credentials (Archiva deployed in Tomcat) > -- > > Key: MRM-323 > URL: http://jira.codehaus.org/browse/MRM-323 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0 > Environment: - Tomcat 5.5.20 > - Linux > - Mozilla Firefox >Reporter: Maria Odea Ching > > Steps to re-create issue: > - Deploy Archiva in Tomcat, then start tomcat > - Access Archiva in browser and set the required configurations > - Add A Managed Repository with the following configuration: > - id: snapshots > - name: snapshots > - url: snapshots (it would have the value > http://localhost:[PORT]/archiva/repository/snapshots) > - directory: snapshots > - Go to User Management and add the Repository Observer role for the > 'snapshots' repo to the current user > - Open a new tab in your browser then type the webdav URL: > http://localhost:[PORT]/archiva/repository/snapshots > - Supply the user credentials for the 'snapshots' repository. You still > wouldn't be able to access it even if you supply the correct credentials. > Also, the following error shows up in the Archiva logs when you try to build > a Maven project with your settings.xml file configured to use the > repositories in archiva: > 102476 [http-9696-Processor23] ERROR > org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/archiva].[RepositoryServlet] > - Servlet.service() for servlet RepositoryServlet threw exception > javax.servlet.ServletException: Unable to service DAV request due to > unconfigured DavServerComponent for prefix [snapshots]. > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:93) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:39) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) > at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-112) How to use packages should be documented
[ http://jira.codehaus.org/browse/MJAVADOC-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-112. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.3 It is a javadoc specification, just read [1]. The javadoc was improved to be more clear. [1] http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html > How to use packages should be documented > > > Key: MJAVADOC-112 > URL: http://jira.codehaus.org/browse/MJAVADOC-112 > Project: Maven 2.x Javadoc Plugin > Issue Type: Improvement >Affects Versions: 2.2 > Environment: XP Pro >Reporter: David Hoffer >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.3 > > > It took me about a day to figure out that the way to specify multiple > namespaces was to delimit with colon (:) this should be documented on the web > site. > com.xrite.xdsiii:com.xrite.xdsiii.driver:com.xrite.xdsiii.driver.* -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-57) Plugin does not properly handle dependency version using set notation
[ http://jira.codehaus.org/browse/MIDEA-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94689 ] David Hoffer commented on MIDEA-57: --- Any word on when we might have a release build? > Plugin does not properly handle dependency version using set notation > - > > Key: MIDEA-57 > URL: http://jira.codehaus.org/browse/MIDEA-57 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: XP SP2 >Reporter: David Hoffer >Assignee: Edwin Punzalan > Fix For: 2.1 > > > Create m2 project that has dependency with verion specified using set > notation, such as [1.1,). Build project using install goal, everything is > fine; goal goes to repositories and finds 1.1 verison. Now run idea:idea > command; the IDEA project will not have the right artifact version if any. > See email notes of my failure below: > My project is a multi-module maven/IDEA project. > One of the modules has a dependency on a locally deployed artifact > where the current version is xrite-colorlib-api-1.1. I want to > specify 1.1 as the minimum version as that version has what I need but > subsequent versions are likely to be okay as well. Using set notation > works well for install/deploy/release goals and must not cause > failures for the idea goal. > When I ran the idea goal here is what I found: > - The main module that had a dependency on xrite-colorlib-api (using > [1.1,) did not work at all. I.e. it made the IDEA module but it had > none of it's dependencies. > - At least one other module that had a build dependency on the prior > module, had a dependency on xrite-colorlib-api-1.2-SNAPSHOT which is a > bogus version. No snapshot of this artifact exists. In any case, it > should not choose to use a snapshot when a released version is > specified. > As to your question of if it should reach out to the defined repos and > use the most up-to-date version; I would think this would be ideal (if > not required). I think the rule should be that it should create IDEA > projects that are exactly equivalent to what maven would use/build if > I ran the install goal for example. How else could developers, using > maven to generate IDEA projects, ever stay in sync with what maven is > building? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGONSSH-44) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/WAGONSSH-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94691 ] Barrett Nuzum commented on WAGONSSH-44: --- alas, maven 2.0.6 does not *include* wagon*.jar files in the maven/lib directory. Does anyone have any idea how I can fix it with maven 2.0.6 ? > directoryPermissions is not repected when I deploy a POM > > > Key: WAGONSSH-44 > URL: http://jira.codehaus.org/browse/WAGONSSH-44 > Project: wagon-ssh > Issue Type: Bug > Environment: Debian Linux unstable, Sun JDK 1.5.0_06 >Reporter: Trustin Lee >Assignee: Brett Porter > Attachments: wagon-permission-patch.diff > > > It seems like 'directoryPermissions' doesn't work at all though > 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also > changed my umask to 002, but it didn't help at all. > If you have committership in the Apache Directory Project (Brett? :), then > you can try it by yourself: > > svn co https://svn.apache.org/repos/asf/directory/trunks/ directory > cd directory > mvn --non-recursive deploy > > This is my ~/.m2/settings.xml > > > > > > apache.snapshots > trustin > /home/trustin/.ssh/id_rsa > 0775 > 0664 > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPWAR-65) Problems with maven.war.property.expansion
[ http://jira.codehaus.org/browse/MPWAR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MPWAR-65. Resolution: Fixed Added maven.war.expansion.excludes property to exclude files during a property expansion copy (Fixes corruption of binary files). Applied property expansion to web.xml handling for consistency. Introduced the maven.war.src.filtering property to control whether filtering is enabled or not when copying webapp resources. > Problems with maven.war.property.expansion > -- > > Key: MPWAR-65 > URL: http://jira.codehaus.org/browse/MPWAR-65 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: Caleb Lyness >Assignee: Stephane Nicoll > Fix For: 1.6.3 > > > When you use the maven.war.property.expansion=true, all resources in your > webapps folder are all modified. This is fine, but some binary files (for > example image) are broken in the process. I would propose that 2 variable are > added, apon which the filter set can be further specified. > maven.war.property.expansion.includes > maven.war.property.expansion.excludes > In this way specific files may have the expansion applied to them or avoid > any meddling. > Also, note that the special treatment of web.xml conflicts with the > maven.war.property.expansion. > The web.xml is copied and filtered during the main copy step (including > expansion). Then later > it is copied again, without expansion, overwritting the original file. This > can be worked around by > setting maven.war.webxml=nonexistentfile or by having > maven.war.webxml.overwrite=false > The expansion code should be added to the second stage as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPWAR-68) corrupt images after copy
[ http://jira.codehaus.org/browse/MPWAR-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MPWAR-68. Resolution: Fixed Added maven.war.expansion.excludes property to exclude files during a property expansion copy (Fixes corruption of binary files). Applied property expansion to web.xml handling for consistency. Introduced the maven.war.src.filtering property to control whether filtering is enabled or not when copying webapp resources. > corrupt images after copy > - > > Key: MPWAR-68 > URL: http://jira.codehaus.org/browse/MPWAR-68 > Project: maven-war-plugin > Issue Type: Bug >Affects Versions: 1.6.2 >Reporter: G.J. Sterenborg >Assignee: Stephane Nicoll > Fix For: 1.6.3 > > Attachments: descending.gif, descending.gif, descending.gif > > > maven-1.1-beta-3 seems to corrupt images during a . > I'll attach two samples: > - corrupt-copy (2284 bytes) > - original (843 bytes) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1508) upload vraptor 2.3.2.2
upload vraptor 2.3.2.2 -- Key: MAVENUPLOAD-1508 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1508 Project: maven-upload-requests Issue Type: Task Reporter: Nico Steppat VRaptor 2.3.2.2 framework update with some urgent bug fixes. VRaptor 2 is a mvc controller based on the idea (stolen) from Rails that configuration should be minimal and conventions should be maximized. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPWAR-61) Renaming jar file with war.target.pathfile
[
http://jira.codehaus.org/browse/MPWAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MPWAR-61.
Assignee: Stephane Nicoll
Resolution: Fixed
This is implemented. There was a small issue with the patch that I've fixed.
Added tes06 to test this scenario.
> Renaming jar file with war.target.pathfile
> --
>
> Key: MPWAR-61
> URL: http://jira.codehaus.org/browse/MPWAR-61
> Project: maven-war-plugin
> Issue Type: Improvement
>Affects Versions: 1.6.1
> Environment: maven 1.x
> eclipse 3.1.2
>Reporter: hugo lassiege
>Assignee: Stephane Nicoll
>Priority: Trivial
> Fix For: 1.6.3
>
> Attachments: plugin.jelly
>
>
> Hi,
> I had a little problem during the creation of a war file.
> Here is an example :
> I add a applet-1.0.0.jar in the dependencies
> I don't put the applet in WEB-INF/lib so I use the property : war.target.path
> lib/
> But, this applet have a version number and I don't want to change my jsp each
> time I change the dependencies.
> I modify the plugin to add the rename of the file :
> I add a option (line 172 of plugin.jelly) :
>value="${dep.getProperty('war.target.pathfile')}"/>
>
> file="${lib.path}"/>
>
> So I can use :
> lib/applet.jar
> and now I can just change the dependencies and not the jsp file.
> Is it a wrong way or can you add this options in the plugin ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (WAGONSSH-44) directoryPermissions is not repected when I deploy a POM
[ http://jira.codehaus.org/browse/WAGONSSH-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94691 ] Barrett Nuzum edited comment on WAGONSSH-44 at 5/1/07 11:15 AM: alas, maven 2.0.6 does not *include* wagon*.jar files in the maven/lib directory. Does anyone have any idea how I can fix it with maven 2.0.6 ? Looks like the problem is fixed for ScpWagon, but not for FileWagon. was: alas, maven 2.0.6 does not *include* wagon*.jar files in the maven/lib directory. Does anyone have any idea how I can fix it with maven 2.0.6 ? > directoryPermissions is not repected when I deploy a POM > > > Key: WAGONSSH-44 > URL: http://jira.codehaus.org/browse/WAGONSSH-44 > Project: wagon-ssh > Issue Type: Bug > Environment: Debian Linux unstable, Sun JDK 1.5.0_06 >Reporter: Trustin Lee >Assignee: Brett Porter > Attachments: wagon-permission-patch.diff > > > It seems like 'directoryPermissions' doesn't work at all though > 'filePermissions' do. I tried both scp and scpexe. Nothing worked. I also > changed my umask to 002, but it didn't help at all. > If you have committership in the Apache Directory Project (Brett? :), then > you can try it by yourself: > > svn co https://svn.apache.org/repos/asf/directory/trunks/ directory > cd directory > mvn --non-recursive deploy > > This is my ~/.m2/settings.xml > > > > > > apache.snapshots > trustin > /home/trustin/.ssh/id_rsa > 0775 > 0664 > > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-262) Maven compilation and eclipse classpath don't match with conflicting versions at same dependency depth
[ http://jira.codehaus.org/browse/MECLIPSE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94702 ] Jorg Heymans commented on MECLIPSE-262: --- I think we're suffering from the same problem. In our root pom we declared commons-logging commons-logging 1.1 logkit logkit avalon-framework avalon-framework javax.servlet servlet-api (note the exclusion of avalon-framework) However, the eclipse plugin still selects avalon-framework : [INFO] [eclipse:eclipse] [DEBUG] org.apache.cocoon:cocoon-sitemap-impl:jar:1.0.0-RC1-SNAPSHOT (selected for null) [DEBUG] commons-collections:commons-collections:jar:3.2:compile (selected for compile) [DEBUG] commons-jxpath:commons-jxpath:jar:1.2:compile (selected for compile) [DEBUG] junit:junit:jar:3.8:compile (applying version: 3.8.2) [DEBUG] junit:junit:jar:3.8.2:compile (applying scope: test) [DEBUG] junit:junit:jar:3.8.2:test (selected for test) [DEBUG] xml-apis:xml-apis:jar:2.0.2:compile (applying version: 1.3.02) [DEBUG] xml-apis:xml-apis:jar:1.3.02:compile (selected for compile) [DEBUG] commons-logging:commons-logging:jar:1.0:compile (applying version: 1.1) [DEBUG] commons-logging:commons-logging:jar:1.1:compile (selected for compile) [DEBUG] log4j:log4j:jar:1.2.12:compile (applying version: 1.2.14) [DEBUG] log4j:log4j:jar:1.2.14:compile (selected for compile) [DEBUG] logkit:logkit:jar:1.0.1:compile (selected for compile) [DEBUG] avalon-framework:avalon-framework:jar:4.1.3:compile (selected for compile) [DEBUG] javax.servlet:servlet-api:jar:2.3:compile (applying version: 2.4) [DEBUG] javax.servlet:servlet-api:jar:2.4:compile (selected for compile) [DEBUG] commons-collections:commons-collections:jar:2.0:compile (applying version: 3.2) [DEBUG] javax.servlet:servlet-api:jar:2.4:provided (not setting scope to: compile; local scope provided wins) The dependency plugin shows correct dependency resolution (no avalon-framework) [INFO] [dependency:resolve] [INFO] [INFO] The following files have been resolved: [INFO]aopalliance:aopalliance:jar:1.0 (scope = compile) [INFO]commons-collections:commons-collections:jar:3.2 (scope = compile) [INFO]commons-io:commons-io:jar:1.3.1 (scope = compile) [INFO]commons-jxpath:commons-jxpath:jar:1.2 (scope = compile) [INFO]commons-lang:commons-lang:jar:2.3 (scope = compile) [INFO]commons-logging:commons-logging:jar:1.1 (scope = compile) [INFO]concurrent:concurrent:jar:1.3.4 (scope = compile) [INFO]jakarta-regexp:jakarta-regexp:jar:1.4 (scope = compile) [INFO]javax.servlet:servlet-api:jar:2.4 (scope = provided) [INFO]junit:junit:jar:3.8.2 (scope = test) [INFO]log4j:log4j:jar:1.2.14 (scope = compile) [INFO]org.apache.avalon.framework:avalon-framework-api:jar:4.3.1 (scope = compile) [INFO]org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1 (scope = compile) [INFO]org.apache.cocoon:cocoon-configuration-api:jar:1.0.1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-pipeline-api:jar:1.0.0-RC1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-pipeline-impl:jar:1.0.0-RC1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-sitemap-api:jar:1.0.0-RC1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-spring-configurator:jar:1.0.1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-thread-api:jar:1.0.0-RC1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-util:jar:1.0.0-RC1-SNAPSHOT (scope = compile) [INFO]org.apache.cocoon:cocoon-xml-api:jar:1.0.0-RC1-SNAPSHOT (scope = compile) [INFO]org.apache.excalibur.components:excalibur-pool-api:jar:2.2.1 (scope = compile) [INFO]org.apache.excalibur.components:excalibur-sourceresolve:jar:2.2.1 (scope = compile) [INFO]org.apache.excalibur.components:excalibur-store:jar:2.2.1 (scope = compile) [INFO]org.apache.excalibur.components:excalibur-xmlutil:jar:2.2.1 (scope = compile) [INFO]org.apache.excalibur.containerkit:excalibur-instrument-api:jar:2.2.1 (scope = compile) [INFO]org.apache.excalibur.containerkit:excalibur-logger:jar:2.2.1 (scope = compile) [INFO]org.springframework:spring-aop:jar:2.0.3 (scope = compile) [INFO]org.springframework:spring-beans:jar:2.0.3 (scope = compile) [INFO]org.springframework:spring-context:jar:2.0.3 (scope = compile) [INFO]org.springframework:spring-core:jar:2.0.3 (scope = compile) [INFO]org.springframework:spring-web:jar:2.0.3 (scope = compile) [INFO]xml-apis:xml-apis:jar:1.3.02 (scope = compile) > Maven compilation and eclipse classpath don't match with conflicting versions > at same dependency depth > ---
[jira] Commented: (MCLOVER-70) Non-Clovered Jars used for Transitive Dependencies
[ http://jira.codehaus.org/browse/MCLOVER-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_94704 ] Indrajit Khare commented on MCLOVER-70: --- I noticed this recently as well. Using the maven-clover-plugin does not give comprehensive coverage numbers. For projects that have modules that are dependent transitively non-clovered jars are being used for the dependencies when running tests in clover:instrument. > Non-Clovered Jars used for Transitive Dependencies > -- > > Key: MCLOVER-70 > URL: http://jira.codehaus.org/browse/MCLOVER-70 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: James Olsen > > When executing tests or building ear/war archives, the plugin is not using > instrumented jars for transitive dependencies. The ordinary jar is used > instead. Hence no test coverage stats are obtained for those components. > Adding the transitive dependency as a direct dependency on the project > results in both the instrumented and plain jar appearing in the archive. I > presume the same also happens for the unit test classpath although I haven't > confirmed. > The plugin should use the instrumented version of the jar where available > regardless of whether the dependency is direct or transitive. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-1262) NoClassDefFound error when staring Continuum on win32
[ http://jira.codehaus.org/browse/CONTINUUM-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed CONTINUUM-1262. --- Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 1.1-alpha-1 already fixed. > NoClassDefFound error when staring Continuum on win32 > - > > Key: CONTINUUM-1262 > URL: http://jira.codehaus.org/browse/CONTINUUM-1262 > Project: Continuum > Issue Type: Bug >Affects Versions: 1.0.3 > Environment: Windows XP >Reporter: Wouter Hermeling >Assignee: Emmanuel Venisse >Priority: Blocker > Fix For: 1.1-alpha-1 > > > This issue is probably linked to CONTINUUM-231 > When starting continuum on a Windows OS having a PATH containing spaces, the > startup fails giving NoClassDefFound error messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1509) JETM 1.2.1 bundles
JETM 1.2.1 bundles --- Key: MAVENUPLOAD-1509 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1509 Project: maven-upload-requests Issue Type: Wish Reporter: Jens Schumann Please upload jetm 1.2.1 to central maven2 repository. Thanks again, Jens http://jetm.void.fm/maven2/jetm-1.2.1/jetm-1.2.1-bundle.jar http://jetm.void.fm/maven2/jetm-1.2.1/jetm-optional-1.2.1-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPWAR-30) [PATCH] Option to pack project classes inside a JAR into WEB-INF/lib
[ http://jira.codehaus.org/browse/MPWAR-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MPWAR-30: --- Assignee: (was: Stephane Nicoll) Fix Version/s: (was: 1.7) > [PATCH] Option to pack project classes inside a JAR into WEB-INF/lib > > > Key: MPWAR-30 > URL: http://jira.codehaus.org/browse/MPWAR-30 > Project: maven-war-plugin > Issue Type: New Feature >Affects Versions: 1.6 >Reporter: Felipe Leme > Attachments: maven_war_usesJar.patch, MPWAR-30.diff > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > The way the plugin works now, the project classes are packed under > WEB-INF/classes. It would be nice if the plugin used the project's JAR > instead, packing it under WEB-INF/lib. That feature would be really useful > when the war is a secondary package for the project (for instance, when the > main artifact is a JAR containg a taglib). > I'm providing a patch for this change - if there is interest in applying it, > I can write some test cases too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPTEST-63) Memory leak in test plugin 1.8?
[ http://jira.codehaus.org/browse/MPTEST-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MPTEST-63: Description: In a project with ~40 test classes, I was surprised to see 'maven dist-bin' fail with a java.lang.reflect.InvocationTargetException Exception in thread "main" java.lang.OutOfMemoryError when running the junit test suite, even though, the tests pass when running just 'maven test'. The point is that dist-bin runs the test suite twice (once from jar:jar,once from site:generate), and it's only the second time that it fails. I can reproduce it with a simple custom goal: It works by simply downgrading to test-plugin-1.7, so it's not a problem with my tests. was: In a project with ~40 test classes, I was surprised to see 'maven dist-bin' fail with a java.lang.reflect.InvocationTargetException Exception in thread "main" java.lang.OutOfMemoryError when running the junit test suite, even though, the tests pass when running just 'maven test'. The point is that dist-bin runs the test suite twice (once from jar:jar,once from site:generate), and it's only the second time that it fails. I can reproduce it with a simple custom goal: It works by simply downgrading to test-plugin-1.7, so it's not a problem with my tests. Fix Version/s: (was: 1.8.1) > Memory leak in test plugin 1.8? > --- > > Key: MPTEST-63 > URL: http://jira.codehaus.org/browse/MPTEST-63 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Linux FC3, jdk 1.4.2_10, m11b3 >Reporter: Lukas Theussl >Priority: Critical > > In a project with ~40 test classes, I was surprised to see 'maven dist-bin' > fail with a > java.lang.reflect.InvocationTargetException > Exception in thread "main" java.lang.OutOfMemoryError > when running the junit test suite, even though, the tests pass when running > just 'maven test'. The point is that dist-bin runs the test suite twice (once > from jar:jar,once from site:generate), and it's only the second time that it > fails. I can reproduce it with a simple custom goal: > > > > > It works by simply downgrading to test-plugin-1.7, so it's not a problem with > my tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPTEST-64) test-plugin-1.8 is way slower than 1.7
[ http://jira.codehaus.org/browse/MPTEST-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MPTEST-64: Fix Version/s: (was: 1.8.1) > test-plugin-1.8 is way slower than 1.7 > -- > > Key: MPTEST-64 > URL: http://jira.codehaus.org/browse/MPTEST-64 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 > Environment: Linux FC3, jdk 1.4.2_10, m11b3 >Reporter: Lukas Theussl > > This is maybe related to MPTEST-63: a test suite that takes ~30s with > test-plugin-1.7, takes over a minute with 1.8. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1262) NoClassDefFound error when staring Continuum on win32
NoClassDefFound error when staring Continuum on win32 - Key: CONTINUUM-1262 URL: http://jira.codehaus.org/browse/CONTINUUM-1262 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Environment: Windows XP Reporter: Wouter Hermeling Priority: Blocker This issue is probably linked to CONTINUUM-231 When starting continuum on a Windows OS having a PATH containing spaces, the startup fails giving NoClassDefFound error messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MPTEST-66) 1.8 version introduces bug in other plugins
[ http://jira.codehaus.org/browse/MPTEST-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPTEST-66. --- Resolution: Won't Fix Documented the issue. > 1.8 version introduces bug in other plugins > --- > > Key: MPTEST-66 > URL: http://jira.codehaus.org/browse/MPTEST-66 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: nicolas de loof >Assignee: Lukas Theussl > Fix For: 1.8.1 > > Attachments: MPTEST-66.patch > > > When maven-war-plugin is run with maven.test.skip=true, the sources are not > compiled. > Latest version of test-plugin has removed prereqs on java:compile & > java:jar-resources. > Assuming other plugins themself run the java:compile goal may have impact on > lots of plugin and can break many application builds. I think the "test:test" > goal may have a prereqs="java:compile,java:jar-resources", and the > "test:compile" goal only prereqs="test:prepare-filesystem,test:test-resources" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-206) Filtering does not work when using in fileSet inside moduleSet
Filtering does not work when using in fileSet inside moduleSet -- Key: MASSEMBLY-206 URL: http://jira.codehaus.org/browse/MASSEMBLY-206 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: win32 Reporter: Liya Jan i have a descriptor : com.cc:module1 com.cc:module2 com.cc:module3 src/main true core conf/* false and although there is "true", the copied sources are not filtered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-207) CLONE -Filtering does not work when using in fileSet inside moduleSet
CLONE -Filtering does not work when using in fileSet inside moduleSet - Key: MASSEMBLY-207 URL: http://jira.codehaus.org/browse/MASSEMBLY-207 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-1 Environment: win32 Reporter: Liya Jan i have a descriptor : com.cc:module1 com.cc:module2 com.cc:module3 src/main true core conf/* false and although there is "true", the copied sources are not filtered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-207) CLONE -Filtering does not work when using in fileSet inside moduleSet
[ http://jira.codehaus.org/browse/MASSEMBLY-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Liya Jan closed MASSEMBLY-207. -- Resolution: Duplicate cloned by mistake > CLONE -Filtering does not work when using in fileSet inside moduleSet > - > > Key: MASSEMBLY-207 > URL: http://jira.codehaus.org/browse/MASSEMBLY-207 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-1 > Environment: win32 >Reporter: Liya Jan > > i have a descriptor : > > > com.cc:module1 > com.cc:module2 > com.cc:module3 > > > > > src/main > true > core > > conf/* > > > > false > > > and although there is "true", the copied sources are not > filtered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2972) Ignores version of plugin dependency specified in my pom
Ignores version of plugin dependency specified in my pom Key: MNG-2972 URL: http://jira.codehaus.org/browse/MNG-2972 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: maven 2.0.6, java version "1.5.0_07" Reporter: Derek Alexander Priority: Critical xmlbeans-maven-plugin declares a dependency on xmlbeans-2.0.0 I want to use xmlbeans-2.2.0 So in my pom I put: org.codehaus.mojo xmlbeans-maven-plugin xmlbeans ... xmlbeans xbean 2.2.0 http://www.nabble.com/Override-plugin-dependency-version-tf2357806s177.html#a6568092 Apparently this should be possible: http://maven.apache.org/pom.html#plugins "dependencies: Dependencies are seen a lot within the POM, and are an element under all plugins element blocks. The dependencies have the same structure and function as under that base build. The major difference in this case is that instead of applying as dependencies of the project, they now apply as dependencies of the plugin that they are under. The power of this is to alter the dependency list of a plugin, perhaps by removing an unused runtime dependency via exclusions, or by altering the version of a required dpendency. See above under Dependencies for more information." -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
issues@maven.apache.org
[ http://jira.codehaus.org/browse/MPNSIS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MPNSIS-15. - Resolution: Fixed Done > Use MODERN_UI macros for a better L&F > - > > Key: MPNSIS-15 > URL: http://jira.codehaus.org/browse/MPNSIS-15 > Project: maven-nsis-plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier >Priority: Minor > Fix For: 2.1 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVEN-1840) java.util.ConcurrentModificationException in Goal
[ http://jira.codehaus.org/browse/MAVEN-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MAVEN-1840. -- Resolution: Won't Fix Fix Version/s: (was: 1.1-rc1) This problem seems to be only while running maven in continuum ... > java.util.ConcurrentModificationException in Goal > - > > Key: MAVEN-1840 > URL: http://jira.codehaus.org/browse/MAVEN-1840 > Project: Maven 1 > Issue Type: Bug > Components: jelly/ant integration >Affects Versions: 1.1-beta-3 > Environment: build maven 1.1 RC 1 on continuum 1.0 on solaris with > jdk 1.4 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > > maven:run-touchstone: > Trying to get missing dependencies (and updated snapshots) required by > Touchstone: > - Checking for an update of touchstone:touchstone:SNAPSHOT:jar from > http://people.apache.org/repo/m1-snapshot-repository/ > Skipping download as local copy is up to date! > - Checking for an update of touchstone:test:SNAPSHOT:war from > http://people.apache.org/repo/m1-snapshot-repository/ > Skipping download as local copy is up to date! > build:start: > clean:clean: > xdoc:clean: > [delete] Deleting directory > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target > clean: > java:prepare-filesystem: > [mkdir] Created dir: > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes > java:init: > java:compile: > [echo] > maven.dependency.classpath: > /export/home/continuum/.maven/repository/ant/jars/ant-optional-1.5.1.jar > /export/home/continuum/maven-1.1/lib/maven.jar > /export/home/continuum/.maven/repository/maven/jars/maven-model-3.0.1.jar > > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/a.jar > > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/b.jar > > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/c-1.0-alpha-1-SNAPSHOT.jar > > /export/home/continuum/.maven/repository/classworlds/jars/classworlds-1.0-beta-1.jar > > /export/home/continuum/.maven/repository/touchstone/jars/touchstone-SNAPSHOT.jar > > /export/home/continuum/.maven/repository/commons-jelly/jars/commons-jelly-tags-interaction-1.0.jar > > > [echo] Compiling to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes > [javac] Compiling 1 source file to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes > java:jar-resources: > Copying 1 file to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes > Copying 1 file to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes/org/apache/maven/touchstone > Copying 2 files to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes > test:test: > java:prepare-filesystem: > java:init: > java:compile: > [echo] > maven.dependency.classpath: > /export/home/continuum/.maven/repository/ant/jars/ant-optional-1.5.1.jar > /export/home/continuum/maven-1.1/lib/maven.jar > /export/home/continuum/.maven/repository/maven/jars/maven-model-3.0.1.jar > > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/a.jar > > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/b.jar > > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/lib/c-1.0-alpha-1-SNAPSHOT.jar > > /export/home/continuum/.maven/repository/classworlds/jars/classworlds-1.0-beta-1.jar > > /export/home/continuum/.maven/repository/touchstone/jars/touchstone-SNAPSHOT.jar > > /export/home/continuum/.maven/repository/commons-jelly/jars/commons-jelly-tags-interaction-1.0.jar > > > [echo] Compiling to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/classes > java:jar-resources: > test:prepare-filesystem: > [mkdir] Created dir: > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-classes > [mkdir] Created dir: > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-reports > test:test-resources: > Copying 1 file to > /export/home/continuum/continuum_1.0.3_data/working-directory/6/src/test/touchstone-build/target/test-classes/org/apache/maven/touchstone > Copying 1 file to > /export/home/continuum/continuum_1.0.3
[jira] Created: (MNG-2973) Cannot specify a version range for build extensions
Cannot specify a version range for build extensions
---
Key: MNG-2973
URL: http://jira.codehaus.org/browse/MNG-2973
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.5
Reporter: Tim Meighen
Attachments: pom.xml
When specifying a version range in a build extension, I get the following:
+ Error stacktraces are turned on.
Maven version: 2.0.6
[DEBUG] Building Maven user-level plugin registry from:
'/Users/tmeighen/.m2/plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from:
'/Users/tmeighen/maven/conf/plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Initialising extension: junit:junit
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been included
transitively during the resolution process. Here is the information we do have
for this artifact:
o GroupID: junit
o ArtifactID: junit
o Version: <<< MISSING >>>
o Type:pom
[INFO]
[DEBUG] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact
{junit:junit:null:pom}: The version cannot be empty.
at
org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
at
org.apache.maven.artifact.DefaultArtifact.(DefaultArtifact.java:122)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:117)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:111)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:40)
at
org.apache.maven.artifact.factory.DefaultArtifactFactory.createProjectArtifact(DefaultArtifactFactory.java:95)
at
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:94)
at
org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:98)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions(DefaultLifecycleExecutor.java:158)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:141)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: < 1 second
[INFO] Finished at: Tue May 01 17:53:00 PDT 2007
[INFO] Final Memory: 2M/1016M
[INFO]
Note that this works with Maven 2.0.5. Also the same version range works with
2.0.6 when specified in the dependencies section (i.e. not a build extension).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
