[jira] Closed: (MRM-76) Front End web user interface for configuring multiple repository proxy
[ http://jira.codehaus.org/browse/MRM-76?page=all ] Brett Porter closed MRM-76. --- Assignee: Brett Porter Resolution: Fixed I've done this Front End web user interface for configuring multiple repository proxy -- Key: MRM-76 URL: http://jira.codehaus.org/browse/MRM-76 Project: Archiva Issue Type: Task Reporter: John Tolentino Assigned To: Brett Porter Fix For: 1.0-beta-1 For configuring multiple repository proxy. -- 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-135) integrate repository sync and conversion in the main application
[ http://jira.codehaus.org/browse/MRM-135?page=all ] Brett Porter updated MRM-135: - Fix Version/s: (was: 1.0-beta-1) integrate repository sync and conversion in the main application Key: MRM-135 URL: http://jira.codehaus.org/browse/MRM-135 Project: Archiva Issue Type: New Feature Components: repository-converter, partner sync, scheduling Reporter: Brett Porter -- 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-145) identify skins and adjust type in index accordingly
[ http://jira.codehaus.org/browse/MRM-145?page=all ] Brett Porter updated MRM-145: - Fix Version/s: 1.0-beta-1 identify skins and adjust type in index accordingly --- Key: MRM-145 URL: http://jira.codehaus.org/browse/MRM-145 Project: Archiva Issue Type: Improvement Components: indexing Reporter: Brett Porter Fix For: 1.0-beta-1 like we identify archetypes, attempt to identify skins and index them accordingly. It may be beneficial to introduce a proper packaging type for this in Maven itself. While it is not entirely deterministic (as a skin is simply a set of files laid onto the site), the existence of one of css/maven-base.css and site.vm would be a reliable predictor. -- 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-129) flush the index periodically during rebuild
[ http://jira.codehaus.org/browse/MRM-129?page=all ] Brett Porter updated MRM-129: - Fix Version/s: 1.0-beta-1 flush the index periodically during rebuild --- Key: MRM-129 URL: http://jira.codehaus.org/browse/MRM-129 Project: Archiva Issue Type: Improvement Components: indexing Reporter: Brett Porter Fix For: 1.0-beta-1 currently, the indexing can take some time when it is done from scratch on a large repository, and requires a large amount of memory. It would be good to periodically checkpoint the index with a set of artifacts already completed. How this affects the timestamp used needs to be interpreted, as if the indexing is stopped it may want to avoid reindexing those already done. Perhaps an alternative is to sort the discovered artifacts by timestamp, and setting it to the most recent one done - this can be considered in conjunction with the current issue that synced artifacts sometimes are new but have a timestamp older than the last indexing time and so are not indexed. -- 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-150) add field validations for forms
[ http://jira.codehaus.org/browse/MRM-150?page=all ] Brett Porter updated MRM-150: - Fix Version/s: 1.0-beta-1 add field validations for forms --- Key: MRM-150 URL: http://jira.codehaus.org/browse/MRM-150 Project: Archiva Issue Type: Task Components: web application Reporter: Brett Porter Assigned To: Maria Odea Ching Fix For: 1.0-beta-1 these are documented in the validation files by todos -- 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-156) track repositry manager base url in the metadata of a managed repository
[ http://jira.codehaus.org/browse/MRM-156?page=all ] Brett Porter updated MRM-156: - Fix Version/s: 1.0-beta-1 track repositry manager base url in the metadata of a managed repository Key: MRM-156 URL: http://jira.codehaus.org/browse/MRM-156 Project: Archiva Issue Type: New Feature Components: web application Reporter: Brett Porter Fix For: 1.0-beta-1 repository.manager.url = http://localhost:8080/ (for requesting the index) repository.manager.id = releases This is needed in the metadata at the root of the repo, so that when a pom configures a repository http://localhost:8080/releases/, the tools can recognise where it comes from -- 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-131) complete artifact browsing
[ http://jira.codehaus.org/browse/MRM-131?page=all ] Brett Porter updated MRM-131: - Fix Version/s: 1.0-beta-1 complete artifact browsing -- Key: MRM-131 URL: http://jira.codehaus.org/browse/MRM-131 Project: Archiva Issue Type: Improvement Components: web application Reporter: Brett Porter Fix For: 1.0-beta-1 currently some features of the artifact display page are not implemented (links to dependencies, displaying other information from the pom, and so on) -- 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-151) re-introduce index of developers and dependencies
[ http://jira.codehaus.org/browse/MRM-151?page=all ] Brett Porter updated MRM-151: - Fix Version/s: 1.0-beta-1 re-introduce index of developers and dependencies - Key: MRM-151 URL: http://jira.codehaus.org/browse/MRM-151 Project: Archiva Issue Type: Improvement Components: indexing Reporter: Brett Porter Fix For: 1.0-beta-1 it will be useful to identify which projects a developer are associated with, and the dependency index will be needed to do the depended-on page on the browse artifact page -- 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: (MRM-157) add a report on artifacts that have external repositories/plugin repositories in them
add a report on artifacts that have external repositories/plugin repositories in them - Key: MRM-157 URL: http://jira.codehaus.org/browse/MRM-157 Project: Archiva Issue Type: New Feature Components: reporting Reporter: Brett Porter this may have certain constraints - eg, we report on release repo if it has any snapshot repos, etc. -- 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-84) Basic statistics
[ http://jira.codehaus.org/browse/MRM-84?page=all ] Brett Porter updated MRM-84: Fix Version/s: 1.0-beta-1 Basic statistics Key: MRM-84 URL: http://jira.codehaus.org/browse/MRM-84 Project: Archiva Issue Type: Task Components: reporting Affects Versions: 1.0-beta-1 Reporter: John Tolentino Fix For: 1.0-beta-1 Original Estimate: 16 hours Remaining Estimate: 16 hours -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73279 ] Bernd commented on SUREFIRE-31: --- I could also not cleanly apply surefire-junit4.zip to the current sources. From a quick look: current ReportEntry has no constructor of the required form. You may want to test my patches? support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Issue Type: Improvement Reporter: John Didion Attachments: SUREFIRE-31-maven-surefire-plugin.patch, SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- 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] Deleted: (MRM-71) Traverse Dependencies
[ http://jira.codehaus.org/browse/MRM-71?page=all ] Brett Porter deleted MRM-71: Traverse Dependencies - Key: MRM-71 URL: http://jira.codehaus.org/browse/MRM-71 Project: Archiva Issue Type: Task Reporter: John Tolentino Original Estimate: 8 hours Remaining Estimate: 8 hours -- 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-60) Repository Manager should have a means to remove old snapshot builds
[ http://jira.codehaus.org/browse/MRM-60?page=all ] Brett Porter updated MRM-60: Fix Version/s: 1.0-beta-1 Repository Manager should have a means to remove old snapshot builds Key: MRM-60 URL: http://jira.codehaus.org/browse/MRM-60 Project: Archiva Issue Type: New Feature Reporter: Tim Clemons Fix For: 1.0-beta-1 A nice feature for the MRM to have would be a way to set rules on when older SNAPSHOT builds of the form name-version-date.time.ext should be removed from the repository. This could either be time based (e.g. any builds older than a month) or count based (e.g. keep only the newest 5 builds). In addition to the artifact itself, md5 and sha1 files should also be cleaned out. -- 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-128) better handling of jar artifacts without a pom
[ http://jira.codehaus.org/browse/MRM-128?page=all ] Brett Porter updated MRM-128: - Fix Version/s: 1.0-beta-1 better handling of jar artifacts without a pom -- Key: MRM-128 URL: http://jira.codehaus.org/browse/MRM-128 Project: Archiva Issue Type: Bug Components: indexing Reporter: Milos Kleint Fix For: 1.0-beta-1 when indexing jar artifacts, the name and description (plus other fields) are read from the artifact's pom file. When indexing local repository I figured that some artifacts don't have pom files. Specifically the archetype artifacts (see ARCHETYPE-48), there might be otehr cases. So it would be nice to consult the pom file in the actual artifact if pom not present. (it's stored at META-INF/maven if I recall correctly) -- 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-82) Reports should be components of their own so that new ones can be dropped in
[ http://jira.codehaus.org/browse/MRM-82?page=all ] Brett Porter updated MRM-82: Fix Version/s: 1.0-beta-1 Reports should be components of their own so that new ones can be dropped in Key: MRM-82 URL: http://jira.codehaus.org/browse/MRM-82 Project: Archiva Issue Type: Task Components: reporting Affects Versions: 1.0-beta-1 Reporter: John Tolentino Fix For: 1.0-beta-1 Original Estimate: 16 hours Remaining Estimate: 16 hours -- 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-83) Reports should be passed a listener to be able to log their discoveries
[ http://jira.codehaus.org/browse/MRM-83?page=all ] Brett Porter updated MRM-83: Fix Version/s: 1.0-beta-1 Reports should be passed a listener to be able to log their discoveries --- Key: MRM-83 URL: http://jira.codehaus.org/browse/MRM-83 Project: Archiva Issue Type: Task Components: reporting Affects Versions: 1.0-beta-1 Reporter: John Tolentino Assigned To: John Tolentino Fix For: 1.0-beta-1 Original Estimate: 16 hours Remaining Estimate: 16 hours - There will be different types of listeners passed in - web page, mail, etc. - There may be more than one listener, which can be achieved through an aggregate listener rather than crowding the interface with collections -- 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: (MRM-100) Make ProxyConfiguration into a plexus configuration object
[ http://jira.codehaus.org/browse/MRM-100?page=all ] Brett Porter closed MRM-100. Assignee: Brett Porter (was: Edwin Punzalan) Resolution: Won't Fix configuration was redone using a model Make ProxyConfiguration into a plexus configuration object -- Key: MRM-100 URL: http://jira.codehaus.org/browse/MRM-100 Project: Archiva Issue Type: Improvement Components: remote proxy Reporter: Edwin Punzalan Assigned To: Brett Porter Original Estimate: 6 hours Remaining Estimate: 6 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRM-148) provide way of zipping the repository index for remote distribution
[ http://jira.codehaus.org/browse/MRM-148?page=comments#action_73281 ] Milos Kleint commented on MRM-148: -- as discussed on mailing list as long as the following chain works, 'm happy 1. user has a repository url in pom. 2. by contacting a predefined location in the repository, I'm able to figure out the location of the index zip 3. I download the index zpi and i'm able to map the artifacts in index to those in the repository url defined in user's pom. provide way of zipping the repository index for remote distribution --- Key: MRM-148 URL: http://jira.codehaus.org/browse/MRM-148 Project: Archiva Issue Type: New Feature Reporter: Milos Kleint Attachments: archiver.patch for use in the IDEs, it would be nice to have the index for the remote repository readily available for download. the attached path solves that by always creating a zip file after the index is updated and placing it into the repository in .index folder. That way the IDE can easily check the location only with the knowledge of the repository url. -- 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: (MEAR-17) Jar files packed in the EAR file should also be added to application.xml or manifest.mf
[ http://jira.codehaus.org/browse/MEAR-17?page=comments#action_73284 ] Stephane Nicoll commented on MEAR-17: - No, so patching the EJB modules break signatures. That's one of the reason why I don't want to do it in the EAR plugin (but you should do so in the projeet building the EJB module) Thanks for the link, it's interessting but JavaEE5 specifc for now. Regarding APP-INF/lib it's a weblogic proprietary feature, it won't work on other app server. Jar files packed in the EAR file should also be added to application.xml or manifest.mf --- Key: MEAR-17 URL: http://jira.codehaus.org/browse/MEAR-17 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Kristoffer Peterhäesel Assigned To: Stephane Nicoll While attempting to package an EAR for deployment on JBoss I have come across a (for me) major issue with the way this module works. The issue is that there are a lot dependency jars included by default. That by itself isn't the problem. The problem is there is no way to include it in the classpath without defining all the dependencies again in the pom.xml for the EAR. In an ideal world (for me) the jars would be an easy way to add the jars to the classpath since I want to include all I need in the EAR to make it as easy as possible to set up a depoyment environment. There are really two options for how to do that. Either the jar files are added to the generated Manifest.MF file or else there should be a simple option to include all packed jar files to the application.xml. Both should (AFAIK) work in any standard-compliant container. The option of putting all the jar files in APP-INF/lib only works on Weblogic. -- 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: (MRESOURCES-25) Filtering of property values containing backslashes in path names still does not escape them?
[ http://jira.codehaus.org/browse/MRESOURCES-25?page=comments#action_73290
]
Holger Riegel commented on MRESOURCES-25:
-
Are you sure you are using version 2.2 of Maven resources plugin?
Look at your local Maven repository in the path
org/apache/maven/plugins/maven-resources-plugin. If there's a directory with
name 2.1 you are using the old 2.1 version of the plugin.
I had the same effect as the one you described.
But when I specified in the pom.xml the version 2.2 it worked:
plugin
artifactIdmaven-resources-plugin/artifactId
version2.2/version
/plugin
Alternatively you may delete your local repository. Maven should then get the
latest version of the resources plugin.
Filtering of property values containing backslashes in path names still does
not escape them?
-
Key: MRESOURCES-25
URL: http://jira.codehaus.org/browse/MRESOURCES-25
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Environment: Windows
Reporter: Bryan Carpenter
This was originally reported as MRESOURCES-17, and I understood from the
comments
there it was fixed in version 2.2 of the plugin. But I have tried using that
version of the
resources plugin, and I am still seeing the same problem.
My source property file contains:
org.apache.ws.security.crypto.merlin.file=${basedir}/keys/x509.PFX.MSFT
After filtering it looks like this:
org.apache.ws.security.crypto.merlin.file=D:\cygwin\home\dbc\cvs\omii-packaging\source\ws-wss4j/keys/x509.PFX.MSFT
and when the this is read in by `Properties.load()' the value ends up as:
d:cygwinhomedbccvsomii-packagingsourcews-wss4j/keys/x509.PFX.MSFT
--
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: (MAVENUPLOAD-1078) subethasmtp 1.0.3 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1078?page=comments#action_73291 ] fabrizio giustina commented on MAVENUPLOAD-1078: the only SNAPSHOT dependency is the retrotranslator-maven-plugin in the parent pom used during builds to produce the java-14 version of the jar: it's not a transitive dependency so it should not be a problem for people dependending on this pom. I know you can't actually release a project using the release plugin using SNAPSHOT plugins, but does this also apply to repository uploads? The retrotranslator mojo has not been released yet (although there was a release proposal just a few days ago) so if we have to remove dependency on the snapshot we could: - wait till a retrotranslator release is out - just remove the dependency version from the parent POM What do you say Carlos? subethasmtp 1.0.3 bundles - Key: MAVENUPLOAD-1078 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078 Project: maven-upload-requests Issue Type: Task Reporter: fabrizio giustina subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc plus an additional artifact for the jdk14 compatible version with a java14 classifier http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar subethasmtp-parent: only contains the parent pom http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1089) JExcelApi 2.6 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1089?page=comments#action_73295 ] Teodor Danciu commented on MAVENUPLOAD-1089: Here's a second attempt to solve this issue. I have uploaded a new version of the bundle at the specified location. http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar I added new information into the pom.xml, except for the SCM URL, because JExcelApi does not seem to have a public source repository. I hope this is enough. There's no more info I could provide myseld. Thanks, Teodor JExcelApi 2.6 Upload Key: MAVENUPLOAD-1089 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1089 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar http://jexcelapi.sourceforge.net/ JasperReports relies on this version of JExcelApi, so we need it uploaded to the Maven repositories. This is why it is me who uploads the bundle, although I'm not a JExcelApi developer. -- 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: (MANTRUN-37) Antrun breaks on multi-module builds
[ http://jira.codehaus.org/browse/MANTRUN-37?page=comments#action_73296 ] Martin Heitz commented on MANTRUN-37: - Having the same problem. Seems to be related to the use of xdoclet, which is loading antrun 1.0... Extract from pom: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId version1.1/version executions ... Stack trace (which shows, that 1.0 is used, although 1.1 is configured) follows: INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 'org.apache.maven.plugins:maven-antrun-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run. [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run': Unable to find the mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 'org.apache.maven.plugins:maven-antrun-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:538) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) 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:324) 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) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-antrun-plugin:1.0:run' in the plugin 'org.apache.maven.plugins:maven-antrun-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:533) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:390) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) ... 16 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.0:run. at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:323) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:312) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:440) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:524) ... 18 more Antrun breaks on multi-module builds Key: MANTRUN-37 URL: http://jira.codehaus.org/browse/MANTRUN-37 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Maven 2.0.1 Reporter: Mike Perham Priority: Critical I just updated to antrun v1.1 (which needs to be marked as released in jira BTW) and find that my multimodule build is now breaking. Running the build in the child module itself works fine but if I build the parent, it fails when it gets
[jira] Commented: (MASSEMBLY-99) dependencySets in a descriptor doesn't work anymore
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_73297 ] Norman Fomferra commented on MASSEMBLY-99: -- Dear John, If I understand correctly, the fix is, that the assembly descriptor now allows to place a dependencySets child element into a moduleSets parent element? That would be great. Where can I get the src/it/dependency-sets/massembly-99 example? Norman dependencySets in a descriptor doesn't work anymore --- Key: MASSEMBLY-99 URL: http://jira.codehaus.org/browse/MASSEMBLY-99 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: all Reporter: Olivier Lamy Assigned To: John Casey Priority: Blocker Fix For: 2.2 Attachments: assembly-spike-1.0.zip, descriptor.xml I attached my descriptor file. dependencySets dependencySet outputDirectorylib/outputDirectory unpackfalse/unpack scoperuntime/scope !-- how to exclude dependencies excludes excludejunit:junit/exclude /excludes -- /dependencySet /dependencySets unzip -l on the assembly file show empty lib directory. Olivier -- 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-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=all ] Maria Odea Ching updated CONTINUUM-755: --- Attachment: CONTINUUM-755-continuum-webapp-userValidation.patch Attached patch for validating User and UserGroup forms Add field validations with webwork field validator -- Key: CONTINUUM-755 URL: http://jira.codehaus.org/browse/CONTINUUM-755 Project: Continuum Issue Type: Task Components: Web interface Affects Versions: 1.1 Reporter: Emmanuel Venisse Assigned To: Maria Odea Ching Fix For: 1.1 Attachments: CONTINUUM-755-continuum-webapp-userValidation.patch, CONTINUUM-755-continuum-webapp.patch Original Estimate: 1 day, 6 hours Time Spent: 1 day, 8 hours Remaining Estimate: 0 minutes -- 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: (MPPMD-28) exclude files
[ http://jira.codehaus.org/browse/MPPMD-28?page=comments#action_73310 ] Jesper Zedlitz commented on MPPMD-28: - It it just a documentation problem. It is possible to exclude files from the PMD report: plugin artifactIdmaven-pmd-plugin/artifactId version2.1/version configuration excludes exclude**/org/example/generator**/exclude /excludes /configuration /plugin The two asterixes at the beginning of the path are important! exclude files - Key: MPPMD-28 URL: http://jira.codehaus.org/browse/MPPMD-28 Project: maven-pmd-plugin Issue Type: Wish Reporter: Jesper Zedlitz It would be nice if you could exclude files (generated source code) from the PMD report. The Cobertura plugin for examples has a configuration element excludes excludeorg/example/generated/**/*.class/exclude /excludes -- 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: (MCHANGELOG-46) Using the dateFormat option the generate changelog report shows a wrong date
Using the dateFormat option the generate changelog report shows a wrong date --- Key: MCHANGELOG-46 URL: http://jira.codehaus.org/browse/MCHANGELOG-46 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Reporter: Giorgio Urto Priority: Minor Using the dateFormat option in the generated changelog report a file that was changed the 14 december 2005 at 11.48.50 is show using this timestamp 0020-05-27 00:00:00. Here is my configuration for the plugin: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId version2.0-SNAPSHOT/version reportSets reportSet iddual-report/id configuration typerange/type range365/range dateFormatdd-MM-/dateFormat /configuration reports reportchangelog/report reportfile-activity/report reportdev-activity/report /reports /reportSet /reportSets /plugin Without the dateFormat attribute set, the date in the report is ok. -- 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: (MDEP-29) Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable)
[ http://jira.codehaus.org/browse/MDEP-29?page=comments#action_73314 ] Jimisola Laursen commented on MDEP-29: -- Haven't seen any activity for this plugin lately. When will 1.1/2.0 will be released? Will it have the functionality to output dependency filenames? Make (sure) dependency:resolve outputs absolute filename (or at least make it configurable) --- Key: MDEP-29 URL: http://jira.codehaus.org/browse/MDEP-29 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 1.1, 2.0 Reporter: Jimisola Laursen I haven't used 1.1/2.0 yet myself, but from Brian Fox's comment (http://jira.codehaus.org/browse/MDEP-24#action_69078) it's uncertain whether dependency:resolve outputs the absolute filename at all times. Being able to specify whether the output should be filename onlhy or absolute filename would be very useful. -- 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-529) Modules (child) scm connection URLs are not constructed correctly
[ http://jira.codehaus.org/browse/CONTINUUM-529?page=comments#action_73315
]
Martin van den Bemt commented on CONTINUUM-529:
---
You will run into other problems when the scm url is inherited and the location
in scm != artifactId, so better define the correct scm url in the child pom. So
if you want this fix, this defintely isn't a bug, but at most an enhancement or
request for this kind of functionality.
Modules (child) scm connection URLs are not constructed correctly
-
Key: CONTINUUM-529
URL: http://jira.codehaus.org/browse/CONTINUUM-529
Project: Continuum
Issue Type: Bug
Components: Core system, SCM
Affects Versions: 1.0.2
Reporter: Grégory Joseph
Fix For: 1.1
It *seems* to me that, when adding a parent pom to continuum, which has
modules defined, but the scm url only defined in the parent, it gets and
parses the child poms correctly, but their scm URLs are build as
${parentScmUrl}/${childArtifactId} , while I think they should rather be
${parentScmUrl}/${modulePath}
Maybe this is a maven inheritance issue, though ?
--
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: (DOXIA-74) Added muse format to doxia-core
Added muse format to doxia-core --- Key: DOXIA-74 URL: http://jira.codehaus.org/browse/DOXIA-74 Project: doxia Issue Type: New Feature Components: Core Affects Versions: 1.0-alpha-8 Reporter: Arnaud Bailly Priority: Minor Fix For: 1.0-alpha-8 Attachments: patch-doxia-1.0-alpha-8 As a workaround to DOXIA-68 bug, I have m\ade a patch to doxia-core-1.0-alpha-8 that include necessary code for generating maven sites from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. This patch may be useful for people who wish to write their documentation using Emacs muse mode. -- 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: (MPPMD-28) exclude files
[ http://jira.codehaus.org/browse/MPPMD-28?page=all ] Lukas Theussl closed MPPMD-28. -- Assignee: Lukas Theussl Resolution: Won't Fix This tracker is for the Maven 1 pmd plugin.If you meant to file this for the m2 plugin, please go to http://jira.codehaus.org/browse/MPMD. In m1, you have to use the maven.pmd.excludes property to exclude certain files, see http://maven.apache.org/maven-1.x/plugins/pmd/faq.html#disable-select-files. exclude files - Key: MPPMD-28 URL: http://jira.codehaus.org/browse/MPPMD-28 Project: maven-pmd-plugin Issue Type: Wish Reporter: Jesper Zedlitz Assigned To: Lukas Theussl It would be nice if you could exclude files (generated source code) from the PMD report. The Cobertura plugin for examples has a configuration element excludes excludeorg/example/generated/**/*.class/exclude /excludes -- 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=comments#action_73318 ] Mike Perham commented on MEV-337: - Here's my take on some of the more mysterious deps in OJB. antlr-2.7.5.jar Compile/Optional commons-beanutils-1.7.0.jar Compile/Required commons-betwixt-0.8-dev.jar Remove? Runtime/Optional, no compilation or test failures without it commons-digester-1.7.jarCompile/Optional commons-pool-1.2.jarCompile/Optional commons-transaction-1.1.jar Compile/Required jakarta-regexp-1.3.jar Compile/Optional jcs.jar Compile/Optional prevayler.jar Runtime/Optional village-2.0.jar Runtime/Optional OJB 1.0.4 has a number of dependencies that should be optional -- Key: MEV-337 URL: http://jira.codehaus.org/browse/MEV-337 Project: Maven Evangelism Issue Type: Bug Reporter: Matt Raible Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of dependencies that should be optional in 1.0.4. http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom For example: xjavadoc, xdoclet, velocity, torque, p6spy It does appear that some dependencies changed with this release (which is odd for a point release) - so you should probably get in touch with the OJB developers and see which ones are absolutely required. -- 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-99) dependencySets in a descriptor doesn't work anymore
[ http://jira.codehaus.org/browse/MASSEMBLY-99?page=comments#action_73319 ] John Casey commented on MASSEMBLY-99: - svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-assembly-plugin then, go to: cd maven-assembly-plugin/src/it/dependency-sets/massembly-99 and look in: src/main/assembly/bin.xml dependencySets in a descriptor doesn't work anymore --- Key: MASSEMBLY-99 URL: http://jira.codehaus.org/browse/MASSEMBLY-99 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: all Reporter: Olivier Lamy Assigned To: John Casey Priority: Blocker Fix For: 2.2 Attachments: assembly-spike-1.0.zip, descriptor.xml I attached my descriptor file. dependencySets dependencySet outputDirectorylib/outputDirectory unpackfalse/unpack scoperuntime/scope !-- how to exclude dependencies excludes excludejunit:junit/exclude /excludes -- /dependencySet /dependencySets unzip -l on the assembly file show empty lib directory. Olivier -- 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: (MCHANGELOG-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73320 ] Dennis Lundberg commented on MCHANGELOG-46: --- Are you using Perforce as your SCM? Using the dateFormat option the generate changelog report shows a wrong date --- Key: MCHANGELOG-46 URL: http://jira.codehaus.org/browse/MCHANGELOG-46 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Reporter: Giorgio Urto Priority: Minor Using the dateFormat option in the generated changelog report a file that was changed the 14 december 2005 at 11.48.50 is show using this timestamp 0020-05-27 00:00:00. Here is my configuration for the plugin: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId version2.0-SNAPSHOT/version reportSets reportSet iddual-report/id configuration typerange/type range365/range dateFormatdd-MM-/dateFormat /configuration reports reportchangelog/report reportfile-activity/report reportdev-activity/report /reports /reportSet /reportSets /plugin Without the dateFormat attribute set, the date in the report is ok. -- 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: (MNGECLIPSE-190) Unable to enable Maven2 plugin for existing not maven2 project
Unable to enable Maven2 plugin for existing not maven2 project -- Key: MNGECLIPSE-190 URL: http://jira.codehaus.org/browse/MNGECLIPSE-190 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Components: Wizards Affects Versions: 0.0.10 Environment: WinXP, Eclipse 3.2 Reporter: Marek Bieganski Assigned To: Eugene Kuleshov Attachments: UnableToEnable.PNG Steps: 1. Create new Java project, enter name e.g. lib 2. Right click on it, select Maven2-Enable 3. Cannot do anything on this window In 0.0.9 it was it worked fine. -- 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-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=comments#action_73326 ] Jeremy Whitlock commented on MRELEASE-130: -- Hi all, Work started on this yesterday. Currently I am working on creating a Modello model for a Release Descriptor that will be used by Maven instead of the ReleaseConfiguration. Once that is done I will be creating an XMLReleaseDescriptorStore to be able to persist/load a release descriptor to/from an XML document. This will make delegating the release to other tools like Continuum much easier in the long run. If you have any questions or concerns, comment on this so we can keep track of it. Take care, Jeremy Create a model for a release Key: MRELEASE-130 URL: http://jira.codehaus.org/browse/MRELEASE-130 Project: Maven 2.x Release Plugin Issue Type: New Feature Reporter: Jason van Zyl Assigned To: Jeremy Whitlock Use modello to create a model for a release. Something that could be sent to a release mechanism for an official release. -- 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: (MCHANGELOG-46) Using the dateFormat option the generate changelog report shows a wrong date
[ http://jira.codehaus.org/browse/MCHANGELOG-46?page=comments#action_73327 ] Giorgio Urto commented on MCHANGELOG-46: No whe are using svn 1.3.0 with viewvc 1.0.1 as SCM. I' am also very interested at MCHANGELOG-45, as we have found the same problem using the maven site feature over 460 svn repository. Is that issue (MCHANGELOG-45) going to be planned/assigned? Thank you. Giorgio Using the dateFormat option the generate changelog report shows a wrong date --- Key: MCHANGELOG-46 URL: http://jira.codehaus.org/browse/MCHANGELOG-46 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Reporter: Giorgio Urto Priority: Minor Using the dateFormat option in the generated changelog report a file that was changed the 14 december 2005 at 11.48.50 is show using this timestamp 0020-05-27 00:00:00. Here is my configuration for the plugin: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-changelog-plugin/artifactId version2.0-SNAPSHOT/version reportSets reportSet iddual-report/id configuration typerange/type range365/range dateFormatdd-MM-/dateFormat /configuration reports reportchangelog/report reportfile-activity/report reportdev-activity/report /reports /reportSet /reportSets /plugin Without the dateFormat attribute set, the date in the report is ok. -- 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-727) Allow Continuum to work with the release plugin to perform the official release
[ http://jira.codehaus.org/browse/CONTINUUM-727?page=comments#action_73328 ] Jeremy Whitlock commented on CONTINUUM-727: --- Hi All, Work on the Maven side started yesterday by creating a model to be used to hold the release descriptor. Edwin will be working on the Continuum side by creating the Web bits for this when it is ready. If you have any questions or concerns, please post it here so we can keep track of it. If you are interested in the Maven side of this, please reference MRELEASE-130 defined above as a dependency. Take care, Jeremy Allow Continuum to work with the release plugin to perform the official release --- Key: CONTINUUM-727 URL: http://jira.codehaus.org/browse/CONTINUUM-727 Project: Continuum Issue Type: New Feature Components: Core system Reporter: Jason van Zyl Assigned To: Jeremy Whitlock Fix For: 1.1 This might eventually be a little tool for release management but it could start in Continuum. So the release plugin would do a release:prepare and store the information in a descriptor (maybe use modello to describe the release) and the descriptor could be sent to Continuum via a Web Service and Continuum could do the official release. -- 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: (MAVENUPLOAD-1078) subethasmtp 1.0.3 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1078?page=comments#action_73322 ] Carlos Sanchez commented on MAVENUPLOAD-1078: - remove the version, having the snapshot there can cause problems subethasmtp 1.0.3 bundles - Key: MAVENUPLOAD-1078 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1078 Project: maven-upload-requests Issue Type: Task Reporter: fabrizio giustina subethasmtp-smtp and subethasmtp-wiser bundles: contain jar, sources, javadoc plus an additional artifact for the jdk14 compatible version with a java14 classifier http://magnolia.sourceforge.net/bundles/subethasmtp-smtp-1.0.3-bundle.jar http://magnolia.sourceforge.net/bundles/subethasmtp-wiser-1.0.3-bundle.jar subethasmtp-parent: only contains the parent pom http://magnolia.sourceforge.net/bundles/subethasmtp-parent-1.0.3-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1089) JExcelApi 2.6 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1089?page=all ] Carlos Sanchez closed MAVENUPLOAD-1089. --- Assignee: Carlos Sanchez Resolution: Fixed JExcelApi 2.6 Upload Key: MAVENUPLOAD-1089 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1089 Project: maven-upload-requests Issue Type: Task Reporter: Teodor Danciu Assigned To: Carlos Sanchez http://jasperreports.sourceforge.net/maven/jxl-2.6-bundle.jar http://jexcelapi.sourceforge.net/ JasperReports relies on this version of JExcelApi, so we need it uploaded to the Maven repositories. This is why it is me who uploads the bundle, although I'm not a JExcelApi developer. -- 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: (DOXIA-74) Added muse format to doxia-core
[ http://jira.codehaus.org/browse/DOXIA-74?page=comments#action_73323 ] Vincent Siveton commented on DOXIA-74: -- Thanks Arnaud! Some comments about your patch: * Patch should be licensed to Apache, no BSD, GNU or other [1] * Follow our code style [2] * Provide a minimalist documentation * role-hint=doxia needs to be renamed * role-hint=xhtml is already used somewhere * Use logging API instead of System.err or throw Exception [1] Contributions intended for inclusion in ASF products (eg. patches, code) must be licensed to ASF under the terms of the Apache Software License [2] http://maven.apache.org/guides/development/guide-m2-development.html Added muse format to doxia-core --- Key: DOXIA-74 URL: http://jira.codehaus.org/browse/DOXIA-74 Project: doxia Issue Type: New Feature Components: Core Affects Versions: 1.0-alpha-8 Reporter: Arnaud Bailly Priority: Minor Fix For: 1.0-alpha-8 Attachments: patch-doxia-1.0-alpha-8 As a workaround to DOXIA-68 bug, I have m\ade a patch to doxia-core-1.0-alpha-8 that include necessary code for generating maven sites from muse syntax and add a dependency to muse-parser from doxia-core pom.xml. This patch may be useful for people who wish to write their documentation using Emacs muse mode. -- 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: (MAVENUPLOAD-1091) Upload ognl:ognl:2.6.9 to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1091?page=all ] Carlos Sanchez closed MAVENUPLOAD-1091. --- Assignee: Carlos Sanchez Resolution: Fixed Upload ognl:ognl:2.6.9 to ibiblio - Key: MAVENUPLOAD-1091 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1091 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock Assigned To: Carlos Sanchez http://www.mattwhitlock.com/ognl-2.6.9-bundle.jar http://www.ognl.org/ OGNL stands for Object-Graph Navigation Language; it is an expression language for getting and setting properties of Java objects. This bundle also contains javadoc and sources jars. -- 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=comments#action_73324 ] Carlos Sanchez commented on MEV-337: this needs to be fixed in apache OJB, we just sync from there OJB 1.0.4 has a number of dependencies that should be optional -- Key: MEV-337 URL: http://jira.codehaus.org/browse/MEV-337 Project: Maven Evangelism Issue Type: Bug Reporter: Matt Raible Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of dependencies that should be optional in 1.0.4. http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom For example: xjavadoc, xdoclet, velocity, torque, p6spy It does appear that some dependencies changed with this release (which is odd for a point release) - so you should probably get in touch with the OJB developers and see which ones are absolutely required. -- 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: (MEV-337) OJB 1.0.4 has a number of dependencies that should be optional
[ http://jira.codehaus.org/browse/MEV-337?page=comments#action_73329 ] Mike Perham commented on MEV-337: - Yeah, sorry Carlos, I didn't even realize this was MEV. I thought it was the OJB JIRA. :) OJB 1.0.4 has a number of dependencies that should be optional -- Key: MEV-337 URL: http://jira.codehaus.org/browse/MEV-337 Project: Maven Evangelism Issue Type: Bug Reporter: Matt Raible Compare the 1.0.3 pom with the 1.0.4 - there seems to be a number of dependencies that should be optional in 1.0.4. http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.3/db-ojb-1.0.3.pom http://www.ibiblio.org/maven2/ojb/db-ojb/1.0.4/db-ojb-1.0.4.pom For example: xjavadoc, xdoclet, velocity, torque, p6spy It does appear that some dependencies changed with this release (which is odd for a point release) - so you should probably get in touch with the OJB developers and see which ones are absolutely required. -- 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: (MEV-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_73331 ] Joakim Erdfelt commented on MEV-413: The Jaxen pom is maintened by the jaxen software development group - http://jaxen.codehaus.org/team-list.html You could ask them to flag certain dependencies as optionaltrue/optional for the next release. In my opinion, they are the authoritative source for decisions on the jaxen pom. There are several jaxen mailing lists that could be used - http://jaxen.codehaus.org/mail-lists.html Those mailing lists would be the best place to get this change to be made, and for it to stick for all future version of jaxen too. Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5) - Key: MEV-413 URL: http://jira.codehaus.org/browse/MEV-413 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Jimisola Laursen Assigned To: Carlos Sanchez The pom (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) has dependencies on domj, jdom, xom, xerces:xercesImpl and xerces:xmlParserAPIs (see below). I can't see why any of these dependencies are necessary - especially not the dependency on xerces. A slimmed down verson of Xerces is included with JDK 1.5 and adding an addition Xerces in the classpath caused some major headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen 1.1-beta-9 has. dependencies dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.6.1/version /dependency dependency groupIdjdom/groupId artifactIdjdom/artifactId version1.0/version /dependency dependency groupIdxerces/groupId artifactIdxmlParserAPIs/artifactId version2.6.2/version /dependency dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.6.2/version /dependency dependency groupIdxom/groupId artifactIdxom/artifactId version1.0b3/version /dependency /dependencies -- 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-794) Password expiration
[ http://jira.codehaus.org/browse/CONTINUUM-794?page=comments#action_73332 ] Carlos Sanchez commented on CONTINUUM-794: -- From Lester: - when adding a user account is created, it asks for the number of days the account will be valid. The default is forever (meaning no expiration), which happens when the user leaves it unfilled. I will need input on whether we'll opt for the user to input the actual expiration date instead. I initially had it to accept decimal values as I'm not sure if 'days' would be a good unit of measure here. - when the account expires, acegi will prevent the account from being authenticated. It is handled similar to an incorrect login. Password expiration --- Key: CONTINUUM-794 URL: http://jira.codehaus.org/browse/CONTINUUM-794 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Lester Ecarma In the acegi user details service, every time a user authenticates check for date of password creation, if more than defined time set expired=true in the database and return the user with expired=true too I think Acegi will redirect to he page for change password, need to investigate. -- 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: (MEV-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_7 ] Jimisola Laursen commented on MEV-413: -- Thank you for the information. I'll do just that. Is it possible to move this issue to Jaxen (Jira key: JAXEN)? Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5) - Key: MEV-413 URL: http://jira.codehaus.org/browse/MEV-413 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Jimisola Laursen Assigned To: Carlos Sanchez The pom (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) has dependencies on domj, jdom, xom, xerces:xercesImpl and xerces:xmlParserAPIs (see below). I can't see why any of these dependencies are necessary - especially not the dependency on xerces. A slimmed down verson of Xerces is included with JDK 1.5 and adding an addition Xerces in the classpath caused some major headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen 1.1-beta-9 has. dependencies dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.6.1/version /dependency dependency groupIdjdom/groupId artifactIdjdom/artifactId version1.0/version /dependency dependency groupIdxerces/groupId artifactIdxmlParserAPIs/artifactId version2.6.2/version /dependency dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.6.2/version /dependency dependency groupIdxom/groupId artifactIdxom/artifactId version1.0b3/version /dependency /dependencies -- 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: (MEV-413) Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5)
[ http://jira.codehaus.org/browse/MEV-413?page=comments#action_73334 ] Jimisola Laursen commented on MEV-413: -- Me again... I forgot to say that Jaxen mailing lists seems to be out of order. Archive links doesn't work from project site and looking at the Nabble archive (http://www.nabble.com/jaxen---user-f11892.html) the last post is from Jul 11 2006. So, for now moving this issue to JAXEN seems like the best chance to get some attention. Jaxen has unnecessary and unexpected dependencies (which cause problems with JDK 1.5) - Key: MEV-413 URL: http://jira.codehaus.org/browse/MEV-413 Project: Maven Evangelism Issue Type: Bug Components: Dependencies Reporter: Jimisola Laursen Assigned To: Carlos Sanchez The pom (http://www.ibiblio.org/maven2/jaxen/jaxen/1.1-beta-9/jaxen-1.1-beta-9.pom) has dependencies on domj, jdom, xom, xerces:xercesImpl and xerces:xmlParserAPIs (see below). I can't see why any of these dependencies are necessary - especially not the dependency on xerces. A slimmed down verson of Xerces is included with JDK 1.5 and adding an addition Xerces in the classpath caused some major headache. JDK 1.5 or not, I have the exclude all the dependencies that Jaxen 1.1-beta-9 has. dependencies dependency groupIddom4j/groupId artifactIddom4j/artifactId version1.6.1/version /dependency dependency groupIdjdom/groupId artifactIdjdom/artifactId version1.0/version /dependency dependency groupIdxerces/groupId artifactIdxmlParserAPIs/artifactId version2.6.2/version /dependency dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.6.2/version /dependency dependency groupIdxom/groupId artifactIdxom/artifactId version1.0b3/version /dependency /dependencies -- 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-794) Password expiration
[ http://jira.codehaus.org/browse/CONTINUUM-794?page=comments#action_73335 ] Carlos Sanchez commented on CONTINUUM-794: -- we need to store only the date created. - Number of days valid is a configuration option, for now it can just be injected ffrom the xml config file, and will be shared for all users. Being number of days it must be of type int. You store the date as Date, no need to use a calendar, convert the days to milliseconds and you now if it's expired or not. - in ContinuumUserDetailsService.loadUserByUsername you can check if date created + expiration days current date and if true set accountNotExpired to false in the returned UserDetails Password expiration --- Key: CONTINUUM-794 URL: http://jira.codehaus.org/browse/CONTINUUM-794 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez Assigned To: Lester Ecarma In the acegi user details service, every time a user authenticates check for date of password creation, if more than defined time set expired=true in the database and return the user with expired=true too I think Acegi will redirect to he page for change password, need to investigate. -- 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-796) Disable account on login failures
[ http://jira.codehaus.org/browse/CONTINUUM-796?page=comments#action_73342 ] Carlos Sanchez commented on CONTINUUM-796: -- We need to inject an ApplicationEventPublisher into ProviderManager that will process the AuthenticationFailurePasswordEvent as said before. Actually seems that it's not AuthenticationFailurePasswordEvent but AuthenticationFailureBadCredentialsEvent. There's a long list of possible events that inherit from AbstractAuthenticationFailureEvent, http://acegisecurity.org/multiproject/acegi-security/apidocs/org/acegisecurity/event/authentication/AbstractAuthenticationFailureEvent.html Disable account on login failures - Key: CONTINUUM-796 URL: http://jira.codehaus.org/browse/CONTINUUM-796 Project: Continuum Issue Type: Sub-task Reporter: Carlos Sanchez We can hook into acegi authz event system to get unsuccessful logins and add the counter. After a definer number (eg. 3) of unsucessful consecutive logins the account must be disabled. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73343 ] Jian Wu commented on SUREFIRE-31: - Hi Bernd, You may want to test my patches? Sure. Do you mind telling me the instruction how to apply your patches? Thanks, Jian support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Issue Type: Improvement Reporter: John Didion Attachments: SUREFIRE-31-maven-surefire-plugin.patch, SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- 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: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_73345 ] Bernd commented on SUREFIRE-31: --- Jian, as a first step, please have a look at http://maven.apache.org/guides/development/guide-m2-development.html chapter Creating and submitting a patch There is some information about how to apply a patch Does that help? Bernd support junit 4.0 - Key: SUREFIRE-31 URL: http://jira.codehaus.org/browse/SUREFIRE-31 Project: surefire Issue Type: Improvement Reporter: John Didion Attachments: SUREFIRE-31-maven-surefire-plugin.patch, SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip I know this is a pretty sizable task. I just wanted to get it in the system now that 4.0 has officially been released. Hopefully this will generate some discussion about how 4.0 will be handled - mainly if it will require a completely seperate implemenation of surefire (keeping the same API so it can easily be used by the maven plugin), or if use of 4.0 will be made a configurable option of the current surefire. Here's some additional features I'd like to see: 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an @Category annotation, or make category a parameter of @Test. However, the filtering mechanism provided by 4.0 is sufficent to support categories given the presense of such an annotation. I recommend putting the @Category annotation in a seperate module (surefire-annotations?) and build support for it into surefire. Hopefully the junit guys could be convinced to incorporate it in a later version. 2. Similarly, support repeated tests via an @Repeated annotation. I'm not sure how easy this would be to do external to junit. -- 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: (MNG-2520) build error while: mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeGroupId=org.apache.maven.archetypes -DarchetypeArtifactId=maven-archetype-s
[ http://jira.codehaus.org/browse/MNG-2520?page=all ]
Vincent Siveton closed MNG-2520.
Assignee: Vincent Siveton
Resolution: Won't Fix
I suspect that you have already a pom.xml with jar packaging in the directory
where you called mvn.
To be clear, you had and did:
{noformat}
C:\maven-2.0.4\try\my-apppom.xml with packagingjar/packaging
C:\maven-2.0.4\try\my-appmvn archetype:create ...
= Embedded error: Unable to add module to the current project as it is not of
packaging type 'pom'
{noformat}
Feel free to reopen it if it doesn't work on a fresh directory.
build error while: mvn archetype:create -DgroupId=com.mycompany.app
-DartifactId=my-app -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-site
-
Key: MNG-2520
URL: http://jira.codehaus.org/browse/MNG-2520
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.4
Environment: Getting started tutorial
http://maven.apache.org/guides/getting-started/index.html
Reporter: Radu Marian
Assigned To: Vincent Siveton
C:\maven-2.0.4\try\my-appmvn archetype:create -DgroupId=com.mycompany.app
-Dart
ifactId=my-app -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifac
tId=maven-archetype-site
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'archetype'.
[INFO]
-
---
[INFO] Building Maven Quick Start Archetype
[INFO]task-segment: [archetype:create] (aggregator-style)
[INFO]
-
---
[INFO] Setting property: classpath.resource.loader.class =
'org.codehaus.plexus
.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on = 'false'.
[INFO] Setting property: resource.loader = 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound = 'false'.
[INFO] **
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File:
org\apache\velocity\runtime\defaults\velocity.pr
operties
[INFO] Default ResourceManager initializing. (class
org.apache.velocity.runtime.
resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated:
org.codehaus.plexus.velocity.ContextClassLo
aderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.
ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template :
VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in
any
resource loader.
[INFO] Velocimacro : error using VM library template VM_global_library.vm :
org
.apache.velocity.exception.ResourceNotFoundException: Unable to find resource
'V
M_global_library.vm'
[INFO] Velocimacro : VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in
templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may
NOT
replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
glob
al in scope if allowed.
[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[INFO] [archetype:create]
[INFO] Defaulting package to group ID: com.mycompany.app
[INFO]
-
---
[INFO] Using following parameters for creating Archetype:
maven-archetype-site:R
ELEASE
[INFO]
-
---
[INFO] Parameter: groupId, Value: com.mycompany.app
[INFO] Parameter: packageName, Value: com.mycompany.app
[INFO] Parameter: basedir, Value: C:\maven-2.0.4\try\my-app
[INFO] Parameter: package, Value: com.mycompany.app
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: artifactId, Value: my-app
[INFO]
[jira] Created: (MSUREFIRE-159) Surefire should provide a pluggable means to specify a custom provider
Surefire should provide a pluggable means to specify a custom provider -- Key: MSUREFIRE-159 URL: http://jira.codehaus.org/browse/MSUREFIRE-159 Project: Maven 2.x Surefire Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Micah Whitacre The current way that surefire determines which provider to use is hard coded and based on a project's dependencies. I would like to write a custom surefire-provider and be able to specify to use that provider without having to patch the surefire plugin. In my case I want to write a surefire-provider that will run Eclipse PDE Junits which wouldn't neccessarily have a specific dependency listed -- 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-2503) mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error
[ http://jira.codehaus.org/browse/MNG-2503?page=comments#action_73347 ] Vincent Siveton commented on MNG-2503: -- I tried to reproduce your problem with the last version of 4nt without success, ie 4NT 7.01 (4nt.exe, 3.2Mb, build 370) [1] Try to upgrade your 4nt version. I'd like a confirmation before I close this issue. Another tips for the next time, please refer to [2], Creating and submitting a patch part Thanks! [1] http://jpsoft.com/download.htm [2] http://maven.apache.org/guides/development/guide-m2-development.html mvn.bat file is not correct for 4NT 5.0 and does endlocal twice if error -- Key: MNG-2503 URL: http://jira.codehaus.org/browse/MNG-2503 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Windows XP SP2 and 4NT 5.00U Reporter: Mark DeLaFranier Priority: Minor Attachments: mvn.bat 1. If not setup properly and error occurs, the script attempts to endlocal twice: [d:\] mvn --version Exception in thread main java.lang.NoClassDefFoundError: org/codehaus/classworlds/Launcher 4NT: D:\dev\maven2\bin\mvn.bat [145] Missing SETLOCAL 2. Syntax wrong for adding CLASSWORLDS_JAR when under 4NT. For #1, I updated the :error section of the mvn.bat file. For #2, I added a new section to add the CLASSWORLDS_JAR -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMULTIPROJECT-70) Multiproject plugin not using dependencies when maven.jar.override = on
Multiproject plugin not using dependencies when maven.jar.override = on --- Key: MPMULTIPROJECT-70 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-70 Project: maven-multiproject-plugin Issue Type: Bug Environment: Windows 2000 Professional. Maven 1.1. Beta 3. Reporter: Matthew Purland Attachments: jira.zip When using the multiproject plugin with a project with multiple projects, dependencies defined in projectbase.xml, and all projects that have a project.xml file extend from projectbase.xml. If maven.jar.override = on is specified and the correct overridden jar artifactId is present then when running the test goal for a project from within multiproject, dependencies are given to unit tests that are run. Please see attached zip file for more detailed information. When using attached file, please place the contents of local_repo into your local repository for a successful test run/workaround to provide proof of working vs. nonworking. The only workaround I've found is to take the jars that are depended upon and place them into the local repository and depend on them as regular dependencies and take out maven.jar.override. However, this doesn't necessarily solve the problem that if you have a vendor jar that you can't place in ibiblio or a remote repository without setting up a maven repository server such as proximity or continuum. I will try to provide a test in the future. -- 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: (MNGECLIPSE-191) support inplace webapp deployment
support inplace webapp deployment - Key: MNGECLIPSE-191 URL: http://jira.codehaus.org/browse/MNGECLIPSE-191 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Reporter: Mike McMahon Assigned To: Eugene Kuleshov Priority: Minor Attachments: inplace.patch Currently, maven-built webapp projects (with or without m2eclipse) are difficult to debug efficiently using Eclipse. My definition of efficient debugging of a webapp (using Tomcat for example) is: - HTML and JSP pages immediately seen upon edit/save then browser refresh/F5 - Java class changes are HotSwapped into the running JVM, stack is rewound - Java class changes are immediately placed into Tomcat WEB-INF/classes My recommended approach is that m2eclipse should make a .classpath which enables the Eclipse builder (org.eclipse.jdt.core.javabuilder) to fully assemble an exploded war deployment of the webapp. An example classpath is as follows: classpath classpathentry output=src/main/webapp/WEB-INF/classes kind=src path=src/main/java/ classpathentry kind=src path=src/test/java/ classpathentry output=src/main/webapp/WEB-INF/classes kind=src path=src/main/resources/ classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/ classpathentry kind=con path=org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER/ classpathentry kind=output path=target/classes/ /classpath A more complex case (multi-module build having multiple source trees) would work by assembling ALL of the classes and resources into a single webapp location. This approach diverges from the current m2eclipse philosophy of having the Eclipse build mirror the maven build. I dont see much actual value in synchronizing these 2 independent builds, especially when so much productivity is gained by using the Eclipse build for inplace webapp purposes. Patch attached -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-828) Project group error adding project
[ http://jira.codehaus.org/browse/CONTINUUM-828?page=all ] Jesse McConnell closed CONTINUUM-828. - Resolution: Fixed fixed on trunk, 437054 Project group error adding project -- Key: CONTINUUM-828 URL: http://jira.codehaus.org/browse/CONTINUUM-828 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Environment: acegi branch Reporter: Carlos Sanchez Assigned To: Jesse McConnell Fix For: 1.1 I got this exception trying to add maven skins pom http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?view=co [INFO] 0 errors. [INFO] Creating project group with the group id: 'org.apache.maven.skins'. 16:35:13,562 WARN JPOX.RDBMS.SQL [org.jpox.store.rdbms.request.FetchRequest] Object with id 0 not found ! [INFO] Error ocurred during execution org.apache.maven.continuum.ContinuumException: Unable to find the requested project at org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup_aroundBody196(DefaultContinuum.java:2473) at org.apache.maven.continuum.DefaultContinuum$AjcClosure197.run(DefaultContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup(DefaultContinuum.java:1) at org.apache.maven.continuum.web.action.SummaryAction.execute(SummaryAction.java:55) 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 com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:365) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:217) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:191) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:137) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at
[jira] Created: (MRM-158) automatically index proxied artifacts
automatically index proxied artifacts - Key: MRM-158 URL: http://jira.codehaus.org/browse/MRM-158 Project: Archiva Issue Type: Improvement Components: indexing, remote proxy Reporter: Brett Porter currently the proxied artifacts will only be indexed when the indexer is next run. We should automatically index them, but some care needs to be taken: - make sure the indexer is thread safe and won't regularly fail with a failed lock - find the best way to hook this up by design (need to separate proxied artifacts from proxied files as this is internal to the proxy code, and don't want the indexer into the proxy code but rather in the core). -- 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: (MRM-159) should not respond with a 404 if proxying a file results in a remote error
should not respond with a 404 if proxying a file results in a remote error -- Key: MRM-159 URL: http://jira.codehaus.org/browse/MRM-159 Project: Archiva Issue Type: Bug Components: remote proxy Reporter: Brett Porter if any repository returns success, return success otherwise, if any repository returns in error, return a generic error (500), saying to check the logs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-309) add junit results report to website, failures to email
[ http://jira.codehaus.org/browse/CONTINUUM-309?page=all ] Jesse McConnell closed CONTINUUM-309. - Resolution: Fixed applied to trunk, thanks! add junit results report to website, failures to email -- Key: CONTINUUM-309 URL: http://jira.codehaus.org/browse/CONTINUUM-309 Project: Continuum Issue Type: New Feature Reporter: Brett Porter Assigned To: Edwin Punzalan Fix For: 1.1 Attachments: CONTINUUM-309-continuum-webapp.patch, CONTINUUM-309-sample.GIF, continuum-api.diff, continuum-core.diff, continuum-model.diff, continuum-web.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-819) project.getWorkingDirectory is null
[ http://jira.codehaus.org/browse/CONTINUUM-819?page=all ] Jesse McConnell closed CONTINUUM-819. - Resolution: Fixed applied to trunk, thanks! project.getWorkingDirectory is null --- Key: CONTINUUM-819 URL: http://jira.codehaus.org/browse/CONTINUUM-819 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Reporter: Edwin Punzalan Assigned To: Jesse McConnell Attachments: CONTINUUM-819-continuum-core.patch inside an action class' execute method, continuum.getProject().getWorkingDirectory returns null -- 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
