[jira] Commented: (MRM-619) Update docs/site for some corrections
[ http://jira.codehaus.org/browse/MRM-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116568 ] Maria Odea Ching commented on MRM-619: -- Also update the docs to include what is suggested here: http://www.nabble.com/Repository-scanning-cron-vs.-Database-update-cron-to14149717.html Update docs/site for some corrections - Key: MRM-619 URL: http://jira.codehaus.org/browse/MRM-619 Project: Archiva Issue Type: Task Components: documentation Affects Versions: 1.0 Reporter: Maria Odea Ching Priority: Minor Fix For: 1.1 In quick steps (archiva site), the numbering is 1,2,3,4,5,5. In Installing in Tomcat page, update the ff: - war file name (should be archiva-webapp-1.0.war) - mail-[version].jar should also be added in the tomcat common/lib directory -- 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: (MRM-614) User validation message has incorrect URL
[ http://jira.codehaus.org/browse/MRM-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-614: - Fix Version/s: 1.1 User validation message has incorrect URL - Key: MRM-614 URL: http://jira.codehaus.org/browse/MRM-614 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0 Reporter: Nicholas Daley Fix For: 1.1 The URL that was sent in the validation email lost the port and the prefix path for archiva's context. i.e. the URL sent in the email was http://192.168.0.100/security/login!login.action?validateMe=1a9e7e81b84f4c56a5deaa752343a212 it should have been http://192.168.0.100:8080/archiva/security/login!login.action?validateMe=1a9e7e81b84f4c56a5deaa752343a212 -- 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: (MRM-617) Reporting does not work due to bug in client-side JavaScript validation
[
http://jira.codehaus.org/browse/MRM-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Odea Ching updated MRM-617:
-
Fix Version/s: 1.1
Reporting does not work due to bug in client-side JavaScript validation
---
Key: MRM-617
URL: http://jira.codehaus.org/browse/MRM-617
Project: Archiva
Issue Type: Bug
Components: reporting
Affects Versions: 1.0
Environment: Win32
Firefox 2.0.0.9 or MSIE 6.0
German system
Reporter: Arne Degenring
Fix For: 1.1
No matter what Row Count I choose in Manage | Reports, I get the error
message Row count must be between 10 and 5000.. After disabling JavaScript,
which disables the client-side validation, it works.
I tracked it down to the following line in the JavaScript function
validateForm_generateReport() that is included into the pickReport page
508 if (parseInt(field.value)
509 10 ||
510 parseInt(field.value)
511 5.000) {
The problem is the decimal point in the number 5.000. At least on my
system, this is interpreted as 5, not 5000.
--
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: (MRM-619) Update docs/site for some corrections
[ http://jira.codehaus.org/browse/MRM-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-619: - Fix Version/s: 1.1 Update docs/site for some corrections - Key: MRM-619 URL: http://jira.codehaus.org/browse/MRM-619 Project: Archiva Issue Type: Task Components: documentation Affects Versions: 1.0 Reporter: Maria Odea Ching Priority: Minor Fix For: 1.1 In quick steps (archiva site), the numbering is 1,2,3,4,5,5. In Installing in Tomcat page, update the ff: - war file name (should be archiva-webapp-1.0.war) - mail-[version].jar should also be added in the tomcat common/lib directory -- 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: (MRM-608) Unable to find project model for [...] if the initial import of the POM failed
[ http://jira.codehaus.org/browse/MRM-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-608: - Fix Version/s: 1.1 Unable to find project model for [...] if the initial import of the POM failed --- Key: MRM-608 URL: http://jira.codehaus.org/browse/MRM-608 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0 Environment: Windows32 Reporter: Arne Degenring Priority: Critical Fix For: 1.1 Attachments: archiva.log, data.zip It seems that Archiva is not properly updating the database if the initial import of the POM failed due to a parse error, even after the original problem has been corrected, the repository has been rescanned, and the database updated again. Steps to reproduce: 1. Start with a fresh Archiva 1.0 installation 2. Drop a group containing an artifact with a broken POM (illegal XML) to Archiva's internal repo directory 3. Run Scan Repository Now and Update Database Now. The log shows a ProjectModelException because the broken POM could not be parsed. 4. Fix the broken POM. Run Scan Repository Now and Update Database Now again. 5. Use the Browse page to browse to the artifact - you get the error message: Unable to find project model for [junit:junit:3.7]. I've attached the zipped contents of the data directory after performing the steps above, and the log file. Notice that there might be general repository scanning problem in 1.0 that could be related, see http://www.nabble.com/Repository-scanning-problem-in-1.0--tf4897121.html -- 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: (MRM-622) database not being updated with project model information
[ http://jira.codehaus.org/browse/MRM-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-622: - Fix Version/s: 1.1 database not being updated with project model information - Key: MRM-622 URL: http://jira.codehaus.org/browse/MRM-622 Project: Archiva Issue Type: Bug Affects Versions: 1.0 Environment: OS: Windows XP Software: Java 5 Update 12 and Maven 2.0.4 Reporter: Dário Oliveros Fix For: 1.1 I noticed Archiva database was not being updated with project model information in the following scenario: 1) Project B (1.0-SNAPSHOT) depends on Project A (1.0) 2) Project B is deployed to Archiva repository 3) Project B changes Project A dependency version from 1.0 to 1.1-SNAPSHOT 4) Project B is deployed to Archiva repository again. 5) The user executes 'Scan Repository Now' and 'Update Database Now' using Archiva. At this point, if you browse project B, you'll notice it still keeps the reference to the former version of Project A, 1.0, and not 1.1-SNAPSHOT. However, if you download the POM file, you will see it has the lastet dependency version as expected. NOTE: In project B POM file the snapshotRepository is configured with uniqueVersion equals to false. -- 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: (MRM-594) add some minimal hook in LegacyPathParser to allow exception management in artifact resolution
[
http://jira.codehaus.org/browse/MRM-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Odea Ching updated MRM-594:
-
Fix Version/s: (was: 1.1)
1.0.1
add some minimal hook in LegacyPathParser to allow exception management in
artifact resolution
--
Key: MRM-594
URL: http://jira.codehaus.org/browse/MRM-594
Project: Archiva
Issue Type: Improvement
Components: repository interface
Affects Versions: 1.0-beta-4
Reporter: nicolas de loof
Fix For: 1.0.1
Attachments: MRM-594-with-web-ui.patch, MRM-594.patch
Some existing artifacts are not available to maven1. jaxen-1.0-FCS-full for
example (use by some core maven1 plugins) can only be obtained by specifying
a classifier full.
The maven1 request /jaxen/jars/jaxen-1.0-FCS-full.jar is converted as
artifact [ jaxen : jaxen : 1.0-FCS-full ], that doesn't exist.
The LegacyPathParser is allready very complex and works for many artifact,
but cannot handle classifiers as they can be any string.
A solution to help archiva managers should be to use an resolution exception
list :
if ( exceptions.contains( path ) )
{
String exception = exceptions.getProperty( path );
String[] ref = exception.split( : );
artifact.setGroupId( ref[0] );
artifact.setArtifactId( ref[1] );
artifact.setVersion( ref[2] );
if ( ref.length 3 )
{
artifact.setClassifier( ref[3] );
}
return artifact;
}
based on a simple properties file :
jaxen/jars/jaxen-1.0-FCS-full.jar = jaxen:jaxen:1.0-FCS:full
This would allow admins to quickly fix such issues and not require archiva to
find a way to make legacy path deterministic.
--
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: (MRM-606) docs appear in wrong directory for Archiva 1.0 release
[ http://jira.codehaus.org/browse/MRM-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching updated MRM-606: - Fix Version/s: (was: 1.1) 1.0.1 docs appear in wrong directory for Archiva 1.0 release -- Key: MRM-606 URL: http://jira.codehaus.org/browse/MRM-606 Project: Archiva Issue Type: Bug Components: build Affects Versions: 1.0 Reporter: Brett Porter Fix For: 1.0.1 while it is fine on trunk, the docs appear in an archiva-1.0-docs.zip subdirectory of the released distribution - check whether we need to lock down to a better assembly plugin version -- 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: (SCM-360) CVS Tag command doesn't use FileSet (list of files), tagging ALL files in working directory
CVS Tag command doesn't use FileSet (list of files), tagging ALL files in working directory --- Key: SCM-360 URL: http://jira.codehaus.org/browse/SCM-360 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-cvs Affects Versions: 1.x, 2.0 Reporter: Andrei Solntsev Attachments: scm.diff I want to tag ONE file in the working directory. I don't want to tag ALL files. I call SCM Plugin with a FileSet instance which contains only one file. However, CVS provider doesn't use it and tags ALL files in the working directory. -- 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-343) Changelog can be generated with only an end-tag
[ http://jira.codehaus.org/browse/SCM-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116574 ] Andrei Solntsev commented on SCM-343: - This is a useful patch. Why it's not still included in new plugin version? Changelog can be generated with only an end-tag --- Key: SCM-343 URL: http://jira.codehaus.org/browse/SCM-343 Project: Maven SCM Issue Type: Improvement Components: maven-scm-api, maven-scm-provider-cvs Affects Versions: 1.0 Reporter: Roland Asmann Priority: Minor Attachments: scm.diff When given only an end-tag, the changelog was not built correctly -- no tags were included in the command. Changes include: - Check if a tag is given, not if its name is empty - Building a command-line with tags even if one of the tags' names is empty -- 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-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:comment-tabpanel#action_116582 ] Bruno Duarte commented on MRELEASE-163: --- Check: http://www.mail-archive.com/[EMAIL PROTECTED]/msg77348.html It doesn't check the pom module also. BUG: GenerateRealsePomsPhase.java:447 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 Inside my parent pom of a multimodule project, I have something that looks like: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId dependencies dependency groupIdmygroupId/groupId artifactIdbuild-resources/artifactId version1.0-SNAPSHOT/version /dependency ... The snapshot dependencies inside the plugins 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] Created: (MCLOVER-83) contextFilters not applied during build
contextFilters not applied during build - Key: MCLOVER-83 URL: http://jira.codehaus.org/browse/MCLOVER-83 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.3 Environment: Maven 2.0.4 Reporter: Dave Casserly Priority: Minor The contextFilters work fine in the reporting section when generating a site, but they dont work in the build section. I want to apply the contextFilters whilst building so that i can apply a targetPercentage for the build to fail. Thanks 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] Created: (MNG-3319) Reactor cannot detect artifact with exist in project and has test-jar type and test scope
Reactor cannot detect artifact with exist in project and has test-jar type and
test scope
-
Key: MNG-3319
URL: http://jira.codehaus.org/browse/MNG-3319
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle, Reactor and workspace
Affects Versions: 2.0.8
Reporter: Aleksey Solntsev
The fix for MNG-2277 has resolved a lot of problems, first of all for release
procedure.
But we will still has the problem with detecting artifact like this.
dependency
groupIdagillic.models/groupId
artifactIdagillic-processmodel/artifactId
version${project.version}/version
typetest-jar/type
scopetest/scope
/dependency
--
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: (MASSEMBLY-247) versions of included dependencies in multi-module projects are not deterministic
[ http://jira.codehaus.org/browse/MASSEMBLY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116601 ] Tarek El-Sibay commented on MASSEMBLY-247: -- Hi, i have this problem on windows XP but with eclipse 3.2 and without the M2Eclipse plugin. And this problem occured too with a non snapshot version, commons-lang-2.1 was included instead of commons-lang-2.2. But we will try your workaround! Regards Tarek versions of included dependencies in multi-module projects are not deterministic Key: MASSEMBLY-247 URL: http://jira.codehaus.org/browse/MASSEMBLY-247 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1, 2.2-beta-1, 2.2-beta-2 Environment: Maven 2.0.4 an assembly plugin 2.2-SNAPSHOT Reporter: Tarek El-Sibay Attachments: assembly-dependency-problem.zip There is a problem with including dependency jars in an assembly. The resoultion of the version of the dependencies is not deterministic. The attached zipfile contains three projects, assembly, module-One and modue-Two. the assembly project is the aggregator of module-One and module-Two. module-One has a dep to junit 3.8.1, module-Two to junit 4.0. The assembly project contains a DependencyManagement with a dependency to junit 4.0. After executing 'mvn clean package ' in the assembly project the resulting zip file assembly-1.0-SNAPSHOT-luna.zip contains junit 3.8.1, after 'mvn clean install' it contains junit 4.0. Sometimes its the other way around, but playing with both commands shows that the resulting version of junit is not deterministic. -- 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-3163) Profile activation based on hostname or IP
[ http://jira.codehaus.org/browse/MNG-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116610 ] David J. M. Karlsen commented on MNG-3163: -- A more general approach would be to allow profiles to be triggered by shell. properties (not systemproperties). On windows a profile can be triggered by env.COMPUTERNAME and on *nix env.HOSTNAME ootb. Profile activation based on hostname or IP -- Key: MNG-3163 URL: http://jira.codehaus.org/browse/MNG-3163 Project: Maven 2 Issue Type: Improvement Components: Profiles Reporter: David J. M. Karlsen Priority: Minor Fix For: 2.x It would be very nice to be able to activate profiles based on hostname[s] or IP-address[es]. Yes, this could be exported from the system as a systemproperty quite easily on *NIX with -Dhostname=`hostname` but is a little more tricky on other platforms - so why not include it in maven itself? It would be even better if it can be expressed with regex'es or the likes. WDYT? -- 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: (MJAR-71) use manifest in classesdir/META-INF if exists
[
http://jira.codehaus.org/browse/MJAR-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116613
]
Dennis Lundberg commented on MJAR-71:
-
Olivier, your example looks like what I had in mind. Thanks!
use manifest in classesdir/META-INF if exists
-
Key: MJAR-71
URL: http://jira.codehaus.org/browse/MJAR-71
Project: Maven 2.x Jar Plugin
Issue Type: Improvement
Affects Versions: 2.1
Reporter: Carlos Sanchez
Assignee: Olivier Lamy
Fix For: 2.2
Attachments: MJAR-71-disabled_by_default.diff,
MJAR-71-enabled_by_default.diff
With 2.1 I need to add this to the pom to use the manifest that it's already
in the classes folder, make this the default
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.1/version
configuration
archive
manifestFile${project.build.outputDirectory}/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration
/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] Commented: (MRELEASE-273) Regression: NullPointerException at end of standalone release:perform
[
http://jira.codehaus.org/browse/MRELEASE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116614
]
Pavol Juhos commented on MRELEASE-273:
--
This issue prevents us from running mvn release:perform from Hudson
(continuous integration engine)
Do you guys know if maven-release-plugin 2.0-beta-5 is also affected? It might
sufficient for us to force older version of the plugin until this is fixed.
Regression: NullPointerException at end of standalone release:perform
---
Key: MRELEASE-273
URL: http://jira.codehaus.org/browse/MRELEASE-273
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-6
Environment: Maven 2.0.7, maven-release-plugin 2.0-alpha-6
Reporter: Max Bowsher
Priority: Blocker
I executed mvn release:perform -DconnectionUrl=scm:svn:... The actual
performing succeeded, but then the plugin failed with a NullPointerException
- it seems that the plugin attempts to unconditionally run code analogous to
mvn release:clean, but this is inappropriate because release:perform is not
supposed to require a project to be able to run.
Output:
{noformat}
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 28 seconds
[INFO] Finished at: Thu Aug 02 12:53:49 BST 2007
[INFO] Final Memory: 13M/23M
[INFO]
[INFO] Cleaning up after release...
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[DEBUG] Trace
java.lang.NullPointerException
at
org.apache.maven.shared.release.util.ReleaseUtil.getReleasePom(ReleaseUtil.java:73)
at
org.apache.maven.shared.release.util.ReleaseUtil.getStandardPom(ReleaseUtil.java:61)
at
org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.getPomBackup(AbstractBackupPomsPhase.java:37)
at
org.apache.maven.shared.release.phase.AbstractBackupPomsPhase.deletePomBackup(AbstractBackupPomsPhase.java:51)
at
org.apache.maven.shared.release.phase.CreateBackupPomsPhase.clean(CreateBackupPomsPhase.java:70)
at
org.apache.maven.shared.release.DefaultReleaseManager.clean(DefaultReleaseManager.java:427)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:324)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:267)
at
org.apache.maven.shared.release.DefaultReleaseManager.perform(DefaultReleaseManager.java:260)
at
org.apache.maven.plugins.release.PerformReleaseMojo.execute(PerformReleaseMojo.java:102)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
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:280)
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: 39 seconds
[INFO]
[jira] Created: (SCM-361) make cvs tag -F optional
make cvs tag -F optional - Key: SCM-361 URL: http://jira.codehaus.org/browse/SCM-361 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-cvs Affects Versions: 1.0 Reporter: Benoit Decherf Attachments: patch_useForceTag In our cvs server a tag cannot be moved. This is useful to ensure that there is only one version of a component with a same tag. Now, i wan't to integrate all our components to continuum and use it to create releases. The problem is that the scm try to tag the release using cvs tag -F and this fails. I check the code and see that it is hardcoded (in maven-scm-provider-cvs-commons/src/main/java/org/apache/maven/scm/provider/cvslib/command/tag/AbstractCvsTagCommand.java). Is it possible to make it optional ? Or what is the reason to enforce it ? I make a patch to add the option useForceTag. This works, but in case of a conflict with an existing flag, the cvs tag won't failed. (the tag is not set). Is this acceptable ? Or maybe I should check for Warning messages in the output and the command should fail if there are any warnings ? -- 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-1851) Please add antlr's gunit
Please add antlr's gunit Key: MAVENUPLOAD-1851 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1851 Project: maven-upload-requests Issue Type: New Feature Reporter: Kenny MacDermid Hello, I would like to have version 1.0 of antlr's gunit added to the repository. I have confirmed with Terrence Parr and the original gunit author Leon Su that I can make this request. I'm hosting version 1.0 of the source code in a git repository at: http://code.kmdconsulting.ca/gunit.git I will be actively modifying this project to add a set of unit tests and extend the functionality. I will further expand the pom.xml when I do so that it more closely matches the required repository format, and can hopefully sync directly after that point. If you want confirmation from Terence please email him directly. If you don't want to use my cleaned up version of the code, it's also available in a in a jar (with the src in the jar) at: http://www.antlr.org/wiki/display/ANTLR3/gUnit+-+Grammar+Unit+Testing -- 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: (NMAVEN-98) Dotnet simple archetype does not include unit tests
Dotnet simple archetype does not include unit tests --- Key: NMAVEN-98 URL: http://jira.codehaus.org/browse/NMAVEN-98 Project: NMaven Issue Type: Improvement Reporter: Teodoro Cue Jr. Building a project created from the dotnet-simple archetype produces: [INFO] [compile:testCompile] [INFO] NMAVEN-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version = 2.0.5 0727, Framework Version = 2.0.50727, Executable Paths = [C:\WINDOWS\Microsoft.NE T\Framework\v2.0.50727] [INFO] NMAVEN-068-002: No source files to compile. [INFO] Mojo Execution Time = 0 [INFO] [test:test] [INFO] NMAVEN-1100-001: No Unit Tests The dotnet-simple archetype should include an NUnit test case. -- 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: (NMAVEN-98) Dotnet simple archetype does not include unit tests
[ http://jira.codehaus.org/browse/NMAVEN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Teodoro Cue Jr. updated NMAVEN-98: -- Attachment: NMAVEN-98.patch Patch attached. Added a simple NUnit test case. Dotnet simple archetype does not include unit tests --- Key: NMAVEN-98 URL: http://jira.codehaus.org/browse/NMAVEN-98 Project: NMaven Issue Type: Improvement Reporter: Teodoro Cue Jr. Attachments: NMAVEN-98.patch Building a project created from the dotnet-simple archetype produces: [INFO] [compile:testCompile] [INFO] NMAVEN-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version = 2.0.5 0727, Framework Version = 2.0.50727, Executable Paths = [C:\WINDOWS\Microsoft.NE T\Framework\v2.0.50727] [INFO] NMAVEN-068-002: No source files to compile. [INFO] Mojo Execution Time = 0 [INFO] [test:test] [INFO] NMAVEN-1100-001: No Unit Tests The dotnet-simple archetype should include an NUnit test case. -- 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: (NMAVEN-98) Dotnet simple archetype does not include unit tests
[ http://jira.codehaus.org/browse/NMAVEN-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116662 ] Wendy Smoak commented on NMAVEN-98: --- See also r595451, the log says Added sample nunit test class in the archetype. but the commit only touched the pom and archetype.xml files. http://svn.apache.org/viewvc?view=revrevision=595451 Dotnet simple archetype does not include unit tests --- Key: NMAVEN-98 URL: http://jira.codehaus.org/browse/NMAVEN-98 Project: NMaven Issue Type: Improvement Reporter: Teodoro Cue Jr. Attachments: NMAVEN-98.patch Building a project created from the dotnet-simple archetype produces: [INFO] [compile:testCompile] [INFO] NMAVEN-066-013: Found Vendor = Vendor = MICROSOFT, Vendor Version = 2.0.5 0727, Framework Version = 2.0.50727, Executable Paths = [C:\WINDOWS\Microsoft.NE T\Framework\v2.0.50727] [INFO] NMAVEN-068-002: No source files to compile. [INFO] Mojo Execution Time = 0 [INFO] [test:test] [INFO] NMAVEN-1100-001: No Unit Tests The dotnet-simple archetype should include an NUnit test case. -- 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
