[jira] Commented: (MAVENUPLOAD-1668) HtmlUnit 1.12 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104983 ] Julien HENRY commented on MAVENUPLOAD-1668: --- There is no POM on Ibiblio... HtmlUnit 1.12 upload request Key: MAVENUPLOAD-1668 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1668 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot Assignee: Carlos Sanchez http://htmlunit.sourceforge.net/htmlunit-1.12-bundle.jar Team members, including myself: http://htmlunit.sourceforge.net/team-list.html http://sourceforge.net/project/memberlist.php?group_id=47038 -- 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: (MCHECKSTYLE-76) don't check the test code
[
http://jira.codehaus.org/browse/MCHECKSTYLE-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104984
]
kerboriou christophe commented on MCHECKSTYLE-76:
-
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-checkstyle-plugin/artifactId
configuration
outputFileFormatxml/outputFileFormat
includeTestSourceDirectory
true
/includeTestSourceDirectory
configLocation
http://///checkstyle_config.xml
/configLocation
/configuration
/plugin{code}
don't check the test code
-
Key: MCHECKSTYLE-76
URL: http://jira.codehaus.org/browse/MCHECKSTYLE-76
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.1
Environment: windos, standar conf projet (juste parent pom)
Reporter: kerboriou christophe
Priority: Critical
Fix For: 2.2
the parm for excute checkstyle on test code was at true. and i have this log
{panel} [DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-checkstyle-plugin:2.1:checkstyle' --
[DEBUG] (f) cacheFile =
D:\workspaces\workspace\{sous-projet}\target/checkstyle-cachefile
[DEBUG] (f) configLocation = http://///checkstyle_config.xml
[DEBUG] (f) consoleOutput = false
[DEBUG] (f) enableFilesSummary = true
[DEBUG] (f) enableRSS = true
[DEBUG] (f) enableRulesSummary = true
[DEBUG] (f) enableSeveritySummary = true
[DEBUG] (f) failsOnError = false
[DEBUG] (f) format = sun
[DEBUG] (f) headerFile = D:\workspaces\workspace\{sous-projet}\LICENSE.txt
[DEBUG] (f) headerLocation = LICENSE.txt
[DEBUG] (f) includes = **/*.java
[DEBUG] (f) linkXRef = true
[DEBUG] (f) outputDirectory =
D:\workspaces\workspace\{sous-projet}\target\site
[DEBUG] (f) outputFile =
D:\workspaces\workspace\{sous-projet}\target\checkstyle-result.xml
[DEBUG] (f) outputFileFormat = xml
[DEBUG] (f) project = [EMAIL PROTECTED]
[DEBUG] {color:red} *(f) sourceDirectory =
D:\workspaces\workspace\{sous-projet}\src\main\java*{color}
[DEBUG] (f) xrefLocation =
D:\workspaces\workspace\{sous-projet}\target\site\xref
[DEBUG] -- end configuration --
[INFO] [checkstyle:checkstyle]
[DEBUG] resolveLocation(http://///checkstyle_config.xml,
checkstyle-checker.xml)
[DEBUG] Potential URL: http://///checkstyle_config.xml
[DEBUG] resolveLocation(null, checkstyle-checker.properties)
[DEBUG] resolveLocation(LICENSE.txt, checkstyle-header.txt)
[DEBUG] Location is not a URL.
[DEBUG] Location is not a File.
[DEBUG] Potential Resource:
jar:file:/C:/dev/maven/bin/../lib/jsch-0.1.24.jar!/LICENSE.txt
[DEBUG] resolveLocation(null, checkstyle-packages.xml)
[DEBUG] resolveLocation(null, checkstyle-suppressions.xml)
[DEBUG] File D:\workspaces\workspace\{sous-projet}\target\site/checkstyle.rss
created...{panel}
the src/test/java wasn't use.
--
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: (MCOMPILER-57) State default source (1.3) and target (1.1) in the documentation
State default source (1.3) and target (1.1) in the documentation
Key: MCOMPILER-57
URL: http://jira.codehaus.org/browse/MCOMPILER-57
Project: Maven 2.x Compiler Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Gisbert Amm
Priority: Trivial
The documentation does currently say nothing about the compiler defaults,
especially source and target version, which is 1.3 and 1.1 (byte code 45.3). It
would be helpful to add this information to the docs to make the defaults
obvious.
Respective mailing list content:
This has been discussed several times on this list.
IMO, the default compilation target being 1.1 (or another hard-defined
version) meets the rule of least surprise. You can argue that you
don't like 1.1 and you'd prefer 1.3 or even 1.5 but that is another
discussion.
In contrast, the rule of most surprise would be my build changes when
I change my JDK or my build changes when I build things on different
machines. This is the absolute worst thing you can run into when
trying to standardize and control your build process.
If you want to target a specific JDK, then simply add the compiler
configuration in your poms. If you feel this has not been documented
sufficiently, then post a RFE in Jira and someone will add some text
to the proper page(s) on the site.
Wayne
On 8/15/07, Gisbert Amm [EMAIL PROTECTED] wrote:
Searching for version issues, I had a closer look at the *.class files
generated by Maven2 with the default compiler settings and found that
the first bytes of them are cafe babe 0003 002D ..., which is byte
code version 45.3 = Java 1.1.
First I was believing that I had this (target 1.1) configured somewhere
by accident. However, I didn't find any such configuration, therefore I
dug into the plexus-compiler source and found the following in
plexus-site/plexus-components/plexus-compiler/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java:
// TODO: this could be much improved
if ( StringUtils.isEmpty( config.getTargetVersion() ) )
{
// Required, or it defaults to the target of your JDK (eg 1.5)
args.add( -target );
args.add( 1.1 );
}
else
{
args.add( -target );
args.add( config.getTargetVersion() );
}
if ( !suppressSource( config ) StringUtils.isEmpty(
config.getSourceVersion() ) )
{
// If omitted, later JDKs complain about a 1.1 target
args.add( -source );
args.add( 1.3 );
}
Is there any particular reason why target is set to 1.1 here? IMHO, it
breaks the rule of least surprise for I am certainly expecting that the
generated byte code by default has the version of the JDK I'm using the
compiler of. The comment Required, or it defaults to the target of your
JDK doesn't give any reason. Does anybody know, why this default is set?
At least it should be mentioned on
http://maven.apache.org/plugins/maven-compiler-plugin/howto.html to make
it obvious to users. Otherwise people might have problems and need a
long time to find out what's going on (see
http://www.nabble.com/Odd-Compilation-Issue-tf1566644s177.html#a4287495
for an example).
Regards,
Gisbert
--
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-2871) Subartifact (ejb-client for example) are not reselved as active project artifacts
[ http://jira.codehaus.org/browse/MNG-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104986 ] Chris Wewerka commented on MNG-2871: Piotr, I've tested it and it's working with test jars. Thanks. Hopefully the new version of the jar plugin is to be released soon! Subartifact (ejb-client for example) are not reselved as active project artifacts - Key: MNG-2871 URL: http://jira.codehaus.org/browse/MNG-2871 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4, 2.0.5 Environment: Not platform dependent Reporter: Piotr Tabor Assignee: John Casey Fix For: 2.1-alpha-1 Attachments: MavenProject.java, MNG-2871-core-integration-tests.diff, root.tar I have prepared simple project to show the bug. It contains three artifacts: |-root \--- ejb3 \--- client Client depends on ejb3 with typeejb-client/type. The local and remote repository must not contain those artifacts. When I do mvn -X compile (or even integration-tests) on root project I will get those errors: ... [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-resources-plugin:2.2:resources' -- [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /home/ptab/m2/bug/root/client/target/classes [DEBUG] (f) project = [EMAIL PROTECTED] [DEBUG] (f) resources = [EMAIL PROTECTED] [DEBUG] -- end configuration -- [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [DEBUG] pl.waw.tabor:client:jar:1.0-SNAPSHOT (selected for null) [DEBUG] junit:junit:jar:3.8.1:test (selected for test) [DEBUG] pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT:compile (selected for compile) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Skipping disabled repository central [DEBUG] ejb3: using locally installed snapshot [DEBUG] Trying repository Newitech-snapshots-repository Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots) [DEBUG] Skipping disabled repository Newitech-repository [DEBUG] Trying repository Newitech-publiczne Downloading: scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne//pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/) [DEBUG] Trying repository Maven Snapshots Downloading: http://people.apache.org/maven-snapshot-repository/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository Maven Snapshots (http://people.apache.org/maven-snapshot-repository) [DEBUG] Trying repository codehausSnapshots Downloading: http://snapshots.maven.codehaus.org/maven2/pl/waw/tabor/ejb3/1.0-SNAPSHOT/ejb3-1.0-SNAPSHOT-client.jar [WARNING] Unable to get resource 'pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT' from repository codehausSnapshots (http://snapshots.maven.codehaus.org/maven2) [DEBUG] Skipping disabled repository central [DEBUG] Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=pl.waw.tabor -DartifactId=ejb3 \ -Dversion=1.0-SNAPSHOT -Dpackaging=ejb-client -Dfile=/path/to/file Path to dependency: 1) pl.waw.tabor:client:jar:1.0-SNAPSHOT 2) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT pl.waw.tabor:ejb3:ejb-client:1.0-SNAPSHOT from the specified remote repositories: Maven Snapshots (http://people.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2), codehausSnapshots (http://snapshots.maven.codehaus.org/maven2), Newitech-snapshots-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech-snapshots), Newitech-publiczne (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/publiczne/), Newitech-repository (scp://ivy.newitech.com/opt/maven/public_html/repozytoria/newitech) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) pl.waw.tabor:ejb3:ejb-client:client:1.0-SNAPSHOT Try downloading the file manually from the project website. Then,
[jira] Commented: (MECLIPSE-252) Error trying to create an EAR project that contains one web module. It doesn't point to the local project, but only tries to find it in the local and remote repositori
[ http://jira.codehaus.org/browse/MECLIPSE-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104988 ] Bjorn Beskow commented on MECLIPSE-252: --- The problem seems to be caused by the eclipse plugin executing the generate-resources lifecycle phase, which in turn cause the ear plugin to perform dependency resolution. Error trying to create an EAR project that contains one web module. It doesn't point to the local project, but only tries to find it in the local and remote repositories. -- Key: MECLIPSE-252 URL: http://jira.codehaus.org/browse/MECLIPSE-252 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: dependency resolution Affects Versions: 2.3 Reporter: Daniel Alheiros I have one structure that defines 3 projects: project1-jar project2-war project3-ear project2-war is just a WAR that contains the project1-jar as a library (WEB-INF/lib) project3-ear is an EAR that contains project2-war as its only web module. When I run mvn package it works perfectly and creates the EAR containing the proper WAR file and the application.xml, so it works fine, but when I run mvn eclipse:eclipse to generate the projects, the ear project is not generated properly as it tries to find the war in the local and remote repository as the piece of logging show bellow: [INFO] Building project3-ear [INFO]task-segment: [eclipse:eclipse] [INFO] [INFO] Preparing eclipse:eclipse Downloading: http://mycompany.central-repository/repo/com/mycompany/project2-war/1.0-SNAPSHOT/project2-war-1.0-SNAPSHOT.war [WARNING] Unable to get resource 'mycompanygroupid:project2-war:war:1.0-SNAPSHOT' from repository mycompany.central-repository (http://mycompany.central-repository/repo) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) mycompanygroupid:project2-war:war:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=mycompanygroupid -DartifactId=project2-war \ -Dversion=1.0-SNAPSHOT -Dpackaging=war -Dfile=/path/to/file Path to dependency: 1) mycompanygroupid:project3-ear:ear:1.0-SNAPSHOT 2) mycompanygroupid:project2-war:war:1.0-SNAPSHOT -- 1 required artifact is missing. for artifact: mycompanygroupid:project3-ear:ear:1.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), mycompany.central-repository (http://mycompany.central-repository/repo) If I follow this instructions and install my WAR file to my local repository, it then works and makes my EAR project, but I believe it shouldn't be necessary. -- 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] Reopened: (MAVENUPLOAD-1668) HtmlUnit 1.12 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Guillemot reopened MAVENUPLOAD-1668: - htmlunit-1.12.pom is listed in http://www.ibiblio.org/maven/htmlunit/poms/ but the pom is not available: only an error page is delivered. HtmlUnit 1.12 upload request Key: MAVENUPLOAD-1668 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1668 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot Assignee: Carlos Sanchez http://htmlunit.sourceforge.net/htmlunit-1.12-bundle.jar Team members, including myself: http://htmlunit.sourceforge.net/team-list.html http://sourceforge.net/project/memberlist.php?group_id=47038 -- 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] Reopened: (MRRESOURCES-15) ClassCast Exception happens when depending on the snapshot artifacts
[ http://jira.codehaus.org/browse/MRRESOURCES-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton reopened MRRESOURCES-15: I tried to bump Doxia to the new maven-parent:pom:6 (wich uses maven-remote-resources-plugin:1.0-alpha-5) and I got this exception. Here are the steps te reproduce it: * bump the parent of trunks/doxia/doxia/pom.xml (r566642) and install it * try to install sandbox/doxia/doxia-maven-plugin ClassCast Exception happens when depending on the snapshot artifacts Key: MRRESOURCES-15 URL: http://jira.codehaus.org/browse/MRRESOURCES-15 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-alpha-3 Reporter: Balaji Ravi Assignee: Daniel Kulp Priority: Critical Fix For: 1.0-alpha-4 The remote resources plugin throws the following ClassCastException when there are snapshot artifacts. INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.model.Repository [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.model.Repository at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.mergeMetadata(DefaultRepositoryMetadataManager.java:161) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.resolve(DefaultRepositoryMetadataManager.java:134) at org.apache.maven.artifact.transform.AbstractVersionTransformation.res olveVersion(AbstractVersionTransformation.java:65) at org.apache.maven.artifact.transform.SnapshotTransformation.transformF orResolve(SnapshotTransformation.java:63) at org.apache.maven.artifact.transform.DefaultArtifactTransformationMana ger.transformForResolve(DefaultArtifactTransformationManager.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:114) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:482) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1194) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:697) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromReposito ry(DefaultMavenProjectBuilder.java:230) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.g etProjects(ProcessRemoteResourcesMojo.java:408) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.e xecute(ProcessRemoteResourcesMojo.java:273) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) 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(DelegatingMethodAcces sorImpl.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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly
[jira] Closed: (MAVENUPLOAD-1668) HtmlUnit 1.12 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1668. --- Resolution: Fixed http://repo1.maven.org/maven2/htmlunit/htmlunit/1.12/ HtmlUnit 1.12 upload request Key: MAVENUPLOAD-1668 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1668 Project: maven-upload-requests Issue Type: Task Reporter: Marc Guillemot Assignee: Carlos Sanchez http://htmlunit.sourceforge.net/htmlunit-1.12-bundle.jar Team members, including myself: http://htmlunit.sourceforge.net/team-list.html http://sourceforge.net/project/memberlist.php?group_id=47038 -- 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: (MRRESOURCES-15) ClassCast Exception happens when depending on the snapshot artifacts
[ http://jira.codehaus.org/browse/MRRESOURCES-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton updated MRRESOURCES-15: --- Fix Version/s: (was: 1.0-alpha-4) 1.0-alpha-6 ClassCast Exception happens when depending on the snapshot artifacts Key: MRRESOURCES-15 URL: http://jira.codehaus.org/browse/MRRESOURCES-15 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-alpha-3 Reporter: Balaji Ravi Assignee: Daniel Kulp Priority: Critical Fix For: 1.0-alpha-6 The remote resources plugin throws the following ClassCastException when there are snapshot artifacts. INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.model.Repository [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.model.Repository at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.mergeMetadata(DefaultRepositoryMetadataManager.java:161) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.resolve(DefaultRepositoryMetadataManager.java:134) at org.apache.maven.artifact.transform.AbstractVersionTransformation.res olveVersion(AbstractVersionTransformation.java:65) at org.apache.maven.artifact.transform.SnapshotTransformation.transformF orResolve(SnapshotTransformation.java:63) at org.apache.maven.artifact.transform.DefaultArtifactTransformationMana ger.transformForResolve(DefaultArtifactTransformationManager.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:114) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:482) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1194) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:697) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromReposito ry(DefaultMavenProjectBuilder.java:230) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.g etProjects(ProcessRemoteResourcesMojo.java:408) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.e xecute(ProcessRemoteResourcesMojo.java:273) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) 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(DelegatingMethodAcces sorImpl.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) -- 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: (MRRESOURCES-15) ClassCast Exception happens when depending on the snapshot artifacts
[ http://jira.codehaus.org/browse/MRRESOURCES-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MRRESOURCES-15. -- Assignee: Vincent Siveton (was: Daniel Kulp) Resolution: Fixed Fixed in r566658 o renamed remoteRepositories to repositories to be more clear o added remoteArtifactRepositories field and use it, if artifact is a snapshot ClassCast Exception happens when depending on the snapshot artifacts Key: MRRESOURCES-15 URL: http://jira.codehaus.org/browse/MRRESOURCES-15 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-alpha-3 Reporter: Balaji Ravi Assignee: Vincent Siveton Priority: Critical Fix For: 1.0-alpha-6 The remote resources plugin throws the following ClassCastException when there are snapshot artifacts. INFO] [ERROR] FATAL ERROR [INFO] [INFO] org.apache.maven.model.Repository [INFO] [INFO] Trace java.lang.ClassCastException: org.apache.maven.model.Repository at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.mergeMetadata(DefaultRepositoryMetadataManager.java:161) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetada taManager.resolve(DefaultRepositoryMetadataManager.java:134) at org.apache.maven.artifact.transform.AbstractVersionTransformation.res olveVersion(AbstractVersionTransformation.java:65) at org.apache.maven.artifact.transform.SnapshotTransformation.transformF orResolve(SnapshotTransformation.java:63) at org.apache.maven.artifact.transform.DefaultArtifactTransformationMana ger.transformForResolve(DefaultArtifactTransformationManager.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:114) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(De faultArtifactResolver.java:73) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepo sitory(DefaultMavenProjectBuilder.java:482) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(D efaultMavenProjectBuilder.java:1194) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(Def aultMavenProjectBuilder.java:697) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromReposito ry(DefaultMavenProjectBuilder.java:230) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.g etProjects(ProcessRemoteResourcesMojo.java:408) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.e xecute(ProcessRemoteResourcesMojo.java:273) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) 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(DelegatingMethodAcces sorImpl.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) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (MCOMPILER-57) State default source (1.3) and target (1.1) in the documentation
[
http://jira.codehaus.org/browse/MCOMPILER-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105003
]
Gisbert Amm commented on MCOMPILER-57:
--
respective thread on the mailing list:
http://www.nabble.com/Why-does-Maven2-by-default-generate-Java-1.1-byte-code--tf4273477s177.html#a12163158
State default source (1.3) and target (1.1) in the documentation
Key: MCOMPILER-57
URL: http://jira.codehaus.org/browse/MCOMPILER-57
Project: Maven 2.x Compiler Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Gisbert Amm
Priority: Trivial
The documentation does currently say nothing about the compiler defaults,
especially source and target version, which is 1.3 and 1.1 (byte code 45.3).
It would be helpful to add this information to the docs to make the defaults
obvious.
Respective mailing list content:
This has been discussed several times on this list.
IMO, the default compilation target being 1.1 (or another hard-defined
version) meets the rule of least surprise. You can argue that you
don't like 1.1 and you'd prefer 1.3 or even 1.5 but that is another
discussion.
In contrast, the rule of most surprise would be my build changes when
I change my JDK or my build changes when I build things on different
machines. This is the absolute worst thing you can run into when
trying to standardize and control your build process.
If you want to target a specific JDK, then simply add the compiler
configuration in your poms. If you feel this has not been documented
sufficiently, then post a RFE in Jira and someone will add some text
to the proper page(s) on the site.
Wayne
On 8/15/07, Gisbert Amm [EMAIL PROTECTED] wrote:
Searching for version issues, I had a closer look at the *.class files
generated by Maven2 with the default compiler settings and found that
the first bytes of them are cafe babe 0003 002D ..., which is byte
code version 45.3 = Java 1.1.
First I was believing that I had this (target 1.1) configured somewhere
by accident. However, I didn't find any such configuration, therefore I
dug into the plexus-compiler source and found the following in
plexus-site/plexus-components/plexus-compiler/plexus-compilers/plexus-compiler-javac/src/main/java/org/codehaus/plexus/compiler/javac/JavacCompiler.java:
// TODO: this could be much improved
if ( StringUtils.isEmpty( config.getTargetVersion() ) )
{
// Required, or it defaults to the target of your JDK (eg 1.5)
args.add( -target );
args.add( 1.1 );
}
else
{
args.add( -target );
args.add( config.getTargetVersion() );
}
if ( !suppressSource( config ) StringUtils.isEmpty(
config.getSourceVersion() ) )
{
// If omitted, later JDKs complain about a 1.1 target
args.add( -source );
args.add( 1.3 );
}
Is there any particular reason why target is set to 1.1 here? IMHO, it
breaks the rule of least surprise for I am certainly expecting that the
generated byte code by default has the version of the JDK I'm using the
compiler of. The comment Required, or it defaults to the target of your
JDK doesn't give any reason. Does anybody know, why this default is set?
At least it should be mentioned on
http://maven.apache.org/plugins/maven-compiler-plugin/howto.html to make
it obvious to users. Otherwise people might have problems and need a
long time to find out what's going on (see
http://www.nabble.com/Odd-Compilation-Issue-tf1566644s177.html#a4287495
for an example).
Regards,
Gisbert
--
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-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105017 ] Wendy Smoak commented on CONTINUUM-1234: Brett, any thoughts on this as you work with the project groups and permissions on vmbuild? Improve user role management - Key: CONTINUUM-1234 URL: http://jira.codehaus.org/browse/CONTINUUM-1234 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: Future With three roles per project group, even a moderate number of groups means a very long list of roles to look through when assigning roles to users. There is no way to sort the roles, and they seem to be listed in the order the project groups were added to Continuum. Consider listing the project group roles in a grid, with 'User' 'Developer' and 'Administrator' across the top, and the project group name down the side. Also, the name of the role is misleading, it says Project User when it is really Project Group User -- we don't have per-project roles, just per-group roles. -- 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-3116) maven.test.skip=true should not skip test compilation/packaging
[ http://jira.codehaus.org/browse/MNG-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105020 ] Florian Kirchmeir commented on MNG-3116: @Tim Tomislav: Yep, that's exactly what I was looking for! Thanks for pointing me at it! @Marcel: Hm, I'd have to experiment with that, since it's not quite obvious to me what will happen. Will this have the same effect, i.e. classes in src/test still being compiled and packaged, but not executed? Even so, I think skipExec is better suited in my case, since it's obvious what's supposed to happen. @Helton: Well, that will compile my test-classes, but won't package them with my application. :-( @all: I'm closing this issue. maven.test.skip=true should not skip test compilation/packaging --- Key: MNG-3116 URL: http://jira.codehaus.org/browse/MNG-3116 Project: Maven 2 Issue Type: Improvement Affects Versions: 2.0.7 Reporter: Florian Kirchmeir Hi! I'm raising an issue that has already been noted for Maven 1.x. See: http://jira.codehaus.org/browse/MPTEST-51 In our case, we're running into this problem because our build-machine is different from the test-machine. So, when building the application, tests must not be executed, but still be compiled and packaged! Currently, when setting maven.test.skip=true, compilation and packaging will be skipped as well. We'd need a way to skip test execution only! Best regards, Florian Kirchmeir -- 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: (MJAR-81) Ability to list Class-Path: elements individually
Ability to list Class-Path: elements individually - Key: MJAR-81 URL: http://jira.codehaus.org/browse/MJAR-81 Project: Maven 2.x Jar Plugin Issue Type: New Feature Environment: All Reporter: Robert Egan Priority: Minor I'd like a method to list my classpath elements in a manner other than in one long string. For example, one of my production jars contains the following entry Class-Path: plugins/framework plugins/checkservices plugins/transferse rvices plugins/alerts plugins/pr plugins/pr/achapps plugins/pr/wireap ps securityUtil-hotfix.jar securityUtil.jar wcmCache-hotfix.jar wcmCa che.jar wcmPrincipals-hotfix.jar wcmPrincipals.jar lib/gnu/gnu-crypt o.jar lib/oracle/jdbc-10.2.0.1.0/ojdbc14.jar lib/oracle/jdbc-10.2.0.1 .0/jdbc_rowset_tiger1.0.1mrel-ri/rowset.jar lib/jdom/jdom-1.0/jdom.ja r lib/emory.edu/backport-util-concurrent-2.2/backport-util-concurrent .jar lib/apache/jakarta-commons/commons-cli-1.0.jar lib/apache/jakart a-commons/commons-collections-3.1.jar lib/apache/jakarta-commons/comm ons-dbcp-1.2.1.jar lib/apache/jakarta-commons/commons-lang-2.1.jar li b/apache/jakarta-commons/commons-pool-1.2.jar lib/apache/jakarta-comm ons/commons-logging-1.0.4/commons-logging.jar lib/rsa/authapi.jar lib /apache/log4j/log4j-1.2.8.jar lib/jradius/jradius.jar lib/jradius/jra dius-dictionary.jar lib/httpclient/commons-codec-1.3.jar lib/httpclie nt/commons-httpclient-3.0.jar lib/apache/JCS/jcs-1.2.6.8.jar lib/oswe go.edu/util-concurrent-1.3.4.jar And it sure would be nice to have something like classpath entryplugins/framework/entry entryplugins/checkservices/entry entryplugins/transferservices/entry entry...etc/entry /classpath -- 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: (MRELEASE-271) perform goal sometimes fails with multi-module projects
[ http://jira.codehaus.org/browse/MRELEASE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105025 ] werner mueller commented on MRELEASE-271: - hallo today the very same thing happened here too. the same parent-pom and release was running before. i did move it in subversion and updated the scm connection settings. the release:perform goal fails while it tries to find a dependency it is supposed to create. the mentioned workaround in maven.users list: $ mvn release:prepare -DpreparationGoals=clean install solves this issue so i can release again. but well it is kinda weird this came out of nowhere. perform goal sometimes fails with multi-module projects --- Key: MRELEASE-271 URL: http://jira.codehaus.org/browse/MRELEASE-271 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4, 2.0-beta-6 Environment: XP Reporter: David Hoffer Attachments: MavenReleaseFailure.zip, SuccessfulReleaseBuild.txt We have a multi-module maven project that has recently started failing in the release:perform goal. We have just added a couple more modules but do not know if that is the cause of the failure. It seems that the release:perform fails to compile the source after the SCM tag and checkout. The failure says that it cannot find a dependent jar but it is that jar that it is supposed to be building and releasing! I updated to use the latest 2.0-beta-6 release plugin version but this did not help. Upon receiving feedback in the maven users group that others have seen this behavior I followed their advise and added configuration preparationGoalsclean install/preparationGoals/configuration to my parent pom which did fix the problem. Why is the release goal failing now? When do I and when do I not need these changes to my pom? I will attach pom and build logs in hopes this can be fixed soon, let me know if you need additional information. -Dave -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105039 ] David Hoffer commented on MNG-3092: --- Since this issue has been closed you might want to watch/vote for MNG-3092 which replaces it. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: http://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105043 ] David Hoffer commented on MNG-3092: --- Oops I didn't mean to add that last comment... What is the status of this issue? I have not been able to post to the above mentioned email thread. Version ranges with non-snapshot bounds can contain snapshot versions - Key: MNG-3092 URL: http://jira.codehaus.org/browse/MNG-3092 Project: Maven 2 Issue Type: Bug Components: Dependencies Reporter: Mark Hobson Attachments: MNG-3092.patch Contrary to the 2.0 design docs: Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. -- from http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification The following is equates to true: VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new DefaultArtifactVersion( 1.1-SNAPSHOT ) ) The attached patch only allows snapshot versions to be contained in a range if they are equal to one of the boundaries. Note that this is a strict equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-3001) Maven2 does not resolve version ranges correctly [PATCH INCLUDED]
[ http://jira.codehaus.org/browse/MNG-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105041 ] David Hoffer commented on MNG-3001: --- Since this issue has been closed you might want to watch/vote for MNG-3092 which replaces it. Maven2 does not resolve version ranges correctly [PATCH INCLUDED] - Key: MNG-3001 URL: http://jira.codehaus.org/browse/MNG-3001 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4, 2.0.6 Environment: Windows. Affects versions 2.04 2.06 minimum. Reporter: David Hoffer Assignee: Mark Hobson Priority: Blocker Fix For: Reviewed Pending Version Assignment Attachments: VersionRangeSnapshotFix.patch Maven does not properly handle version ranges when the high end is unbounded. The spec clearly states that it should not resolve to a SNAPSHOT unless included as an explicit boundary. Currently maven2 does resolve to a SNAPSHOT which makes usage of version ranges to control versions of dependencies unworkable. (We currently use a local build of maven with this fix else we could not use version ranges. This is a major issue can you please include in the next release?) Code fix and unit tests are included. Example: dependency groupIdmyGroup/groupId artifactIdmyArtifact/artifactId version[1.0,)/version /dependency This version range can resolve to the latest development 1.0-SNAPSHOT. All artifact dependencies should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This should resolve to any released version of 1.1 or higher. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. I think this requirement was forgotten when version ranges were implemented. I have included a patch for this bug. The fix is in the containsVersion method of VersionRange. I have added tests in VersionRangeTest and DefaultArtifactCollectorTest. All tests in maven pass with this fix. -- 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-90) IDEA Plugin does not resolve version ranges correctly
[ http://jira.codehaus.org/browse/MIDEA-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105048 ] David Hoffer commented on MIDEA-90: --- Since this issue is related to MNG-3092 you might want to watch/vote for it. IDEA Plugin does not resolve version ranges correctly - Key: MIDEA-90 URL: http://jira.codehaus.org/browse/MIDEA-90 Project: Maven 2.x IDEA Plugin Issue Type: Bug Affects Versions: 2.0, 2.1 Environment: Xp Pro SP2 Reporter: David Hoffer Similar to MRELEASE-134 in maven-release-plugin version[1.1.0,)/version This version range can resolve to the latest dev SNAPSHOT. The idea plugin should ignore SNAPSHOTS as that is not intended by the unbounded high end of the version range. This document: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges addressed the requirements for version ranges and stated that Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. I think this requirement was forgetten when version ranges were implemented. -- 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-1674) Upload JYaml To maven repo
Upload JYaml To maven repo -- Key: MAVENUPLOAD-1674 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1674 Project: maven-upload-requests Issue Type: New Feature Reporter: Toby Ho Attachments: jyaml.sh I would like to put JYaml into the main maven2 repo. Thanks. -- 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-1675) com.lamatek.googlemaps 0.98c (googlemaps jsp tag library)
com.lamatek.googlemaps 0.98c (googlemaps jsp tag library) - Key: MAVENUPLOAD-1675 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1675 Project: maven-upload-requests Issue Type: Task Reporter: fabrizio giustina -- 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: (MAVENUPLOAD-1674) Upload JYaml To maven repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toby Ho updated MAVENUPLOAD-1674: - Attachment: jyaml.sh Sorry, I made a mistake in the first attachment. This one has the correction. Upload JYaml To maven repo -- Key: MAVENUPLOAD-1674 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1674 Project: maven-upload-requests Issue Type: New Feature Reporter: Toby Ho Attachments: jyaml.sh, jyaml.sh I would like to put JYaml into the main maven2 repo. Thanks. -- 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: (SUREFIRE-348) Proivde a surefire aggregate option for report-only mojo
Proivde a surefire aggregate option for report-only mojo Key: SUREFIRE-348 URL: http://jira.codehaus.org/browse/SUREFIRE-348 Project: Maven Surefire Issue Type: New Feature Components: report plugin Affects Versions: 2.3 Reporter: John Allen I have recently modified many plugins to provide aggregate features that aggregate their respective reports for contained sub-n-modules (inc. sub-sub etc) up the *module* hierarchy (ie not inheritance hierarchy that may be unrelated to the reactor and module structure) and would like to see this for surefire. This enables use view reports for various levels of sub-systems resulting in top level reports that cover an entire solution. I would like to request this feature for the report-only mojo (god knows how you;d do it for the forking surefire:report one) My recommendation is either to separate aggregate into a separate mojo that pulls the surefire result xml files up the tree, merging them as it goes and then have report-only simply knock out a report for the, now aggregated report files it finds when its run as part of site. With is the site generation model one binds these kinds of site preprocessing mojos, that themselves tend to be able to @aggregatorrs (thus also getting round the bug where reporting mojos cant be aggregators) to the pre-site phase. This is our preferred technique to site building where one treats analysis a part of the normal build lifecycle (for how else would one be able to run checkers that read the analysis and fail the build if thresholds are breached?) and reporting do nothing but report on the data that has been produced by the normal build and analysis phases (ie no evil forked lifecycles). The alternative is to pull the data up to the scope that the report-only mojo is running at from the sub-n-modules beneath it before it then reports on it. The mojo obviously gets run for each level of the module hierarchy as the reactor is processed. This can be optimised to do all the work at the top most module if one wants - i.e. build the merged aggregated data files for all the sub-modules on those modules behalf, as it builds its top-most aggregated data file (ie it populates sub-module target/surefire directories with their merged report xml for them as it needs this info for its report). Note I do not know (or like) why the assumptions present in Javadoc and JXR that if one want to aggregate one only wants to aggregate to the top most project.. -- 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-3154) Declaring a site with a file:// location one layer deep results in site-deploy failure
Declaring a site with a file:// location one layer deep results in site-deploy failure -- Key: MNG-3154 URL: http://jira.codehaus.org/browse/MNG-3154 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.0.4 Reporter: Tom Guyette To reproduce: 1 - Create a project that has a site declaration that uses a urlfile:///usr/local/test//url 2 - Make sure the directory /usr/local/test exists and has appropriate write permissions 3 - Run site-deploy on the project 4 - Receive error that looks something like this: [INFO] [site:deploy] file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar - Session: Opened file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar - Session: Disconnecting file:///usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar - Session: Disconnected [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error uploading site Embedded error: Error copying directory structure /usr/local/m2-websites/transport-webservice/site/transport-webservice-xmlbeans-jar/./checkstyle.html (No such file or directory) 5 - Change the site url such that maven will have to create *TWO NEW* layers of directory, run site-deploy, note that it works! 6 - Change the site url such that maven will have to create ZERO new layers of directory, run site-deploy, note that it also works! site-deploy only seems to fail in the case where Maven has to create a single subdirectory for the current project. It looks like wagon doesn't realize it has to create the first layer of directory... possibly something to do with explicit mention of . as a directory in the wagon code. -- 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-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105060 ] Brett Porter commented on CONTINUUM-1234: - sounds good to me. What about the roles that don't fit this category though? Like the user/sys admin? Improve user role management - Key: CONTINUUM-1234 URL: http://jira.codehaus.org/browse/CONTINUUM-1234 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: Future With three roles per project group, even a moderate number of groups means a very long list of roles to look through when assigning roles to users. There is no way to sort the roles, and they seem to be listed in the order the project groups were added to Continuum. Consider listing the project group roles in a grid, with 'User' 'Developer' and 'Administrator' across the top, and the project group name down the side. Also, the name of the role is misleading, it says Project User when it is really Project Group User -- we don't have per-project roles, just per-group roles. -- 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-1391) Missing Download as text link
Missing Download as text link Key: CONTINUUM-1391 URL: http://jira.codehaus.org/browse/CONTINUUM-1391 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1-beta-1 Environment: xp Reporter: Dan Tran Continuum 1.0.3 provides a link to get a build log in full page which I find it very friendly to view the log. I dont see it in 1.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] Created: (CONTINUUM-1392) Continuum tests require too much external set up
Continuum tests require too much external set up Key: CONTINUUM-1392 URL: http://jira.codehaus.org/browse/CONTINUUM-1392 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-beta-2 Reporter: Brett Porter the installation tests fail if M2_HOME is not set (and exported in bash). However, I'm opening this as a more general bug since many unit tests seem to require having Maven involved which is both time consuming and the cause of annoying issues. -- 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-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105062 ] Henry S. Isidro commented on CONTINUUM-1234: I'm thinking of separating the interface into two parts, one a list of checkboxes for the non-templated roles and a grid of checkboxes for the templated roles (the project group roles). These checkboxes would be a toggle where the user can check or uncheck roles for the user. Comments? Improve user role management - Key: CONTINUUM-1234 URL: http://jira.codehaus.org/browse/CONTINUUM-1234 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: Future With three roles per project group, even a moderate number of groups means a very long list of roles to look through when assigning roles to users. There is no way to sort the roles, and they seem to be listed in the order the project groups were added to Continuum. Consider listing the project group roles in a grid, with 'User' 'Developer' and 'Administrator' across the top, and the project group name down the side. Also, the name of the role is misleading, it says Project User when it is really Project Group User -- we don't have per-project roles, just per-group roles. -- 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-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105063 ] Brett Porter commented on CONTINUUM-1234: - that seems to fit. Want to mock it up in html first so we can take a look? Improve user role management - Key: CONTINUUM-1234 URL: http://jira.codehaus.org/browse/CONTINUUM-1234 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: Future With three roles per project group, even a moderate number of groups means a very long list of roles to look through when assigning roles to users. There is no way to sort the roles, and they seem to be listed in the order the project groups were added to Continuum. Consider listing the project group roles in a grid, with 'User' 'Developer' and 'Administrator' across the top, and the project group name down the side. Also, the name of the role is misleading, it says Project User when it is really Project Group User -- we don't have per-project roles, just per-group roles. -- 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: (CONTINUUM-1234) Improve user role management
[ http://jira.codehaus.org/browse/CONTINUUM-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry S. Isidro updated CONTINUUM-1234: --- Attachment: proposed_ui.html Here's a mock up of the proposed user roles UI. This should be done in redback, do we have an open issue for this? Improve user role management - Key: CONTINUUM-1234 URL: http://jira.codehaus.org/browse/CONTINUUM-1234 Project: Continuum Issue Type: Improvement Components: Web - UI Affects Versions: 1.1-alpha-1 Reporter: Wendy Smoak Fix For: Future Attachments: proposed_ui.html With three roles per project group, even a moderate number of groups means a very long list of roles to look through when assigning roles to users. There is no way to sort the roles, and they seem to be listed in the order the project groups were added to Continuum. Consider listing the project group roles in a grid, with 'User' 'Developer' and 'Administrator' across the top, and the project group name down the side. Also, the name of the role is misleading, it says Project User when it is really Project Group User -- we don't have per-project roles, just per-group roles. -- 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: (SUREFIRE-349) redirectTestOutputToFile truncates summary information
redirectTestOutputToFile truncates summary information -- Key: SUREFIRE-349 URL: http://jira.codehaus.org/browse/SUREFIRE-349 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.4 Reporter: Jason T. Greene In the current 2.4-SNAPSHOT, Instead of the normally expected --- T E S T S --- Running org.jboss.cache.FqnTest Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.439 sec Results : Tests run: 26, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD SUCCESSFUL [INFO] You get: --- T E S T S --- [INFO] [INFO] BUILD SUCCESSFUL [INFO] -- 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] Work started: (MASSEMBLY-222) 2.2-beta-1 regression in assembly descriptor interpolation
[
http://jira.codehaus.org/browse/MASSEMBLY-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MASSEMBLY-222 started by John Casey.
2.2-beta-1 regression in assembly descriptor interpolation
--
Key: MASSEMBLY-222
URL: http://jira.codehaus.org/browse/MASSEMBLY-222
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-1
Reporter: Max Bowsher
Assignee: John Casey
Priority: Blocker
Fix For: 2.2-beta-2
I have found a significant change in behaviour between 2.1 and 2.2-beta-1,
using the following assembly descriptor:
{code:xml}
assembly
iddist/id
formats
formattar.gz/format
/formats
includeBaseDirectoryno/includeBaseDirectory
fileSets
fileSet
outputDirectory/foobar-${version}/outputDirectory
includes
includeREADME.txt/include
includechangelog.txt/include
includejava.policy/include
/includes
/fileSet
fileSet
directorytarget/directory
outputDirectory/foobar-${version}/jars/outputDirectory
includes
includefoobar-${version}.jar/include
/includes
/fileSet
fileSet
directorysrc/main/scripts/directory
outputDirectory/foobar-${version}/bin/outputDirectory
fileMode0755/fileMode
/fileSet
/fileSets
dependencySets
dependencySet
outputDirectory/foobar-${version}/jars/outputDirectory
unpackfalse/unpack
/dependencySet
/dependencySets
/assembly
{code}
Using 2.1, ${version} interpolates with the version of the project being
assembled.
Using 2.2-beta-1, the ${version} in the dependencySet interpolates with the
version of each individual dependency, leading to the depenencySet being
scattered across many directories.
--
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
